Есть ли какое-либо преимущество при использовании паттернов ООП в их классическом описании против использования, скажем, приёмов функционального программирования.
Пример: паттерн "Стратегия" может быть легко преобразован (в большинстве случаев) в несколько функций, одна из которых принимает функцию как аргумент.
Мне видится преимущество только в том, что описание паттернами ООП дает более высокоуровневое представление о системе. В принципе, можно реализовать ту же идею другими средствами, но глядя на реализацию, не всякий программист поймет идею с первого взгляда.
Здравствуйте, Flem1234, Вы писали:
F>Есть ли какое-либо преимущество при использовании паттернов ООП в их классическом описании против использования, скажем, приёмов функционального программирования.
F>Пример: паттерн "Стратегия" может быть легко преобразован (в большинстве случаев) в несколько функций, одна из которых принимает функцию как аргумент.
F>Мне видится преимущество только в том, что описание паттернами ООП дает более высокоуровневое представление о системе. В принципе, можно реализовать ту же идею другими средствами, но глядя на реализацию, не всякий программист поймет идею с первого взгляда.
1. Ваш вопрос следует тогда переформулировать: ООП vs. ФП
2. В функциональном программировании тоже есть паттерны.
3. Не стоит зацикливаться на паттернах Банды Четырех. Паттернов намного больше хороших и разных.
Здравствуйте, SE, Вы писали:
SE>1. Ваш вопрос следует тогда переформулировать: ООП vs. ФП
Скорее паттерны в ФП стиле vs паттерны в ООП стиле.
SE>2. В функциональном программировании тоже есть паттерны.
Вот бы увидеть по ним краткое описание в доступной форме.
Хотелось иметь стандарты, чтобы когда я говорю, что здесь "стратегия" в ФП стиле, все понимали, как это выглядит в коде. И наоборот, смотря в код, все видели — там "стратегию" в ФП стиле.
SE>3. Не стоит зацикливаться на паттернах Банды Четырех. Паттернов намного больше хороших и разных.
Я и не зацикливаюсь. Просто удобнее общаться, когда имеешь одинаковый ээээ... словарный запас. Благодаря книге GOF все знают о паттернах в ООП стиле, что облегчает общение. Вот бы статью на эту тему почитать. Типа "Как выглядели бы паттерны в мире ФП"
Здравствуйте, Flem1234, Вы писали:
F>Пример: паттерн "Стратегия" может быть легко преобразован (в большинстве случаев) в несколько функций, одна из которых принимает функцию как аргумент.
От того, что поменялась реализация, паттерн Стратегия не перестал быть Стратегией. Принцип ведь остался тот же.
Здравствуйте, Flem1234, Вы писали:
SE>>2. В функциональном программировании тоже есть паттерны. F>Вот бы увидеть по ним краткое описание в доступной форме. F>Хотелось иметь стандарты, чтобы когда я говорю, что здесь "стратегия" в ФП стиле, все понимали, как это выглядит в коде. И наоборот, смотря в код, все видели — там "стратегию" в ФП стиле.
Да, с этим негусто. Гугл выдал например такое A Functional Pattern System for Object-Oriented Design. К сожалению я в области ФП набегами, но может быть корифеи RSDN'а лучше ориентируются в этой области.
Здравствуйте, Aikin, Вы писали:
A>От того, что поменялась реализация, паттерн Стратегия не перестал быть Стратегией. Принцип ведь остался тот же.
Согласен. Но как он будет выглядеть в коде?
Примерно так?
using System;
public class Program
{
private static void Main()
{
var strategy = SelectStrategy();
Console.WriteLine(strategy(2, 2));
Console.ReadLine();
}
public static Func<int,int, int> SelectStrategy()
{
return new Func<int, int, int>(Sum);
}
public static int Sum(int a, int b)
{
return a + b;
}
public static int Mul(int a, int b)
{
return a * b;
}
}
Здравствуйте, SE, Вы писали:
SE>Да, с этим негусто. Гугл выдал например такое A Functional Pattern System for Object-Oriented Design. К сожалению я в области ФП набегами, но может быть корифеи RSDN'а лучше ориентируются в этой области.
Я тоже. Собственно, мой пост по существу провокация. Она должна побудить отцов к флейму и интересным постам (или статье)
Здравствуйте, Flem1234, Вы писали:
F>Но как он будет выглядеть в коде?
Точно так же. Только вместо AbstractStrategy будет тип функции, а вместо ConcreteStrategy будет уже функция.
Я вот только не совсем догоняю как будет быглядеть реализация, если одна стратегия содержит в себе две функции
F>Примерно так?
Не, это не Cтратегия, это Фабричный метод
Здравствуйте, Flem1234, Вы писали:
F>Здравствуйте, Aikin, Вы писали:
A>>Точно так же. Только вместо AbstractStrategy будет тип функции, а вместо ConcreteStrategy будет уже функция.
F>А можно код?
что-то типа такого
type Strategy = Add | Mul
let getStrategy = function
| Add -> (+)
| Mul -> ( *)
let run a b strategy = strategy a b
printfn "%d" (run 2 3 (getStrategy Add))
printfn "%d" (run 2 3 (getStrategy Mul))
Здравствуйте, Flem1234, Вы писали:
F>Есть ли какое-либо преимущество при использовании паттернов ООП в их классическом описании против использования, скажем, приёмов функционального программирования.
В голове наступит заметное прояснение, если понять, что такое "паттерн". Паттерн — это прием программирования, который описывает построение некоего решения типовой ситуации из определенных строительных блоков.
При этом подразумевается, что
а) в используемом языке есть подходящие строительные блоки
б) в используемом языке нет готовой конструкции, которая покрывает предлагаемое решение.
При таком понимании вопросы типа "как перенести паттерны GoF в Forth" отпадают сами собой.
Паттерны банды были построены для очень узкого сектора — объектно-ориентированных языков программирования. В функциональном программировании другие строительные блоки, и паттерны GoF в общем случае там неприменимы.
Наверняка там должны быть какие-то свои паттерны, которые лично я привести не смогу в силу своего слабого знакомства с предметом.
Теперь можно поразмышлять на тему исходного вопроса. Очевидно, что паттерны GoF являются частью арсенала ООП, так же как и паттерны ФП. Так что любое преимущество автоматически бы приводило к превосходству соответствующей парадигмы.
Увы, пока что однозначных выводов в пользу одной из парадигм сделать не удается.
Так что лично я склонен считать, что просто некоторые задачи компактнее решаются в стиле ООП, а некоторые — в стиле ФП. И так далее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Паттерны банды были построены для очень узкого сектора — объектно-ориентированных языков программирования. В функциональном программировании другие строительные блоки, и паттерны GoF в общем случае там неприменимы.
Не совсем так. Большинство паттернов GoF в универсальных функциональных языках применимы, но выглядеть оно там будет несколько по другому. Та же упомянутая стратегия прекрасно реализуется и в ФП, только вместо ОО интерфейса имеем функциональный тип, а вместо реализующего класса лямбду. Если же стратегия требует нескольких методов, то решение вообще получается идентичным.
S>Наверняка там должны быть какие-то свои паттерны, которые лично я привести не смогу в силу своего слабого знакомства с предметом.
Ну карринг, к примеру — типичный чисто ФП паттерн, в языках вроде Хаскелля даже встроенный в язык. Или монады. Можно еще как паттерн трактовать стандартные операции со списком — свертку, фильтрацию, проекцию, сортировку и группировку (да да, в функциональном SQL и во многих других ФП языках оно так же встроено в язык).
... << RSDN@Home 1.2.0 alpha 4 rev. 1106 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Трурль, Вы писали:
Т>А если реализовать его на if-ах?
Самая главная особенность стратегии: Стратегия позволяет менять алгоритм независимо от клиентов, которые его используют. Т.о. уменяшается связность меду пользователем функциональности и самой функциональностью.
Если ты на ифах такое сможешь замутить то таки да, это будет Стратегия
F>Мне видится преимущество только в том, что описание паттернами ООП дает более высокоуровневое представление о системе. В принципе, можно реализовать ту же идею другими средствами, но глядя на реализацию, не всякий программист поймет идею с первого взгляда.
Где-то в сети етсь презентация, в которой показано, что, емнип, 17 из 43 паттернах, описаных у GoF, доступны в функциональных языках напрямую, как конструкции языка или встроенные в стандарнтные библиотеки. Может кто и вспомнит ссылку
Здравствуйте, SE, Вы писали:
SE>Здравствуйте, Flem1234, Вы писали:
SE>>>2. В функциональном программировании тоже есть паттерны. F>>Вот бы увидеть по ним краткое описание в доступной форме. F>>Хотелось иметь стандарты, чтобы когда я говорю, что здесь "стратегия" в ФП стиле, все понимали, как это выглядит в коде. И наоборот, смотря в код, все видели — там "стратегию" в ФП стиле. SE>Да, с этим негусто. Гугл выдал например такое A Functional Pattern System for Object-Oriented Design. К сожалению я в области ФП набегами, но может быть корифеи RSDN'а лучше ориентируются в этой области.
Кто находил нормальный (не китайский и не разбитый) скан книги Gang of Four например в djvu на английском языке чтобы можно было нормально распечатать, без всяких графических полей там и навигации вебсайта на каждой странице?
Здравствуйте, Flem1234, Вы писали:
F>Есть ли какое-либо преимущество при использовании паттернов ООП в их классическом описании против использования, скажем, приёмов функционального программирования.
Вообще-то в этом посте есть один ключевой неверный момент, я его выделил жирным. ООП и ФП хорошо дополняют друг друга. Между ними нет противостояния. Точнее оно есть только в головах отъявленных фанатов. В реальности же уже чётко наметилась тенденция по интеграции этих подходов даже в мейнстрим языках. Что не может не радовать.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Flem1234, Вы писали:
F>Есть ли какое-либо преимущество при использовании паттернов ООП в их классическом описании против использования, скажем, приёмов функционального программирования.
Что было раньше — курица или яйцо? Язык ОО-паттернов тяготеет к пересечению описания проблем психологии восприятия и "механических" абстракций, типа описания удобного в обслуживании набора взаимодействующих устройств. Язык и абстракции функционального стиля — к "чистой" математике.
Оптимальное же сочетание разновидностей абстракций определяется в завимости от текущих условий.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Aikin, Вы писали:
F>>Пример: паттерн "Стратегия" может быть легко преобразован (в большинстве случаев) в несколько функций, одна из которых принимает функцию как аргумент. A>От того, что поменялась реализация, паттерн Стратегия не перестал быть Стратегией. Принцип ведь остался тот же.\
Не совсем так. Исчез сам паттерн. Его реализация стала настолько тривиальна, что как такового паттерна уже нет.
На мой взгляд ФП — это технология реализации. Вот что это значит...
Реально ФП — это развитие (и одновременно ограничение) технологии структурно/процедурного программирования. Средствами декомпозиции кода в нем было разбиение на функции (точнее процедуры). ФП тут ничего нового не привнес.
С другой стороны ФП резко улучшил средства декомпозиции на уровне функции введя такие идиомы как лямбды и ФВП. Кроме того в ФП появилось и развилось множество других методов укорачивания и декларатизирования кода. Это позволило с одной стороны увеличить детализацию декомпозиции, а с другой сделать код функций короче и декларативнее.
Там где в ООП иногда требуется применять сложные решения (не автоматизируемые средствами ООП) ФП предлагает простые (короткие и декларативные) решения. Это во многих случаях позволят вообще уйти от применения паттернов или хотя бы упростить (или частично автоматизировать) их применение.
С другой стороны средствами ФП далеко не все паттерны ООП можно устранить (или автоматизировать их реализацию). Более того ООП предлагает мощные средства проектирования (на базе абстрагирования) на уровне приложения. ФП этого предложить не может. Пожалуй единственным средством расширяющим средства проектирования в ФЯ являются алгебраические типы. В купе с сопоставлением с образцом они позволяют решать некоторые задачи проще. Но опят таки — это увеличение декларативности решения, а не средсво проектирования приложений. Мне могут возразить — а как же классы типов в Хаскеле? — на что я спокойно отвечу, что они не являются идиомами ФП, а скорее являются расширением конкретного языка средствами идеологически похожими на средства давно используемыми в ООП (интерфейсами).
Кроме того чистый ФП вообще имеет мало смысла в насквозь императивном мире компьютеров (да и вообще мире). Не все алгоритмы могут быть эффективно реализованы в функциональном стиле, а любой ввод/вывод сразу императив. Попытки скрыть императив за монадами приводят к чрезмерному усложнению и снижению производительности.
Посему мне видится, что ФП и ООП могут прекрасно дополнять друг-друга. ООП будет упрощать проектирование на уровне всего приложения, а ФП упрощать реализацию его частей (на более детальном уровне).
Собственно именно так такая кооперация ООП и ФП и просматривается в наиболее перспективных (на мой взгляд) языках: Nemerle, Scala, Haskell и C# 3+.
С Haskell конечно отдельный разговор. На его классы типов можно смотреть по разному, но на мой взгляд это те же ООП-средства, просто приспособленные для "чистого" ФЯ. Остальные же языки — это чистые гибриды ФП и ООП. Разница только в качестве поддержки ФП и в глубине связи между ФП и ФЯ. Здесь пожалуй Scala пошла дальше всего.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Та же упомянутая стратегия прекрасно реализуется и в ФП, только вместо ОО интерфейса имеем функциональный тип, а вместо реализующего класса лямбду. Если же стратегия требует нескольких методов, то решение вообще получается идентичным.
Это уже не паттерн, а применение фичи языка, о чем и говорил Синклер. Многие паттерны ООП действительно бессмысленны при наличии некоторых ФП-фич. Стратегия, к примеру, просто выражается.
С другой стороны, скажем такая фича C#, как событие может быть выраженно в виде паттерна с использованием функционального типа. Это обратный пример. Правда, пример работает только для .нет-языков, так как скажем в С++ или Яве событий нет и они там тоже реализуются паттернами. Причем реализуются значительно сложнее.
S>>Наверняка там должны быть какие-то свои паттерны, которые лично я привести не смогу в силу своего слабого знакомства с предметом.
AVK>Ну карринг, к примеру — типичный чисто ФП паттерн, в языках вроде Хаскелля даже встроенный в язык.
Карринг не паттерн. И ты не сможешь повторить (даже сэмулировать) его на языке где нет функциональных типов.
Паттерном можно назвать более общий прием — создание фунции путем манипуляции над другими функциями. Но это опять таки основополагающая фича ФП с изучения которой начинается изучение ФП. Паттерн же — это прием выходящий за рамки базовых концепций, на мой взгляд.
AVK> Или монады.
Вот монады, пожалуй можно назвать паттерном встроенным в Хаскель. Без них действительно можно жить (если есть поддержка императивного программирования).
AVK>Можно еще как паттерн трактовать стандартные операции со списком — свертку, фильтрацию, проекцию, сортировку и группировку (да да, в функциональном SQL и во многих других ФП языках оно так же встроено в язык).
Точно нельзя, так как они являются обычными функциями. Это уже извращение самого понятия "Паттерн", и тогда паттерном можно будет называть любой класс, например, строку.
Паттерн есть нечто, что нельзя выразить средствами языка и требуется каждый раз реализовывать по шаблону.
В общем, обсуждение опять ушло в терминологию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, desco, Вы писали:
D>что-то типа такого
D>
D>type Strategy = Add | Mul
D>let getStrategy = function
D> | Add -> (+)
D> | Mul -> ( *)
D>let run a b strategy = strategy a b
D>printfn "%d" (run 2 3 (getStrategy Add))
D>printfn "%d" (run 2 3 (getStrategy Mul))
D>
Это не эмуляция стратегии, а какая-то фигня. Смысл стратегии в том, что выбор операции осуществляются на базе некоторых внешних факторов. К чистому ФП это вообще не применимо, так как в нем просто не должно быть этих внешних факторов. Ведь внешние факторы — это побочные эффекты.
Так что вместо паттерна стратегии можно просто применять функцию возвращающую функцию с некоторой сигнатурой:
Strategy() : int * int -> int
{
...
}
Но это подразумевает наличие некоторого глобального состояния, вхождения Strategy в состав некоторого ООП-класса или передачу состояние функции Strategy в качестве параметра.
Короче в языке с поддержкой ФП стратегия просто превращается в использование функций высшего порядка, что настолько тривиально, что назвать это паттерном можно только обладая очень бурной фантазией.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Посему мне видится, что ФП и ООП могут прекрасно дополнять друг-друга. ООП будет упрощать проектирование на уровне всего приложения, а ФП упрощать реализацию его частей (на более детальном уровне).
Полностью с этим согласен!
F>>>Пример: паттерн "Стратегия" может быть легко преобразован (в большинстве случаев) в несколько функций, одна из которых принимает функцию как аргумент. A>>От того, что поменялась реализация, паттерн Стратегия не перестал быть Стратегией. Принцип ведь остался тот же.\ VD>Не совсем так. Исчез сам паттерн. Его реализация стала настолько тривиальна, что как такового паттерна уже нет.
Вот с этим хочу немного поспорить
Стратегия не всегда подменяет только один метод, чаще всего ее интерфейс содержит два и более методов. В этом случае их уже, насколько мне известно, не обернешь так же естественно как в случае с одной функцией.
Здравствуйте, Aikin, Вы писали: VD>>Не совсем так. Исчез сам паттерн. Его реализация стала настолько тривиальна, что как такового паттерна уже нет. A>Вот с этим хочу немного поспорить A>Стратегия не всегда подменяет только один метод, чаще всего ее интерфейс содержит два и более методов. В этом случае их уже, насколько мне известно, не обернешь так же естественно как в случае с одной функцией.
Из ФВП можно вернуть сколько угодно функций. 1 или кортеж — прямой аналог итерфейса. А список функций в ООП уже выражается с трудом, а вот в ФП — это стандартная практика.
Здравствуйте, Tonal-, Вы писали:
A>>Стратегия не всегда подменяет только один метод, чаще всего ее интерфейс содержит два и более методов. В этом случае их уже, насколько мне известно, не обернешь так же естественно как в случае с одной функцией. T>Из ФВП можно вернуть сколько угодно функций. 1 или кортеж — прямой аналог итерфейса. А список функций в ООП уже выражается с трудом, а вот в ФП — это стандартная практика.
Не могли бы вы привести пример кода.
Массив ссылок на функцию или делегатов можно сделать и в императивных языках, но тут важна сигнатура методов входящих в стратегию, а не сам факт объединения функций в одну конструкцию.
Здравствуйте, Aikin, Вы писали: T>>Из ФВП можно вернуть сколько угодно функций. 1 или кортеж — прямой аналог итерфейса. А список функций в ООП уже выражается с трудом, а вот в ФП — это стандартная практика. A>Не могли бы вы привести пример кода. A>Массив ссылок на функцию или делегатов можно сделать и в императивных языках, но тут важна сигнатура методов входящих в стратегию, а не сам факт объединения функций в одну конструкцию.
Посмотри в декларативке.
Из последних: Re: [Haskell]Задача на fold
Жаль, но не смог оценить Уровень моих знаний функциональных языков не позволяет.
Не могли бы вы все же пояснить этот пример. Меня интересует типизированная "ссылка" на две и более функции.
Странно видеть Open/closed principle рядом со Strategy. Имхо, различные principles, как то: OCP, LSP, ISP, SRP, etc. это более "низкоуровневые" вещи чем паттерны. В той же стратегии намешаны, как минимум, LSP и DIP.
Если нам не помогут, то мы тоже никого не пощадим.
Уровень моих знаний функциональных языков не позволяет.
