[pyar] Programación Orientada a Aspectos (POA)

[Ricardo Araoz]

On 23/09/10 02:07, Ernesto Savoretti wrote:
> A ver. Antes de este thread yo sabía tirando a nada de aspect oriented
> programming y consecuentemente tampoco sabía que la forma más directa
> de expresarlo en Python es a través de la implementación de
> decoradores.
> Coincido con Pablo en que la mayor parte de la documentación que
> existe sobre decoradores en Python no hace mención a AOP, pero bueno,
> la idea no es resucitar una discusión sino compartir a través de un
> ejemplo lo que este thread me sirvió para aprender.
> Para espanto de los sufridos pythonistas, va el ejemplo:
>
> Supongamos que tenemos 2 funciones, por ej:
> def edit_article(request):
>     ...
>
> y
>
> def change_user_mail(request):
>     ...
>
> estas funciones tienen cada uno un objetivo espécifico, planteado en
> el nombre de las mismas, y por ende deberán contener código específico
> para cumplir su tarea.
> Pero supongamos que además, para ser ejecutadas, el usuario debe
> haberse acreditado en el sistema.
> Uno podría resolver esto con:
>
> def edit_article(request):
>     if not request.user.is_authenticated():
>          #mandalo a que haga login
>
> y lo mismo en la otra función.
> Pero este enfoque tiene 2 problemas:
> 1) Se repite código innecesariamente
> 2) Se mezcla código específico de la función con código que no tiene
> nada que ver con la tarea a cumplir, cual es el de verificar las
> credenciales del usuario.
>
> En Django, esto se resuelve con el decorador:
>
> @login_required
> def edit_article(request):
>
> Con esto, el código dentro de la función se dedica "a lo suyo", la
> función queda "limpita", y el código de validación queda "inyectado"
> por el decorador "desde afuera" (esto último es un barbarismo, pido se
> me conceda la licencia)
> Me parece que el ejemplo sirve para ver una implementación "de la vida
> real" de porque los decoradores pueden implicar una implementación de
> AOP, y a entender un poco más (aunque sólo sea rasgar la superficie)
> de lo que es AOP en sí.
>
> Mis saludos.
>
>   

Bueno, a guitarrear se ha dicho!
Primero aclaro que de POA ni jota.
Segundo, entiendo que tal vez el ejemplo que has dado es sólo ilustrativo.
Aún así quisiera señalar que, en mi opinión, si hacés lo propuesto el
programa está mal diseñado. Las funciones se tienen que dedicar sólo a
lo suyo (encapsulamiento?) y nada más. No sé qué hace el usuario
obteniendo acceso a ellas cuando no tiene permisos. O no debería haber
entrado hasta ser validado, o si entró las opciones de menú, controles,
botones, a los que no tiene permisos debieran estar
deshabilitados/ocultos. En cuyo caso el problema no existe.
Sé que podemos encontrar algún caso rebuscado. Por ejemplo un campo de
texto que debe ser validado sólo si cierta condición se cumple. Pero en
ese caso el código corresponde que esté en el campo :
if debeValidar then:
    validar()

Seguro que vamos a poder encontrar algún caso que invalide lo que digo,
pero va a ser algo de excepción y no la norma. En ese caso el decorador
puede servir.
Ojo! Tal vez esto no corra para quien tenga que hacer magia en algún
framework. Pero son aplicaciones muy específicas.

Si bien el tono es de afirmación, es más de pregunta. Me encantaría
aprender en qué casos lo que digo no es conveniente y cómo encarar el
tema en estos casos.