Существуют ли какие-либо Принципы для Clojure?
а. Как S.O.L.I.D. Объектно-ориентированные принципы проектирования для языков OO, таких как Java?
б. или другие более эвристические, например "Tell do not ask", "Favor Composition vs Inheritance", "Talk to Interfaces"?
Существуют ли шаблоны проектирования (для гибкого кода)?
Что такое счетная часть базового функционального программирования, например инкапсуляция для объектно-ориентированного?
Знайте о каких-либо ресурсах для них?
К вашему первому вопросу: нет. †
Clojure здесь, чтобы помочь вам сделать все правильно, быстро и приятно. Все после этого подливается.
И там много соуса. Я не предполагаю знать способ Clojure, даже если он есть, но вот некоторые рекомендации, которые мне рассказали и обнаружили при записи в Clojure:
Сначала сделайте что-нибудь работающее. Затем вы можете проверить, проверить и оптимизировать, если необходимо. Там есть причина, что макрос time находится на основном языке. Правильность перед быстротой, чтобы быть симпатичной.
Абстрактный. Если вы повторяете себя, вы, вероятно, не делаете этого правильно. Составление, карри и комбинирование функций.
Отдельные побочные эффекты из вашей логики. например если вы хотите отформатировать и сохранить строку, отформатируйте ее в одной функции, а затем используйте другую функцию для ее сохранения, однако вам нужно.
3a. Не сходите с ума. Иногда лучше иметь несколько анонимных функций, чем пучок из одной строки defn, засоряющий ваш код.
Test. Рич дал вам REPL по какой-то причине; используйте ад из этого REPL.
Не загромождайте пространство имен. Мы чисты в Clojure -land. Подтвердите свой use или используйте :only, что вам нужно. Сделайте код доступным для чтения.
Знать основную библиотеку. Не только clojure.core, но clojure.java.io, clojure.string, clojure.set и все между ними. Если вы считаете, что Clojure должен иметь функцию для выполнения X, это, вероятно, делает. Вы можете использовать apropos (от, да, другую основную библиотеку: clojure.repl).
Документируйте свой код. Докстеллы - прекрасная вещь. Если у вас есть склонность быть многословным, то доктрина является местом, где можно освободиться. Но, хорошо знаю, что хороший код часто "сам документирует". Если код не требует пояснений, нет необходимости быть педантичным.
Это функциональный язык. Если вы можете, используйте функцию. Протоколы, макросы и записи - все отлично, но когда вы можете с ним справиться, используйте функцию. Вы можете создавать, комбинировать, сопоставлять, уменьшать, итерировать (список продолжается, и дальше, и на...). Это действительно приятно.
Прежде всего, разорвать вышеуказанные правила, если это имеет смысл. Но будьте готовы переосмыслить и реорганизовать. Если вы сохранили свой код достаточно модульно, рефакторинг вашего кода должен быть реорганизацией и рекомбинацией.
Некоторые другие советы: прочитайте код других людей. Если вы начнете читать код и будете хорошо читать код, вы станете лучше писать свои собственные, и вы, вероятно, тоже научитесь чему-то новому: есть более чем один способ сделать практически все.
Наконец, прочитайте, Clojure Стандарты кодирования библиотек, чтобы получить представление о том, что ожидается в коде Clojure.
† По крайней мере, пока нет.
Жесткий вопрос.
Clojure очень гибкий. Поэтому они - лучшие практики, но они не так важны, как для java.
Я пишу здесь несколько примеров советов от наиболее общих к наиболее конкретным семействам.
Есть рекомендации для программирования в целом: написать много тестов, написать что-то правильное и приятное, профиль и оптимизировать при необходимости
Есть рекомендации по функциональному программированию: писать небольшие функции, записывать чистые функции, составлять небольшие функции, кодировать код через функции, стараться использовать комбинаторы, когда это возможно...
Есть советы для LISP: использовать макрос, чтобы разделить повторяющиеся шаблоны, построить свою программу снизу вверх. (См. Paul Graham 'on LISP' для лучшего объяснения, чем мое)
Также есть несколько советов для Clojure: следуйте тщательному анализу состояния и идентичности (http://clojure.org/state, за очень хорошее объяснение), попробуйте использовать seqs и их функции, когда это возможно, написать строки документа для функций
Хорошим источником дополнительных советов является Clojure Стандарт кодирования библиотек http://www.assembla.com/wiki/show/clojure/Clojure_Library_Coding_Standards
Но все эти советы - это просто советы, а Clojure может использоваться кем-то, кто не хочет следовать этим советам, потому что, как Lisp, он очень гибкий.
Что касается шаблона проектирования, функциональный программист редко думает в этих терминах, так как большинство из них предназначено для языков OO и не применяется на функциональном языке.
Питер Норвиг имеет интересные слайды в Design Pattern и LISP/Dylan: http://norvig.com/design-patterns/
Надеюсь, что это поможет.
1a) Я не знаю ничего подобного, но каждая книга о FP будет делать что-то подобное.
1b)
"Поддержка композиции и наследование" → уже позаботились о том, что вы начали с FP
"говорить с абстракциями" → более общий
"ленитесь, когда сможете"
"избегать состояния"
"Используйте ЧИСТЫЕ ФУНКЦИИ!!!"
Элемент списка
....
2.) Вы можете использовать некоторые из тех же шаблонов проектирования, которые они намного проще реализовать. Некоторые из них имеют меньше смысла, но обычно. Люди FP не делают большой сделки из этого. (Это касается шаблонов GoF, которые я знаю только)
Посмотрите на шаблон наблюдателя, например. В Clojure вы можете использовать функцию add-watcher, чтобы сделать шаблон наблюдателя устаревшим.
3.) Вы можете использовать инкапсуляцию в пространствах имен для поиска defn- или вы можете скрыть свою функцию в других функциях. В Радости Clojure приведены некоторые примеры. Вы можете нажать его, насколько хотите.
Принцип Не повторяй себя (DRY) очень хорошо подходит для clojure. Язык очень гибкий и действительно способствует составлению абстракций способами, которые могут действительно уменьшить количество кода котельного места очень близко к нулю.
Некоторые примеры способов удаления дублированного кода:
(lazy-seq (cons (do-something data) (call-myself (rest data))), проверьте, будет ли map или iterate делать то, что вы хотите.(def send-formated-xml (comp send xml format)) таким образом, вы можете отобразить функцию формата на некоторые данные позже и т.д.Это видео содержит принципы SOLID и их применение в Clojure.
Это показывает, как эти принципы сохраняются в функциональном мире так же, как и в ООП, потому что нам все еще нужно решать одни и те же основные проблемы. В целом, это заставило меня думать, что функциональное программирование лучше подходит для дизайна SOLID.
есть запись в блоге, в которой упоминается "мышление в clojure" здесь, и в нем приводятся некоторые указатели на книгу" Радость Clojure, а также на некоторые другие книги (и даже ссылки на некоторые видеоролики)
Теперь я получил книгу The Joy Of Clojure, немного прочитал ее, и promises научил меня "Путь clojure". надеюсь, что выяснится, что я скажу, что я ищу, некоторые принципы...
Эта книга работает, но вы можете купить "версию раннего доступа" из manning здесь и получить 40% кода с кодом "s140". см. информацию здесь