Архитектура функционального программирования
То же самое, но красивее:
extension Date {
func allDates(till endDate: Date) -> [Date] {
var date = self
var array: [Date] = []
while date <= endDate {
array.append(date)
date = Calendar.current.date(byAdding: .day, value: 1, to: date)!
}
return array
}
}
Как получить все даты на следующие 20 дней:
if let date = Calendar.current.date(byAdding: .day, value: 20, to: Date()) {
print(Date().allDates(till: date))
}
6 ответов
Общая нить в "архитектуре" проектов, которые используют функциональные языки, - то, что они имеют тенденцию быть разделенными на слои алгебры, а не подсистем в традиционном системном смысле архитектуры.
Для ярких примеров таких проектов, проверьте XMonad, Yi, и HappS. Если Вы исследуете, как они структурированы, Вы найдете, что они включают слои одноместной структуры с небольшим количеством промежуточного связующего звена combinator.
Также взгляд бумага Эксперимента Scala, которая обрисовывает в общих чертах архитектуру, где система состоит из компонентов что краткий обзор по их зависимостям.
Самая большая общность, которую Вы найдете на функциональных языках, использует функции, чтобы хранить данные. Это немного похоже на функции средства доступа использования на объекте без объекта. Вместо этого функция создается в среде, где она имеет доступ к данным, ей нужно. Теперь эта функция может передаваться и использоваться где угодно и все еще сохранить способность использовать данные.
Вот очень простой пример. Это не чисто функционально, поскольку это действительно изменяет состояние, но это достаточно распространено:
(define (make-counter)
(let ((count 0))
(lambda ()
(set! count (+ count 1))
count)))
(define x (make-counter))
(x) returns 1
(x) returns 2
...etc...
, Таким образом, у нас есть функция, делать-счетчик, который возвращает другую функцию, которая имеет состояние счетчика внутри. Мы можем назвать тот недавно созданный счетчик и наблюдать изменение внутри.
Это - то, как структурированы функциональные программы. У Вас есть функции, которые берут функции в качестве аргументов, у Вас есть функции, которые возвращают функции со скрытым состоянием и т.д. Это весь намного более чисто, чем руководящая память самостоятельно.
Я распечатал и просмотрел Шаблоны разработки в Ocaml, и они используют модули и функторы (и объекты) для воссоздания нормальных шаблонов разработки, к которым мы привыкли. Это интересно, но я думаю, что они используют объекты также очень для реального наблюдения преимущества функциональных языков. FP очень компонуем, часть, он - природа. Я предполагаю, что мой короткий ответ должен использовать модули и функторы .
Мой текущий проект является довольно большим, и мы разделяем каждый модуль файлами - неявный в ocaml. Я искал для всестороннего ресурса также, который мог бы иметь некоторые альтернативные представления или некоторые мысли о действительно успешном дизайне, который вышел из проекта.
Надо надеяться, не слишком тангенциальный, но вероятно интересный для любого просматривающего ответы на этот вопрос это представление Шаблоны разработки в Динамическом программировании Peter Norvig.
Я думаю, что это может помочь;
Некоторые шаблоны исчезают - то есть, они поддерживаются непосредственно функциями языка, некоторые шаблоны более просты или имеют различный фокус, и некоторые чрезвычайно неизменны.
[AIM-2002-005] Gregory T. Sullivan, Усовершенствованные Функции Языка программирования Исполняемых Шаблонов разработки "Лучшие Шаблоны Посредством Отражения
22 марта 2002
книга [GOF95] Шаблонов разработки представляет 24 испытанных шаблона, которые последовательно появляются в хорошо разработанных программных системах. Каждому шаблону дарят описание проблемы проектирования адреса шаблона, а также демонстрационный код реализации и конструктивные соображения. Данная статья исследует, как шаблоны от "Банды Четыре'', или "GOF'' книга, как это часто называют, появляются, когда подобные проблемы решаются с помощью динамического, языка объектно-ориентированного программирования высшего порядка. Некоторые шаблоны исчезают - то есть, они поддерживаются непосредственно функциями языка, некоторые шаблоны более просты или имеют различный фокус, и некоторые чрезвычайно неизменны.
Я работал с некоторыми довольно большими функциональными проектами. Они обычно попадают в два лагеря (по крайней мере, те я использовал):
- Экстремальная масштабируемость/надежность/параллелизм. Транзакционные модели могут быть созданы очень плотно на язык. Параллельный ML является ярким примером этого, и проекты, которые используют его, очень трудно понять превратно когда дело доходит до правильности параллелизма.
- платформы Парсинга/изменения. Многие шаблоны разработки, на основе которых эти платформы, невероятно легко сформулировать/создать/изменить на функциональных языках. Шаблон "посетитель" является ярким примером этого.