Существуют ли какие-либо принципы Clojure?

Question

1. Существуют ли какие-либо принципы для Clojure?

   а.Как SOLID Объектно-ориентированные принципы проектирования для ОО-языков, таких как Java?

   б.или другие, более эвристические, такие как «Скажи, не спрашивай», «Композиция избранного против наследования», «Разговор с интерфейсами»?

2. Существуют ли шаблоны проектирования (для гибкого кода)?

3. Какова противоположность базового функционального программирования, такого как инкапсуляция для объектно-ориентированного?

Знаете какие-нибудь ресурсы для этого?

Answer 1

На ваш первый вопрос: нет. ^†

Clojure здесь, чтобы помочь вам сделать все правильно, быстро и с удовольствием. Все после этого подливки.

И здесь много соуса. Я не берусь знать способ Clojure , даже если он есть, но вот некоторые рекомендации, которые мне сказали и открыли при написании в Clojure:

1. Во-первых, получите что-то работающее. Затем вы можете исследовать, тестировать и оптимизировать при необходимости. Есть причина, по которой макрос time написан на базовом языке. Правильность перед быстротой , чтобы быть милым.

2. Abstract. Если вы повторяете себя, вы, вероятно, делаете это неправильно . Составьте, карри и объединить функции.

3. Отдельные побочные эффекты от вашей логики . например если вы хотите отформатировать и сохранить строку, отформатируйте ее в одной функции, затем используйте другую функцию для ее сохранения, однако вам это необходимо.

3a. Не сходи с ума от этого. Иногда лучше иметь несколько анонимных функций, чем кучу однострочных defn, засоряющих ваш код.

5. Test. Рич дал вам ответ по причине; использовать черт из этого REPL.

6. Не загромождайте свое пространство имен . Мы чисты в Clojure-стране. Укажите ваши use или используйте :only, что вам нужно. Сделайте ваш код читабельным.

7. Знать базовую библиотеку . Не только clojure.core, но clojure.java.io, clojure.string, clojure.set и все, что между ними. Если вы думаете, что у Clojure должна быть функция для выполнения X, это, вероятно, имеет. Вы можете использовать apropos (из другой базовой библиотеки: clojure.repl).

8. Документируйте свой код . Струны для документов прекрасная вещь. Если у вас есть склонность к многословности, доктрина - это место, где можно выпустить. Но знайте также, что хороший код часто «документирует себя». Если код не требует пояснений, нет необходимости быть педантичным.

9. Это функциональный язык. Когда вы можете, используйте функцию . Протоколы, макросы и записи - это здорово, но когда вам это сойдет с рук, используйте функцию. Вы можете составлять, объединять, отображать, сокращать, выполнять итерации (список можно продолжать, продолжать и продолжать). Это действительно хорошо.

10. Прежде всего, нарушает вышеуказанные правила, если это имеет смысл . Но будьте готовы к переосмыслению и рефакторингу. Если вы сохранили свой код достаточно модульным, рефакторинг вашего кода должен быть вопросом реорганизации и рекомбинации.

Некоторые другие советы: читайте чужой код. Если вы начнете читать код и научитесь читать код, вы станете лучше писать свои собственные, и вы, вероятно, тоже узнаете что-то новое: есть несколько способов сделать практически все.

Наконец, прочитайте Стандарты кодирования библиотеки Clojure , чтобы получить представление о том, что ожидается от производственного кода Clojure.

† По крайней мере, пока.

Answer 2

Сложный вопрос.

Clojure очень гибкий. Так что это лучшие практики, но они не так важны, как для Java.

Я пишу здесь несколько примеров советов от самых общих до самых конкретных семейств.

Есть советы по программированию в целом: написать много тестов, написать что-то правильное и красивое, профилировать и оптимизировать при необходимости

Есть советы по функциональному программированию: писать небольшие функции, писать чистые функции, составлять небольшие функции, анализировать ваш код через функции, пытаться использовать комбинаторы, когда это возможно ...

Есть советы для LISP: используйте макрос, чтобы выделить повторяющиеся шаблоны, создайте вашу программу снизу вверх. (Более подробное объяснение, чем у меня, см. В книге Пола Грэма о LISP)

Есть также несколько советов специально для Clojure: следуйте тщательному анализу состояния и идентичности (http://clojure.org/state, для очень хорошего объяснения), старайтесь по возможности использовать seqs и их функции, пишите строки документов для функций

Хорошим источником дополнительных советов является стандарт кодирования библиотеки Clojure. http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Standards

Но все эти советы - просто советы, и Clojure может использовать тот, кто не хочет следовать этим советам, потому что, будучи Лиспом, он очень гибок.

Что касается шаблона проектирования, то функциональные программисты редко думают об этих терминах, так как большинство из них были разработаны для ОО-языков и не применяются на функциональном языке.

У Питера Норвига есть интересные слайды по шаблонам проектирования и LISP / Dylan: http://norvig.com/design-patterns/

Надеюсь, это поможет.

Answer 3

Принцип Не повторяйся (СУХОЙ) очень хорошо подходит для замыкания.Язык очень гибкий и действительно способствует составлению абстракций способами, которые могут реально уменьшить количество кода рабочей области, очень близкого к нулю.

Вот некоторые примеры способов удаления дублированного кода:

• использовать ленивые минусы только при генерации исходных данных, когда ни один вариант карты не подойдет.Если вы обнаружите, что сами пишете (lazy-seq (cons (do-something data) (call-myself (rest data))), проверьте, будет ли map или iterate делать то, что вы хотите.
• использует небольшие функции и свободно их сочиняет.если функции необходимо отформатировать некоторые данные, оберните их в XML и отправьте по сети.напишите их в трех небольших функциях, а затем используйте (def send-formated-xml (comp send xml format)), чтобы вы могли отобразить функцию форматирования на некоторые данные позже и т. д.
• , когда язык абсолютно не может выразить ваш повторный образец, используйте макрос.Лучше * использовать макрос, чем повторять себя.и всегда помните первое правило макроклуба - не используйте макрос.

Answer 4

1a) Я не знаю ничего подобного, но каждая книга о ФП будет делать что-то подобное.

1b)

• «Композиция Favor vs Inheritance» -> уже позаботилась, потому что вы начали с FP

• "поговорить с абстракциями" -> более общее

• "будь ленив, когда сможешь"

• «избегать состояния»

• «Используйте PURE FUNCTIONS !!!»

• Элемент списка

....

2.) Вы можете использовать некоторые из тех же шаблонов проектирования, которые они гораздо проще реализовать. Некоторые из них имеют меньше смысла, но обычно. ФП люди не делают из этого большого дела. (Это про паттерны GoF, я их знаю только)

Посмотрите на шаблон наблюдателя, например. В Clojure вы можете использовать функцию add-watcher, которая делает шаблон наблюдателя устаревшим.

3.) Вы можете использовать инкапсуляцию в пространствах имен, посмотрите на defn- или можете скрыть свою функцию в других функциях. В Радости Clojure есть несколько примеров. Вы можете толкать его так далеко, как хотите.

Answer 5

В этом видео представлены принципы SOLID и способы их применения в Clojure.

В нем показано, как эти принципы действуют в функциональном мире в той же степени, что и в ООП, поскольку нам по-прежнему нужнырешить те же основные проблемы.В целом, это заставило меня думать, что функциональное программирование лучше подходит для дизайна SOLID.

Answer 6

в блоге есть пост, в котором упоминается «размышление в ближайшем будущем» здесь , и он дает некоторые ссылки на книгу «Радость Clojure» и некоторые другие книги (и даже ссылки на некоторые видео)

Теперь я получил книгу «Радость Clojure», немного ее прочитал, и она обещает научить меня «Пути Clojure». надеюсь, получится сказать, что я ищу, некоторые принципы ...

Эта книга - работа над ней, но вы можете купить "Раннюю версию" у Мэннинга здесь и получить 40% с кодом "s140". см. информацию здесь