2012-03-01 9 views
5

Sé que uno de los objetivos de la programación funcional pura es eliminar la mutabilidad y, por lo tanto, evitar los efectos secundarios. Pero admitámoslo, Java no es un lenguaje funcional incluso con todas las bibliotecas de programación funcional que existen. De hecho, parece que algunas de las bibliotecas de FP saben y esperan esto. Por ejemplo, en Java funcional, existe la clase Effect. En la biblioteca de Jedi FP, existe la interfaz Command. Esto le permite, entre otras cosas, aplicar un patrón de comando con seguridad de tipo a los elementos de un Iterable sin la repetitiva repetición for loop.¿Algo en Guava similar al efecto funcional de Java?

Command<PhoneNumber> makeCall = new Command<PhoneNumber> { 
    public void execute(PhoneNumber p) { p.call(); } 
} 
List<PhoneNumber> phoneList = ... 
FunctionalPrimitives.forEach(phoneList, makeCall); 

Entonces la pregunta es, ¿hay algo así en Guava?

editar después de respuesta aceptada CLARIFICACIÓN

Estoy desarrollando un framework que ayuda con el "problema vertical" inherente a la mayoría de Java FP-bibliotecas, bajo un determinado conjunto de circunstancias. Así que no realmente hace el ejemplo del código como se muestra arriba: es decir, explícitamente declara una nueva implementación de clase de Command con toda su malicia de ruido vertical, simplemente con el propósito de aplicarla inmediatamente después de la declaración.

Estaba pensando más en la línea del patrón de comando real, donde puede haber varios comandos posibles declarados en otro lugar, y solo uno de ellos se pasa al código que quiere aplicarlo iterativamente. Además, el objetivo de mi framework es hacerlo más idiomático para crear objetos de interfaz funcional (funciones, predicados, comandos, otras lambdas simples) sin simplemente mover el problema vertical a otra parte. Hace tiempo que me di cuenta de que esto no está dentro del alcance de la guayaba. Pero como la interfaz tipo Comando está disponible en otras bibliotecas FP, solo quería saber si existía un análogo en Guava.

Un ejemplo de código más completo, usando mi marco, podría ser algo como esto:

class Stuff { 
    private final Stuff CALLS_TO = callsTo(Stuff.class); // a proxy 
    public static final Command<Stuff> CMD1 = commandFor(CALLS_TO.someMethod1()); 
    public static final Command<Stuff> CMD2 = commandFor(CALLS_TO.someMethod2()); 

    // methods exist for use elsewhere, but are conveniently also wrapped as commands 
    public void someMethod1() {...} 
    public void someMethod2() {...} 
} 

class Activity { 
    public void handleIt(List<Stuff> stuffs, Command<Stuff> doCmd) { 
     doSomeThings(); 
     ... 
     forEach(stuffs, doCmd); 
     ... 
     doOtherThings(); 
    } 
} 

Respuesta

10

No!

Kevin Bourrillion, el líder del proyecto de guayaba, ha dicho sobre las características funcionales de la guayaba:

“La sintaxis chupa. Al mismo tiempo, esto es ahora, siempre ha sido y siempre será una medida provisional hasta que se produzca el cambio de idioma correcto, momento en el que finalmente podemos decidir la sintaxis óptima y comenzar la programación de estilo funcional en realidad, mejorar vidas en Java por una vez. Así que estoy indeciso sobre cuánto esfuerzo poner en las funciones/predicar cosas; está en la biblioteca más porque tiene que ser así, no tanto porque creemos que es una joya de la corona. "

Probablemente cambiemos significativamente nuestra estrategia cuando Java 8 aparezca, pero eso no será posible. por un tiempo todavía.

Además, no hemos encontrado muchos casos de uso para los que creemos que la interfaz Command que describes sería la mejor solución. Por ejemplo, creemos que su código anterior sería mucho mejor escrito como

for(PhoneNumber phone : phoneList) { 
    phone.call(); 
} 

a la antigua usanza. Podríamos estar convencidos del mérito de Command, pero creo que el caso de uso "para-cada" casi siempre está mejor hecho a la antigua.

+1

¿Por qué es la forma "pasada de moda" mejor para los comandos, pero no mejor para los filtros y las transformaciones? Además, sé que las características funcionales se ven como stop gap hasta Java 8, pero hay que darse cuenta de que Java 8 está fuera de tiempo, y su adopción no será inmediata. Todavía hay proyectos atascados en Java 5 (afortunadamente, no míos). –

+0

Si lees [la guía del usuario] (http://code.google.com/p/guava-libraries/wiki/FunctionalExplained#Caveats), verás que pensamos que la forma tradicional es mejor para los filtros y transformaciones la mayor parte del tiempo. No todo el tiempo, por eso brindamos esas características, pero la mayoría de las veces. –

+0

Además, el código de la publicación original parece ser un ejemplo de lo que hace que [llore el equipo de Guava] (http://code.google.com/p/guava-libraries/wiki/FunctionalExplained). –

Cuestiones relacionadas