c# - dofactory - gof design patterns

Patrones para mezclar F#y C#en la misma solución

Question

Estudié algunos idiomas funcionales, principalmente con fines académicos. Sin embargo, cuando tengo que proyectar una aplicación cliente-servidor siempre comienzo a adoptar un Diseño Dirigido por Dominio, estrictamente OOP.

Una solución compleja escrita en .Net Framework podría obtener ventajas al utilizar más que un lenguaje y, a veces, más que un paradigma. Mezclar C o C ++ con LUA o Python es una práctica común, a veces incluir prólogo puede ser muy interesante. Nunca intenté mezclar OOP y el paradigma funcional.

F # es un nuevo lenguaje funcional y orientado a objetos, veo que es técnicamente muy fácil mezclar C # con bibliotecas F # en la misma solución. Pero me pregunto si tiene algún sentido: utilizo LINQ para satisfacer muchos de mis requisitos funcionales.

¿Cuándo y cómo cree que es una buena idea mezclar estos dos idiomas? Me pregunto si existe un conjunto de patrones que lo intente.

¿Usas realmente F # en una solución C #?

Answer 1

Escribí un servicio de WCF en F # que actúa como complemento de un traductor para leer un servicio WFS (datos geoespaciales). El código resultó agradable y conciso.

Mientras que el dll autónomo que compilé funcionaba bien dentro de la solución C # de mi colega, intentó estrangularme cuando le mostré el código. Choque cultural, creo.

Entonces, ¿utilizamos F # y C # en el mismo proyecto? Si y no. No, porque reescribí la cosa en C #. Sí, porque construir y probar el prototipo en F # me ahorró más tiempo del que me llevó traducirlo al estilo C # LINQ.

No quisiera intentar crear todo en F #, pero estoy esperando pacientemente el día en que pueda trabajar en el procesamiento de datos / parte algorítmica de una solución de lenguaje mixto en F # sin temer por mi vida.

Answer 2

Hay ciertos lugares donde las técnicas funcionales tradicionales tienen mucho sentido y conducen a un código que es tanto más pequeño como más conciso. Un ejemplo clásico es el análisis de texto y el procesamiento de árbol, que a menudo aparecen juntos cuando se implementa un DSL. Las características de F #, como los iteradores anónimos, la coincidencia de patrones ampliables y la capacidad de definir operadores de infix personalizados para que sirvan como combinadores realmente ayudan mucho aquí. Mientras tanto, en el lado C #, LINQ es un buen comienzo, pero no te lleva todo el camino hasta allí.

Sugiero que eche un vistazo a FParsec , y vea por usted mismo qué tan apropiado es para el procesamiento / análisis avanzado de texto que cualquier biblioteca que pueda escribir en C #.

Answer 3

Los idiomas son solo una herramienta. Al igual que Luke, soy un gran fan de usar la herramienta adecuada para el trabajo. Si una aplicación en particular se beneficia con el uso de C # y F #, entonces la mezcla me parece razonable.

En cuanto a cómo hacerlo, ver:

¿Puedes mezclar lenguajes .net dentro de un solo proyecto?

En pocas palabras: puede unir dos archivos DLL que utilizan diferentes idiomas en una sola DLL como paso posterior a la creación. O bien, puede usar varios idiomas en un sitio web compilado en el servidor.

Answer 4

Me hiciste pensar y traté de decidir dónde lo haría. Hay dos situaciones que vienen a la mente:

1. Si estoy haciendo un proyecto de castillo (MVC) probablemente tendría controladores en C # mientras todos los BL y los modelos están en F # (tiendo a hacer un diseño impulsado por dominio y cableo el BL a los modelos, o a través de componentes inyectados [ala DI] )
2. Comenzar un nuevo proyecto pero incorporando bibliotecas existentes para no reinventar la rueda.

Además, soy un gran defensor de la "herramienta adecuada para el trabajo", por lo que si creo que uno u otro sería mejor, lo usaría.

Answer 5

Sí, en el futuro creo que debemos combinar estos tipos de lenguajes como OOP (C #) con lenguaje funcional (F #) para aprovechar el procesamiento multinúcleo. C # 4 tiene clases para apoyar esto, pero algunas cosas se hacen mejor en F #.

Answer 6

Tenemos una aplicación que obtiene toda su funcionalidad cargando partes de MEF . La mayoría de las partes están escritas en C #, pero hay una parte que procesa datos binarios y está escrita en F #. En este caso, F # fue simplemente más adecuado para el trabajo.

La parte F # se ajusta a una interfaz definida en C # y la aplicación C # no tiene idea de que se trata de una parte F # (que no sea la dependencia de fsharp.dll).

Por supuesto, esto no solo se aplica a F #, si alguien quiere escribir o reescribir una parte (complemento, módulo, lo que sea que quiera llamar) en un idioma diferente, será recogido por MEF y proporcionado a nuestra aplicación sin ningún desventajas.

Elegimos el idioma que mejor se adapte para resolver un problema específico y MEF abstrae todos los detalles, por lo que no tenemos nada de qué preocuparse.

Answer 7

Todavía no lo he probado, pero un lugar donde seguramente me gustaría usar un lenguaje funcional, aunque no sea una razón para usarlo, es para poder evitar lo que se ha descrito aquí.

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Me gustaría simplemente nombrar esto como un verbo, y ejecutarlo

calculateSomething () en lugar de SomtingCalculator.Execute ()

Answer 8

Uso F # para la programación exploratoria en mis soluciones de C #. Por ejemplo, enciendo mi aplicación C # WPF a través de la consola interactiva F # de los estudios visuales y busco en la aplicación en ejecución. Puede ahorrarte muchas sesiones de edición-compilación-depuración.