Entiendo los pros y los contras de usar programación orientada a objetos como un concepto. Lo que estoy buscando son los pros y los contras de usar oo en progreso/openge específicamente. ¿Hay desafíos que debo tener en cuenta? ¿Hay partes del lenguaje que no encajan bien con oo? Cosas como esas.Pros y contras de usar programación orientada a objetos para el progreso openge
Editar: usando 10.2b
te voy a dar mi opinión, pero te aviso que soy probablemente el mayor enemigo del progreso por ahí. ;) Dicho esto, he escrito varios proyectos medianos en OOABL, así que tengo algo de experiencia en el área. Estas son algunas cosas que escribí, para que lo sepas No estoy hablando de mi sombrero: protocolo marco
Pros: OOABL
OOABL Contras:
CATCH/THROW no le permite arrojar sus errores personalizados y forzar a las personas que llaman a atraparlos. La compatibilidad con versiones anteriores evita que esto siga evolucionando, por lo que dudo que vaya a mejorar.PUBLISH/SUBSCRIBE tampoco funcionó, si la memoria sirve.OO es todo sobre la construcción de piezas pequeñas, reutilizables que se pueden combinar para hacer un conjunto mayor. Un gran problema con OOABL es que la parte "ABL" te arrastra hacia abajo con sus gruesas estructuras de datos y la falta de enumeradores, lo que te impide ser realmente capaz de construir cosas realmente bellas con ella. Lamentablemente, dado que es un lenguaje cerrado, no puede simplemente dejar de lado la mano que le asignaron y crear sus propios datos o estructuras de control externos.
Ahora, teóricamente es posible para tratar de construir algunas de estas cosas utilizando MEMPTR, arreglos fijos (EXTENSIÓN) y tal vez WORK-TABLE. Sin embargo, lo intenté en 10.1C y el diseño se vino abajo debido a la falta de herencia de interfaces y clases abstractas, y como esperaba, el rendimiento fue bastante malo. La última parte puede deberse a mi poca capacidad, pero sospecho que es una limitación de implementación que sería casi imposible de superar.
La línea inferior es usar OOABL si es absolutamente necesario que esté codificando en OpenEdge; es mejor que ABL de procedimiento y los bordes ásperos se vuelven ligeramente más suaves después de cada versión iterativa de OpenEdge. Sin embargo, nunca será un lenguaje hermoso (OO o de otro tipo).
Si desea aprender la programación adecuada orientada a objetos y no está restringida a ABL, le recomendaría consultar un lenguaje que trate objetos como ciudadanos de primera clase como Ruby o Smalltalk.
¡Gracias, esto realmente ha ayudado! – Bill
¡No podrías odiar abrirte más que yo! En mi humilde opinión, el Progreso debe abandonar el ABL y trabajar en implementaciones SQL y SQL no asesinas, nadie quiere el ABL –
Lo peor para mí es la falta de matrices de primera clase para permitir implementaciones de mapeo/cola/mazo/lista. –
K +
Sólo una cosa - "Manejo de errores chupa" - que es una mierda, pero no porque no se puede hacer sus propios errores-clases a la captura de ellos en el bloque que llama - que funciona, estoy usando eso. Lo que apesta es esa mezcla de la antigua opción NO-ERROR/ERROR-HANDLE y el bloque Progress.Lang.Error/CATCH y ROUTINE-LEVEL ON ERROR UNDO, THROW. Ese es un gran problema, cuando no existe convención en el equipo, qué manejo de errores y cómo se usará.
Derecha. Trataba de mantenerlo conciso, pero lo que quise decir es que en Java (que es esencialmente lo que OOABL copia en la medida de sus posibilidades), cuando defino un método que 'LANZA 'un error, y alguien más llama a mi método , ellos * deben * 'CAPTAR' el error potencial que voy a lanzar (o alternativamente re-'THROW' en la pila de llamadas nuevamente). En ABL, no hay aplicación en tiempo de compilación de esto. Escribir clases de error personalizadas en OOABL básicamente le da solo un número de error personalizado y un mensaje. No se obtiene ese flujo de control agradable como Java, incluso con 'ROUTINE-LEVEL ON ERROR UNDO, THROW'. –
O, para decirlo de manera más simple, las personas que llaman nunca sabrán que su método arroja una excepción personalizada (por ejemplo, 'FileNotFoundException'). No hay ningún mensaje de compilación al llamar a un método que arroja una excepción personalizada. Tendrían que mirar tu fuente y ver que tu método arroja un error. En Java, el compilador obliga a atrapar o volver a lanzar, incluso si planea ignorarlo. –
@AbeVoelker a lo que te refieres se lo conoce con el nombre de "excepciones marcadas" y se coloca casualmente como uno de los artículos principales en varias listas de "cosas malas de Java". Quizás una de las mejores explicaciones sobre por qué las excepciones controladas hacen más daño que bien fue presentada por el infame Anders Hejlsberg: http://www.artima.com/intv/handcuffs.html Aparte de eso, estoy completamente de acuerdo con su análisis crítico de ABL, que incluye muchas de tus otras publicaciones aquí y en tu blog. No pensaría en ti como un "enemigo", sino un profesional que se preocupa por su conjunto de herramientas. –
En los últimos cuatro años he trabajado el 80% del tiempo con OOABL (comenzó con 10.1c). Definitivamente recomiendo usar OOABL pero creo que es muy importante considerar que usar OOABL de la misma manera que en otros lenguajes de OO está plagado de problemas. Con "de la misma manera" quiero decir patrones de diseño y prácticas de implementación que son comunes en el mundo de oo. Además, algunos tipos de aplicaciones, especialmente en el área de los marcos técnicos, son difíciles de hacer con OpenEdge (por ejemplo, ORM).
Las causas son problemas de rendimiento con OOABL y funciones de OO que faltan en el idioma.
Si está programando en C# o en Java, la huella de memoria y el tiempo de creación de instancias de los objetos no son un gran problema en muchos casos. El uso de ABL se convierte en un gran problema con mucha más frecuencia. Esto lleva a otras decisiones de diseño y evita la implementación de algunos patrones y marcos.
Algunas características OO faltantes o malas:
Si está familiarizado con la programación de oo en otros idiomas y comienza a trabajar con OOABL, podría llegar a un punto en el que se estaba perdiendo muchas cosas que espera encontrar allí, y frustrarse al intentar implementar tales cosas en ABL.
Si su aplicación tiene que ejecutarse solo en Windows, también es posible implementar un nuevo código oo en C# y llamarlo desde su código de progreso existente a través del puente clr, que funciona muy bien.
+1 para todo. Me alegro de no tener que tocarlo más. Si lo hiciera, lo usaría.NET, algún otro lenguaje que llegue a la base de datos usando los adaptadores SQL, o escriba código C y solo escriba ABL como un contenedor para eso :-) –
¿Qué versión de Progress/OpenEdge estás usando? –
usando 10.2b .... – Bill
Una desventaja obvia si usa OOP es cuando intenta generar .NET Proxy usando ProxyGen para su clase. Generador de Proxy no permite CLS como entrada y usted tendrá que escribir el procedimiento de puerta de enlace para exponerlos. [Artículo de KB] (http://knowledgebase.progress.com/articles/Article/P181115?q=Can+y++instantiate+a+4GL+class+instance+from+a+.NET+client%3F&l=en_US&fs=Search&pn = 1) – kiran