¿Hay algún Principio de Clojure?

Question

1. ¿Hay algún principio para Clojure?

   a. Al igual que el S.O.L.I.D. Object-Oriented Design Principles para lenguajes OO como Java?

   b. u otros más heurísticos, como "No preguntar", "Favorecer la composición frente a la herencia", "Hablar con interfaces"?

2. ¿Hay algún patrón de diseño (para código flexible)?

3. ¿Cuál es la contraparte básica de la programación funcional como encapsulación para orientado a objetos?

¿Conoces algún recurso para estos?

Answer 1

1a) No sé de algo así, pero cada libro sobre FP hará algo así.

1b)

• "Favor Composición vs herencia" -> Ya se cuida porque usted comenzó con FP

• "hablar con abstracciones" -> más general

• "ser perezoso cuando se puede"

• "evitar el estado"

• "¡¡¡Utiliza PURE FUNCTIONS !!!"

• elemento de la lista

....

2.) Puede utilizar algunos de los mismos algunos patrones de diseño que sólo son mucho más fáciles de implementar. Algunos de ellos tienen menos sentido, pero normalmente. La gente de FP no hace gran cosa con eso. (Esto se trata de patrones GoF solo los conozco)

Mire el patrón-observador por ejemplo. En Clojure puedes usar la función add-watcher para hacer obsoleto el patrón de observación.

3.) Puede usar la encapsulación en los espacios de nombres, busque defn, o puede ocultar su función en otras funciones. En la Alegría de Clojure hay algunos ejemplos. Puedes empujarlo tan lejos como quieras.

Answer 2

Pregunta difícil.

Clojure es muy flexible. Por lo tanto, son las mejores prácticas, pero no son tan importantes como para Java.

Escribo aquí algunos ejemplos de consejos de las familias más generales a las más particulares.

Hay consejos para la programación en general: escribir un montón de pruebas, escribir algo correcto y agradable, el perfil y optimizar cuando sea necesario

Hay consejos para la programación funcional: escribir funciones pequeñas, escribir funciones puras, componga las funciones pequeñas, factorice su código a través de las funciones, intente usar combinadores cuando sea posible ...

Hay consejos para LISP: utilice macro para factorizar patrones repetitivos, construya su programa de abajo hacia arriba. (Véase Paul Graham 'en LISP' para una explicación mejor que la mía)

También hay algunos consejos específicamente para Clojure: siguen el análisis cuidadoso de estado e identidad (http://clojure.org/state, para una explicación muy buena), trata de usar SEQs y sus funciones cuando sea posible, escribir cadenas de documentación para las funciones

una buena fuente para más consejos son la Biblioteca Clojure codificación estándar http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Standards

Pero todos estos consejos son sólo consejos, y Clojure puede ser utilizado por alguien que no quiero seguir estos consejos, porque, como un Lisp, es muy fle Xible.

En lo que respecta al patrón de diseño, el programador funcional rara vez piensa en estos términos, ya que la mayoría de ellos se han diseñado para lenguajes OO y no se aplican en un lenguaje funcional.

Peter Norvig tiene toboganes interesantes sobre patrones de diseño y LISP/Dylan: http://norvig.com/design-patterns/

Espero que ayude.

Answer 3

A su primera pregunta: no. ^†

Clojure está aquí para ayudarte a hacer las cosas bien, rápido y agradable. Todo después de eso es salsa.

Y hay mucha salsa. No pretendo saber la forma en Clojure, incluso si hay uno, pero aquí hay algunas pautas que han dicho y he descubierto al escribir en Clojure:

1. primer lugar, conseguir algo de trabajo. Luego puede examinar, probar y optimizar si es necesario. Hay una razón por la cual la macro time está en el lenguaje central. Corrección antes de la rapidez, para ser lindo.

2. Resumen. Si se repite usted mismo, probablemente no lo está haciendo bien. Componer, curry y combinar funciones.

3. Separar los efectos secundarios de su lógica. p.ej. si desea formatear y guardar una cadena, formatéela en una función, luego use otra función para guardarla, como sea necesario.

3a. No te vuelvas loco con esto.A veces es mejor tener algunas funciones anónimas que un montón de una sola línea defn s ensuciar tu código.

5. Prueba. Rich te dio un REPL por una razón; utilizar el infierno de ese REPL.

6. No rellene su espacio de nombre. Estamos limpios en Clojure-land. Califique su use o use :only lo que necesita. Haz que tu código sea legible

7. Conozca la biblioteca central. No solo clojure.core, sino clojure.java.io, clojure.string, clojure.set y todo lo demás. Si crees que Clojure debería tener una función para hacer X, probablemente sí lo haga. Puede usar apropos (desde, sí, otra biblioteca central: clojure.repl).

8. Documente su código. Las cadenas de documentos son una cosa hermosa. Si tiene tendencia a ser prolijo, el doctorado es el lugar para soltarse. Pero, sepa también que el buen código a menudo "se documenta a sí mismo". Si el código es autoexplicativo, no hay necesidad de ser pedante.

9. Este es un lenguaje funcional. Cuando pueda, use una función. Los protocolos, macros y registros son geniales: pero cuando puede salirse con la suya, use una función. Puede componer, combinar, mapear, reducir, iterar (la lista sigue y sigue y sigue ...) funciones. Eso es muy agradable.

10. Sobre todo, rompa las reglas anteriores si tiene sentido. Pero prepárate para repensar y refactorizar. Si ha mantenido su código lo suficientemente modular, refactorizar su código debería ser una cuestión de reorganización y recombinación.

Algunos otros consejos: lea el código de otras personas. Si comienzas a leer el código y te vuelves bueno leyendo el código, serás mejor escribiendo el tuyo, y es probable que también aprendas cosas nuevas: hay más de una manera de hacer casi todo.

Finalmente, lea el Clojure Library Coding Standards para tener una idea de lo que se espera en el código Clojure de producción.

† Al menos, todavía no.

Answer 4

hay un post en un blog mencionar "pensar en clojure" here y le da algunos consejos para el libro La alegría de Clojure, y para algunos otros libros (e incluso enlaces a algunos vídeos)

ahora, Tengo el libro The Joy Of Clojure, leo un poco y promete enseñarme "The Way Of Clojure". Espero que resulte diciéndome lo que estoy buscando, algunos principios ...

este libro es el trabajo de progreso pero se puede comprar una "edición de acceso anticipado" de la dotación here y obtener el 40% de la con el código "s140 ". ver información here

Answer 5

Do not Repeat Yourself (DRY) principal se aplica muy bien a clojure. El lenguaje es muy flexible y realmente promueve las abstracciones de composición en formas que realmente pueden reducir la cantidad de código de lugar de la caldera muy cerca de cero.

algunos ejemplos de formas de eliminar el código duplicado son:

• sólo utilizan perezoso-contras cuando se generan datos original donde no hay variante del mapa va a hacer. Si encuentra su auto escritura (lazy-seq (cons (do-something data) (call-myself (rest data))), verifique si map o iterate hará lo que quiera.
• usa pequeñas funciones y compórtalas generosamente. si una función necesita formatear algunos datos, envuélvala en XML y envíela a través de una red. escríbalos en tres pequeñas funciones y luego use (def send-formated-xml (comp send xml format)) de esta forma puede mapear la función de formateo en algunos datos posteriores, etc.
• cuando el lenguaje no puede expresar su patrón repetido, use una macro. Es mejor * usar un macro que repetir tu auto. y recuerda siempre que la primera regla del macro club es no usar una macro.

Answer 6

This video presenta los principios SÓLIDOS y cómo aplicarlos en Clojure.

Muestra cómo estos principios se mantienen tanto en el mundo funcional como en OOP, porque todavía tenemos que resolver los mismos problemas subyacentes. En general, me hizo pensar que la Programación Funcional es más adecuada para el diseño SOLIDO.