He escuchado muchas veces sobre la programación orientada a aspectos, principalmente que es la tecnología de "próxima generación" en programación y que va a 'matar' la POO.
¿Es correcto? ¿Va a morir la POO o cuál puede ser la razón?
Cada vez que alguien le diga que una tecnología de software matará a otra o dominará todo el mercado / uso / audiencia, recuerde esto:
Un ecosistema sano (dinámico pero estable) está formado por una variedad de especies muy diferentes.
Eso significa que cualquier nueva tecnología publicitada pasará por la curva de exageración y al final encontrará su (s) propósito (s) específico (s) a través del tiempo y la experiencia con ella.
Eso también significa que un concepto tan extremo como la programación orientada a aspectos es útil si es necesario, es decir, no siempre y no muy a menudo, debido a los costos implícitos.
Pero ya tiene su lugar, como OOProgramming, como programación genérica, como programación funcional, como programación de procedimientos, etc.
¿Notó que los idiomas que son los más utilizados (y polémicamente populares) y ampliamente difundidos en la vida real "no son puros"? Esto se debe a que permitir varios paradigmas los hace más flexibles para cambiar el contexto a través del tiempo y llenan más nichos de uso.
OOP no va a morir a causa de AOP. AOP agrega algo de valor, pero vive en perfecta coexistencia con OOP. No creo que la programación funcional matará a OOP tampoco. OOP es demasiado adecuado para muchos tipos de dominios problemáticos, no tendría sentido reemplazarlo con el paradigma funcional.
fuente
Los paradigmas van y vienen, pero el código heredado es para siempre. Siempre habrá código C ++ para mantener, por lo que OOP nunca se extinguirá por completo.
fuente
Respuesta corta: No, no lo creo.
Respuesta más larga: por lo que entiendo de AOP, no es un paradigma de programación en sí mismo (como en, no reemplaza a OOP), sino más bien una adición, un conjunto de herramientas que lo ayuda a escribir métodos más cortos, clases más simples y de responsabilidad única. , etcétera. Pero no reemplaza a OOP.
Lo que reemplaza o agrega (al menos en parte) a OOP es la programación funcional, que en realidad es un paradigma de programación diferente (aunque puede mezclarse con OOP, por ejemplo, en el lenguaje de programación Scala ). Prefiere estructuras de datos inmutables y todo tipo de características sofisticadas que tienden a frustrar a los desarrolladores de OOP, particularmente cuando se trata de concurrencia.
fuente
Se habla menos de POO en estos días, ya que se supone que es el enfoque de facto en muchas situaciones. AOP nunca despegó como cualquier tipo de movimiento de masas.
fuente
Recuerdo haber escuchado sobre la Programación Orientada a Aspectos por primera vez en un Tutorial de OOPSLA '97. Dijeron que iba a matar a OO en ese entonces. Desde entonces, OO solo ha crecido más allá de las expectativas más salvajes. AOP, todavía es poco conocido, esencialmente sin impacto en la industria informática. Creo que la respuesta es obvia que AOP no es un asesino de OO.
fuente
Mira algunos sistemas AOP existentes. Dependen de que tenga algún código escrito de alguna forma; por ejemplo, Spring AOP depende de que tenga sus métodos definidos en una clase. Castle Windsor lo admite en C #, que es un lenguaje orientado a objetos.
Teóricamente, podría cambiar de OOP a programación estructurada y aún mantener AOP, pero en la práctica, eso sería difícil. Es fácil subclasificar algo, anular el método relevante para llamar a los filtros antes / después apropiados y transmitirlo en el proceso de inyección de dependencia.
Es muy difícil en comparación reescribir las llamadas a métodos estáticos para enrutarlas a un método de trampolín diseñado para llamar a los filtros definidos por el usuario.
Entonces, desde un punto de vista de implementación común, AOP requiere OOP.
fuente
Si bien OOP ciertamente no es una bala de plata, lo mismo puede decirse de AOP. Es compatible con el diseño basado en componentes, sin embargo, en el esquema general, sus componentes son los nuevos objetos y las interfaces de los componentes son básicamente una lista transaccional de métodos, lo cual NO es cierto OOP.
El diseño adicional basado en AOP y componentes admite un modelo de datos anémicos, que critican a las personas más inteligentes que yo.
http://martinfowler.com/bliki/AnemicDomainModel.html
(Sé que el artículo anterior es antiguo, pero sorprendentemente relevante)
La conclusión es que los sistemas AOP están aquí para quedarse, pero están lejos de ser perfectos también. Ningún sistema es perfecto.
fuente