Заменяет ли функциональное программирование шаблоны проектирования GoF?
Вот как я решил это в своем приложении. В идеале вы должны использовать StringBuilder вместо использования + для строк.
String inParenthesis = "(?";
for(int i = 1;i < myList.size();i++) {
inParenthesis += ", ?";
}
inParenthesis += ")";
try(PreparedStatement statement = SQLite.connection.prepareStatement(
String.format("UPDATE table SET value='WINNER' WHERE startTime=? AND name=? AND traderIdx=? AND someValue IN %s", inParenthesis))) {
int x = 1;
statement.setLong(x++, race.startTime);
statement.setString(x++, race.name);
statement.setInt(x++, traderIdx);
for(String str : race.betFair.winners) {
statement.setString(x++, str);
}
int effected = statement.executeUpdate();
}
Использование переменной типа x выше вместо конкретных чисел помогает много, если вы решите изменить запрос позже.
13 ответов
Сообщение в блоге, которое Вы заключили в кавычки, преувеличивает свое требование немного. FP не делает , устраняют потребность в шаблонах разработки. Термин "шаблоны разработки" просто широко не используется для описания того же самого на языках FP. Но они существуют. Функциональные языки имеют много правил лучшей практики формы, "при обнаружении с проблемой X используйте код, который похож на Y", который является в основном, каков шаблон разработки.
Однако это корректно, что САМЫЕ ОПРЕДЕЛЕННЫЕ ДЛЯ ООП шаблоны разработки в значительной степени не важны на функциональных языках.
я не думаю, что это должно быть особенно спорно, чтобы сказать, что шаблоны разработки в общем только существуют для исправления недостатков на языке. И если другой язык может решить ту же проблему тривиально, что другой язык не будет иметь потребности шаблона разработки для него. Пользователи того языка даже не могут знать, что проблема существует , потому что, ну, в общем, это не проблема на том языке.
Вот то, что Банда Четыре должна заявить об этой проблеме:
выбор языка программирования важен, потому что это влияет на точку зрения. Наши шаблоны принимают Smalltalk/C ++-level функции языка, и тот выбор определяет то, что может и не может быть реализовано легко. Если мы приняли процедурные языки, мы, возможно, включали шаблоны разработки под названием "Наследование", "Инкапсуляция" и "Полиморфизм". Точно так же некоторые наши шаблоны поддерживаются непосредственно менее общими объектно-ориентированными языками. CLOS имеет мультиметоды, например, которые уменьшают потребность в шаблоне, таком как Посетитель. На самом деле существует достаточно различий между Smalltalk и C ++, чтобы означать, что некоторые шаблоны могут быть выражены более легко на одном языке, чем другой. (См. Итератор, например.)
(Вышеупомянутое является кавычкой от Введения до книги Шаблонов разработки, страницы 4, абзаца 3)
основные функции функционального программирования включают функции как первоклассные значения, приправляющие карри, неизменные значения, и т.д. Для меня не кажется очевидным, что шаблоны разработки OO приближают любую из тех функций.
, Каков шаблон "команда", если не приближение первоклассных функций?:) На языке FP Вы просто передали бы функцию как аргумент другой функции. На языке ООП необходимо обернуть функцию в классе, который можно инстанцировать и затем передать тот объект другой функции. Эффект является тем же, но в ООП это назвало шаблон разработки, и требуется намного больше кода. И каков шаблон "абстрактная фабрика", не приправляя карри? Параметры передачи к функции понемногу, для конфигурирования, какое значение это выкладывает при окончательном вызове его.
Так да, несколько шаблонов разработки GoF представляются избыточные на языках FP, потому что более мощный и легче использовать альтернативы существуют.
, Но конечно существуют все еще шаблоны разработки, которые являются не решены языками FP. Что FP эквивалентен из одиночного элемента? (Игнорирующий на мгновение, что одиночные элементы обычно являются ужасным шаблоном для использования)
И он работает оба пути также. Как я сказал, FP имеет свои шаблоны разработки также, люди просто обычно не думают о них как таковой.
, Но Вы, возможно, натыкались на монады. Каковы они, если не шаблон разработки для "контакта с глобальным состоянием"? Это - проблема, это так просто на языках ООП, что никакой эквивалентный шаблон разработки не существует там.
Нам не нужен шаблон разработки для "инкремента, который статическая переменная", или "считала из того сокета", потому что это, что Вы делаете .
Высказывание Монады является шаблоном разработки, так же абсурдно, что Целые числа с их обычными операциями и нулевым элементом являются шаблоном разработки. Нет, Монада математический шаблон , не шаблон разработки.
На (чистых) функциональных языках, побочные эффекты и изменяемое состояние невозможны, если Вы не работаете вокруг этого с монадой "шаблон разработки" или любой из других методов для разрешения того же самого.
Кроме того, на функциональных языках, которые поддерживают ООП (такое как F# и OCaml), для меня кажется очевидным, что программисты, использующие эти языки, использовали бы те же шаблоны разработки, найденные доступными любому языку ООП. На самом деле прямо сейчас я каждый день использую F# и OCaml, и нет никаких поразительных различий между шаблонами, которые я использую на этих языках по сравнению с шаблонами, которые я использую, когда я пишу в Java.
, Возможно, потому что Вы все еще думаете обязательно? Большому количеству людей, после контакта с императивными языками все их жизни, нелегко разочаровываться в той привычке, когда они пробуют функциональный язык. (Я видел некоторые довольно забавные попытки F#, где буквально каждый функция была просто строкой операторов, которым 'позволяют', в основном как будто Вы взяли программу C и заменили все точки с запятой 'позволенным'.:))
, Но другая возможность мог бы быть то, что Вы просто не поняли решение проблем тривиально, которые потребовали бы шаблонов разработки на языке ООП.
, Когда Вы используете приправление карри, или передаете функцию как аргумент другому, остановке и думаете о том, как Вы сделали бы это на языке ООП.
там какая-либо истина к заявлению, что функциональное программирование избавляет от необходимости шаблоны разработки ООП?
Да.:), Когда Вы работаете на языке FP, Вам больше не нужны ОПРЕДЕЛЕННЫЕ ДЛЯ ООП шаблоны разработки. Но Вам все еще нужны некоторые общие шаблоны разработки, как MVC или другое не-ООП определенный материал, и Вам нужны несколько новых определенных для FP "шаблонов разработки" вместо этого. Все языки имеют свои недостатки, и шаблоны разработки обычно, как мы работаем вокруг них.
Так или иначе, можно найти интересным попробовать силы в "более чистых" языках FP, как ML (мой любимый, по крайней мере, для изучения целей), или Haskell, где у Вас нет опоры ООП для возвращений, когда Вы сталкиваетесь с чем-то новым.
<час>Как ожидалось, несколько человек, которым возражают против моего определения шаблонов разработки как "исправление недостатков на языке", таким образом, вот мое выравнивание: Как уже сказано, большинство шаблонов разработки характерно для одной парадигмы программирования, или иногда даже одного определенного языка. Часто, они решают проблемы, что [только 1 110] существуют в той парадигме (См. монады для FP или абстрактные фабрики для ООП). Почему шаблон "абстрактная фабрика" не существует в FP? Поскольку проблема, которую это пытается решить, не существует там. Так, если проблема существует на языках ООП, который не существует на языках FP, тогда ясно, который является недостатком языков ООП. Проблема может быть решена, но Ваш язык не делает так, но требует, чтобы набор шаблонного кода от Вас работал вокруг этого. Идеально, мы хотели бы, чтобы наш язык программирования волшебно сделал весь , проблемы уходят. Любая проблема, которая является все еще, существует в принципе недостаток языка.;)
Я думаю, что каждая парадигма служит различной цели, и как таковой не может быть сравнен таким образом.
я не услышал, что шаблоны разработки GoF применимы к каждому языку. Я услышал, что они применимы ко всему языки ООП . При использовании Функционального программирования тогда домен проблем, которые Вы решаете, отличается от языков OO.
я не использовал бы функциональный язык для записи пользовательского интерфейса, но одного из языков OO как C#, или Java сделает это задание легче. Если бы я писал функциональный язык тогда, то я не рассмотрел бы использование Шаблонов разработки OO.
Как другие сказали, существуют шаблоны, конкретные из функционального программирования. Я думаю, что проблемой избавления от шаблонов разработки не является так вопрос переключения на функциональный, но вопрос функции языка .
Смотрят на то, как Scala покончил с "шаблоном"одиночка"": Вы просто объявляете объект вместо класса. Другая функция, сопоставление с образцом, помогает предотвращению неуклюжего из шаблона "посетитель". Посмотрите сравнение здесь: http://andymaleh.blogspot.com/2008/04/scalas-pattern-matching-visitor-pattern.html
И Scala, как F#, является сплавом функциональных OO. Я не знаю о F#, но он, вероятно, имеет этот вид функций.
Закрытия присутствуют на функциональном языке, но не должны быть ограничены ими. Они помогают с delegator шаблоном.
Еще одно наблюдение. Эта часть кода реализует шаблон: это - такой классик, и это является столь элементным, что мы обычно не думаем о нем как о "шаблоне", но это уверенный:
for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }
Императивные языки как Java и C# приняли то, что является по существу функциональной конструкцией для контакта с этим: "foreach".
Я сказал бы, что, когда у Вас есть язык как Lisp с его поддержкой макросов, тогда можно создать Вас, владеют проблемно-ориентированными абстракциями, абстракциями, которые часто намного лучше, чем общие решения для идиомы.
Функциональное программирование не заменяет шаблоны разработки. Шаблоны разработки не могут быть заменены.
Шаблоны просто существуют; они появлялись со временем. Книга GoF формализовала некоторых из них. Если новые шаблоны обнаруживаются, поскольку разработчики используют языки функционального программирования, который является захватывающим материалом, и возможно будут книги, записанные о них также.
И даже решениями для Шаблона разработки OO является конкретный язык. Шаблоны разработки являются решениями типичных проблем, которые Ваш язык программирования не решает для Вас. В Java Шаблон "одиночка" решает (упрощенную) проблему того. В Scala у Вас есть высокоуровневая конструкция под названием Объект в дополнение к Классу. Это лениво инстанцируют и существует только один. Вы не должны использовать Шаблон "одиночка" для получения Singleton. Это - часть языка.
Шаблоны разработки в Динамическом программировании Peter Norvig имеют вдумчивое покрытие этой общей темы, хотя о 'динамических' языках вместо 'функционального' (существует перекрытие).
У Вас не может быть этого обсуждения, не поднимая системы типов.
основные функции функционального программирования включают функции как первоклассные значения, приправляющие карри, неизменные значения, и т.д. Для меня не кажется очевидным, что шаблоны разработки OO приближают любую из тех функций.
Поэтому эти функции не решают те же проблемы, которые ООП делает..., они - альтернативы императивному программированию. Ответ FP на ООП заключается в системах типов ML, и Haskell... конкретно суммируют типы, абстрактные типы данных, модули ML, Haskell typeclasses.
, Но конечно существуют все еще шаблоны разработки, которые не решены языками FP. Что FP эквивалентен из одиночного элемента? (Игнорирующий на мгновение, что одиночные элементы обычно являются ужасным шаблоном для использования)
первая вещь typeclasses делает, избавляют от необходимости одиночные элементы.
Вы могли пройти список 23 и устранить больше, но у меня нет времени к прямо сейчас.
Представление Norvig ссылается на анализ, который они сделали всех шаблонов GoF, и они говорят, что 16 из этих 23 шаблонов имели более простые реализации на функциональных языках или были просто частью языка. Таким образом, по-видимому, по крайней мере семь из них любой был a) одинаково сложными или b) не присутствовал на языке. К сожалению для нас они не перечисляются!
я думаю, что ясно, что большинство "creational" или "структурные" шаблоны в GoF являются просто приемами, чтобы заставить системы типа примитива в Java или C++ делать то, что Вы хотите. Но остальные достойны соображения, неважно, в каком языке Вы программируете.
можно было бы быть Прототипом; в то время как это - фундаментальное понятие JavaScript, это должно быть реализовано с нуля на других языках.
Один из моих любимых шаблонов является шаблоном Несуществующего объекта: представьте отсутствие чего-то как объект, который делает соответствующий вид ничего. Это может быть легче смоделировать на функциональном языке. Однако реальный успех является сдвигом в перспективе.
Когда Вы попытаетесь посмотреть на это на уровне "шаблонов разработки" (в целом) и "FP по сравнению с ООП", ответы, которые Вы найдете, будут темны в лучшем случае
Идут уровень глубже на обеих осях, тем не менее, и рассматривают определенные шаблоны разработки и , определенные функции языка и вещи становятся более ясными.
Так, например, некоторые определенные шаблоны, как Посетитель , Команда Стратегии , , и Наблюдатель определенно изменение или исчезают при использовании языка с [1 112] алгебраические типы данных и сопоставление с образцом , закрытия , функции первого класса , и т.д. Некоторые другие шаблоны из книги GoF все еще 'слоняются поблизости', все же.
В целом, я сказал бы, что со временем определенные шаблоны устраняются новым (или просто повышение в популярности) функции языка. Это - естественный ход дизайна языка; поскольку языки становятся более высокоуровневыми, абстракции, которые могли ранее только быть вызваны в книге с помощью примеров теперь, становятся приложениями конкретной функции языка или библиотеки.
(В стороне: вот недавний блог , который я записал, который имеет другие ссылки на большее количество обсуждения FP и шаблонов разработки.)
там какая-либо истина к заявлению, что функциональное программирование избавляет от необходимости шаблоны разработки ООП?
Функциональное программирование не является тем же как объектно-ориентированным программированием. Объектно-ориентированные шаблоны разработки не относятся к функциональному программированию. Вместо этого у Вас есть шаблоны разработки функционального программирования.
Для функционального программирования, Вы не прочитаете книги шаблона разработки OO, Вы прочитаете другие книги по шаблонам разработки FP.
агностик языка
Не полностью. Только агностик языка относительно языков OO. Шаблоны разработки не относятся к процедурным языкам вообще. Они едва имеют смысл в контексте дизайна реляционной базы данных. Они не применяются при разработке электронной таблицы.
типичный шаблон разработки ООП и его функциональный эквивалент?
Вышеупомянутое не должно существовать. Это похоже на выяснение части процессуального кодекса, переписанного как код OO. Ummm... Если я перевожу исходный Фортран (или C) в Java, я не сделал чего-то большего чем перевожу его. Если я полностью перепишу его в парадигму OO, это больше не будет смотреть ничто как исходный Фортран или C - это будет неузнаваемо.
нет никакого простого отображения от Дизайна OO до Функционального проекта. Они - совсем другие способы посмотреть на проблему.
Функциональное программирование (как весь стили программирования) имеет шаблоны разработки. Реляционные базы данных имеют шаблоны разработки, OO имеет шаблоны разработки, процедурное программирование имеет шаблоны разработки. Все имеет шаблоны разработки, даже архитектура зданий.
Шаблоны разработки - как понятие - являются бесконечным способом создать, независимо от технологии или проблемной области. Однако определенные шаблоны разработки относятся к определенным проблемным областям и технологиям.
Все, кто думает о том, что они делают, раскроют шаблоны разработки.
Комментарии Brian по поводу трудной связи между языком и шаблоном к точке,
, недостающая часть этого обсуждения является понятием идиомы. Книга Coplien, "Усовершенствованный C++" был огромным влиянием здесь. Задолго до того, как он обнаружил Christopher Alexander и Столбец Без Имени (и Вы не можете говорить разумно о шаблонах, не читая Alexander ни один), он говорил о важности освоения идиомы в действительно изучении языка. Он использовал строковую копию в C как пример, в то время как (*from ++ = *к ++); Вы видите это как лейкопластырь для недостающей функции языка (или функции библиотеки), но что действительно имеет значение об этом, то, что это - большая единица мысли, или выражения, чем любая из его частей.
, Именно это шаблоны и языки, пытаются сделать, позволить нам выражать наши намерения более кратко. Чем более богатый единицы мысли, тем более сложный мысли можно выразить. Наличие богатого, общего словаря в диапазоне масштабов - от архитектуры системы вниз к битовому жонглированию - позволяет нам иметь более интеллектуальные переговоры и мысли о том, что мы должны делать.
Мы можем также, как люди, учиться. Который является всем смыслом осуществления. Каждый из нас может понять и использовать вещи, о которых мы никогда не были бы в состоянии думать сами. Языки, платформы, библиотеки, шаблоны, идиомы и так далее у всех есть их место в совместном использовании интеллектуального богатства.
-
1I' ve нашел проблему - это было из-за несовместимостей между Матрицей 0.9, я имел прежде и текущий 1.x – Serge Tarkovski 14 April 2011 в 09:23
Книга GoF явно связана с ООП - название - Паттерны проектирования - элементы многоразового объектно-ориентированного программного обеспечения (выделено мной)