Discusión:Programación orientada a aspectos

Traducción de Separation of Concerns

El término inglés Concern se traduce como concernir. Pero en español no utilizamos el término conciertos como traducción de concerns. Así que debemos utilizar un sinónimo de concernir. Incumbencia es más apropiado. La traducción original incluida en éste artículo decia "separación de conceptos", esta es una traducción que pierde el sentido original de la separación de incumbencias. La división en rutinas ya es una separación de conceptos.

La seguridad de un sistema, es una incumbencia y no puede ser separado en los conceptos tradicionales de rutina, objeto o modulo. Son incumbencias transversales.

¿sería positivo aplicar estos conceptos de POA a una jerarquía de clases web en PHP?

Respuesta: Entiendo que sí. Sin embargo, hay que tener cuidado de no caer en querer usar aspectos a toda costa. Es decir, hay que usar aspectos cuando realmente supongan una mejor solución a un determinado problema. El uso de aspectos se hace combinado con otros paradigmas de programación, no los sustituye.

Pregunta: Es adecuado presentar la programación orientada a aspectos como un paradigma de programación en la introducción del artículo?

pointcut

Creo que tanto la traducción como la definición de pointcut son incorrectas. Un pointcut es un conjunto de join points. Es decir, puestos a intentar una traducción literal, sería algo así como un corte de puntos, entendiendo corte como trozo, tajada, porción o algo así. Como estas traducciones son un poco horribles, yo lo dejaría en conjunto de puntos de cruce. Un pointcut no define "los Consejos que se aplicarán a cada Punto de Cruce", sino un conjunto de puntos de cruce. Otra cosa es que asociemos los Consejos a estos conjuntos.

AOP como categoría "Módulos Perl"

No entiendo por qué el paradigma de programación orientada a aspectos está categorizado como Módulos Perl. Como bien dice el texto, existen implementaciones para muchos lenguajes, no sólo para Perl.

Traducción JoinPoint, Proxy y Target

La traducción actual me parece poco acertada. Una traducción más acertada para estos elementos propios del lenguaje sería:

JoinPoint: Punto de unión o Punto de Enlace ya que define el punto donde se unirán el código del Aspecto con el código del 'Destinatario'. Actualmente Punto de cruce no creo que defina con exactitud su utilidad.

Target: Destinatario no me parece muy acertado, ya que el 'Target' es el objeto pasivo de la programación orientada a aspectos, propongo Objetivo.

Proxy: Representante suele ser el término utilizado en castellano, y sinceramente me parece más acertado. Resultante parece bastante dependiente de la implementación, ya que presupone que el 'Target' va a ser modificado durante el tejido del aspecto (weaving).

--Redent84 (discusión) 11:49 20 oct 2008 (UTC)

Muchas veces nos encontramos, a la hora de programar, con problemas que no podemos resolver de una manera adecuada con las técnicas habituales usadas en la programación imperativa o en la programación orientada a objetos. Con éstas, nos vemos forzados a tomar decisiones de diseño que repercuten de manera importante en el desarrollo de la aplicación y que nos alejan con frecuencia de otras posibilidades.

No estoy de acuerdo con este párrafo anterior por los siguientes motivos: Con la programación orientada a objetos, el programador NO se preocupa de como será el diseño final del software que esta codificando, ya que nos permite crear clases modulares tanto independientes como dependientes (gracias a la herencia) Esto quiere decir que No estamos forzados a tomar decisiones de diseño, el diseño o ensamblado en si del software viene despues. Con esto quiero decir que la clase por mas simple que sea, En sí ya es un software o programa, que tranquilamente podrás publicar para que otros puedan usarlo a su antojo, y aplicarlo en sus respectivos sistemas, en síntesis El programador no esta forzado a tomar decisiones de diseño ya que las clases pueden ser usados con gran versatilidad.

Post: Si interpreté mal el párrafo, pido disculpas. 'Una maquina nunca será perfecta, porque quien lo invento fué humano'

--190.104.153.52 (discusión) 16:45 13 abr 2009 (UTC)

Enlaces rotos

• http://old.aspyct.org/doku.php?id=aspyct

Elvisor (discusión) 00:26 20 nov 2015 (UTC)

Enlaces externos modificados

Hola,

Acabo de modificar 1 enlaces externos en Programación orientada a aspectos. Por favor tomaos un momento para revisar mi edición. Si tenéis alguna pregunta o necesitáis que el bot ignore los enlaces o toda la página en su conjunto, por favor visitad esta simple guía para ver información adicional. He realizado los siguientes cambios:

• Se añadió el archivo https://web.archive.org/web/20120906032119/http://old.aspyct.org/doku.php?id=aspyct a http://old.aspyct.org/doku.php?id=aspyct

Por favor acudid a la guía anteriormente enlazada para más información sobre cómo corregir los errores que el bot pueda cometer.

Saludos.—InternetArchiveBot (Reportar un error) 15:01 30 jun 2019 (UTC)