2011-04-06 27 views

Respuesta

13

AOP IMHO es solo un artefacto de ciertos tipos de lenguajes de programación estáticos. AFAIKS usualmente son solo un montón de extensiones de compiladores no estándar. Todavía no he visto ninguna aplicación de AOP que no se pueda resolver mejor & de forma nativa en idiomas más dinámicos. Clojure es ciertamente lo suficientemente dinámico, y eso sin considerar siquiera las macros.

Puedo estar equivocado, pero si es así, necesitaría ver un caso de uso de AOP real que no se puede implementar tan bien en Clojure puro.

Editar: para que quede claro: me niego a ver cosas como el asesoramiento de elisp como orientado a aspectos. En los lenguajes dinámicos, esas son solo técnicas para usar cuando las necesite, sin necesidad de soporte de idiomas que no sea el reencuadernación de las definiciones de funciones, que todos los cefaleas admiten de todos modos.

No hay necesidad de tratarlos como especiales: usted puede definir fácilmente su propia función estilo de desconexión en clojure. Ver por ejemplo, compojure's wrap! macro, que en realidad está en desuso, ya que generalmente ni siquiera lo necesita.

+2

Es un poco raro decir macros son dinámicos, ya que siguen en tiempo de compilación (que son ganchos en el compilador). Cuando cambia una macro, necesita volver a compilar todo el código que la llama. No muy dinámico en mi libro ... – Marek

+2

Además, AOP está íntimamente relacionado con MOP, el protocolo de metaobjetos de Common Lisp (también Pascal Constanza es famoso por defender AOP para CL). ¿Crees que Common Lisp también es estático? Esta respuesta parece ser una colección aleatoria de conjeturas (no) educadas ... – Marek

+1

Creo que esta respuesta parece implicar (para alguien que no está bien versado en Clojure) que Clojure de alguna manera elimina las preocupaciones transversales sin ningún esfuerzo adicional. La respuesta de mikera es mucho más clara con respecto a esto y también incluye ejemplos, creo que esta debería ser la respuesta aceptada. El hecho de que esa respuesta y su ejemplo también ponen de relieve algunas dificultades solo lleva a la conclusión de que las preocupaciones AOP/transversales (por cualquier otro nombre) no se resuelven automáticamente en Clojure. – Sprague

11

La programación orientada a aspectos es una excelente manera de lograr separación de concernes en Java. Las abstracciones compostables de Clojure logran esto muy bien. Ver this question también. El tema está cubierto muy bien en The Joy Of Clojure.

como un ejemplo de Orientada a Aspectos Clojure por otro nombre revisar el marco Web Anillo

20

Programación Orientada a Aspectos se suele utilizar para agregar funcionalidad transversal al código que de otra forma serían irremediablemente entrelazados con la lógica de negocio. Un gran ejemplo es el registro: realmente no desea el código de registro disperso en todas partes en su código base.

Realmente no necesita AOP en Clojure porque es fácil de lograr con otras técnicas en Clojure.

Por ejemplo, se puede utilizar de orden superior las funciones de "envolver" otras funciones con funcionalidad transversal:

; a simple function - the "business logic" 
(defn my-calculation [a b] 
    (+ a b)) 

; higher order function that adds logging to any other function 
(defn wrap-with-logging [func] 
    (fn [& args] 
    (let [result (apply func args)] 
     (println "Log result: " result) 
     result))) 

; create a wrapped version of the original function with logging added 
(def my-logged-calculation (wrap-with-logging my-calculation)) 

(my-logged-calculation 7 9) 
=> Log result: 16 
=> 16 
+5

El problema con ese ejemplo, como una comparación con AOP, es que ahora el desarrollador debe invocar el nuevo método de contenedor en lugar del original. Idealmente, sería posible lograr el comportamiento de registro invocando el método original. Eso estaría más cerca de lo que ofrece AOP, ¿verdad? – jcrossley3

+7

@ jcrossley3 - siempre podría redefinir la función original con (def my-calculation (wrap-with-logging my-calculation)) si lo desea .... – mikera

+0

excelente punto! :) – jcrossley3

Cuestiones relacionadas