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

[Claudio Freire]

2010/9/23 Ricardo Araoz <ricaraoz en gmail.com>

> 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.
>

Grave error pensar esto.

Que un botón esté "display:none" en un formulario web no quiere decir que
alguien no pueda falsificarte el POST.

El @login_required es una medida de seguridad que apunta a eso: a
"enforcear" (wow... inventation) la aplicación de las reglas de seguridad.

Mostrar o no mostrar botones es secundario. Lo principal es que sea
imposible realizar ciertas acciones sin permiso. Si alguien se las rebusca
para engañar a la aplicación y llamar la función a pesar de no tener
permisos, @login_required lo para ahí nomás.



> 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()
>

Eso precisamente busca evitar AOP.

Validaciones, logging y otras cosas son criterios que se aplican en
muchísimos lugares de la aplicación. Son "crosscutting concerns" como le
dicen in inglish, y programarlos así directamente como decís desparrama la
lógica asociado a esos temas por toda la aplicación. Hacer una modificación
(ej: los números positivos ahora pueden incluir el 0) implica modificar 1000
millones de lugares donde se implementó la lógica.

El ejemplo de logging de la wiki es genial, puesto que es arquetípico.


Seguro que vamos a poder encontrar algún caso que invalide lo que digo


Eso hace que haya mal diseño. Un buen diseño es válido siempre.



> pero va a ser algo de excepción y no la norma.


Un programa con cientos de excepciones = una pesadilla.

Está bien aceptar la existencia de alguna que otra excepción, pero no hay
que hacerlo demasiado felizmente porque después tu programa es pura
excepción. Hay que minimizar los casos excepcionales, hay que guardarse el
mote de excepcional para lo realmente excepcional.

Ciertas disciplinas (como AOP) buscan eliminar situaciones que se vio, con
experiencia, que sucedían a menudo. No hay que ser displicente e ignorar la
sabiduría en ellas. Es una lástima que el 90% de los textos sobre AOP
apunten a Java, lugar donde AOP está implementado de forma horrenda a mi
parecer. Python provee los decoradores, y con ellos AOP se vuelve natural,
hermoso... los decoradores no resuelven todos los problemas planteados por
AOP, pero sí una gran mayoría.

Me encantaría un texto que muestre AOP a full sobre python, no sólo
decoradores. ¿alguien conoce?
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20100923/a991f9ac/attachment.html>