Есть ли какое-либо преимущество при использовании паттернов ООП в их классическом описании против использования, скажем, приёмов функционального программирования.
Пример: паттерн "Стратегия" может быть легко преобразован (в большинстве случаев) в несколько функций, одна из которых принимает функцию как аргумент.
Мне видится преимущество только в том, что описание паттернами ООП дает более высокоуровневое представление о системе. В принципе, можно реализовать ту же идею другими средствами, но глядя на реализацию, не всякий программист поймет идею с первого взгляда.
Здравствуйте, 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.: Винодельческие провинции — это есть рулез!