Страницы: 0 | (10) | 20 | 40 | 60 | 80 | показать все | след. страница
Quote:
Шаблоны проектирования связаны с объектно-ориентированным проектированием и существуют в его рамках, питон ООП поддерживает. Почему же нельзя реализовать библиотеки для реализации? Неужели я буду первым таким любителем ООП.
Помимо ООП, питон является еще и более-менее полноценным функциональным языком. Значительная часть так называемых "шаблонов проектирования" - это борьба с тем, что C++/Java не являются полноценными функицональными языками. "Шаблоны проектировния" не являются свойством/следствием/важной методикой ООП в более высоком смысле (см. Smalltalk, CLOS). "Шаблоны проектировния" - это тяжелое наследие Java в большей степени.
Не надо их тащить везде. Не надо их тащить в питон. Simple is better than complex. Beautiful is better than ugly.
В ответ на:
"Шаблоны проектировния" - это тяжелое наследие Java в большей степени.
В ответ на:
the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994
В ответ на:где-то нестыковочка
Java is a programming language released in 1995
Я говорю о практике, а именно - "Users of dynamic programming languages have discussed many design patterns as workarounds for the limitations of languages such as C++ and Java. ... Peter Norvig, in `Design Patterns in Dynamic Programming', discusses the triviality of implementing various patterns in dynamic languages. Norvig and others have described language features that encapsulate or replace various patterns that a C++ user must implement for themselves."
Quote:
питон является еще и более-менее полноценным функциональным языком.
Не думал, что это настолько важно. Мне казалось что функциональные языки сродни брейнфаку. То бишь большой проект на функциональном языке не сделаешь - неудобно делать декомпозицию без инкапсуляции.
Правильно ли я понимаю, что единственный признак, по которому питон - функциональный язык - это наличие лямбда функций?
Чтобы проникнуться питоном, рекомендуется для прочтения, на вскидку:
http://python.net/~goodger/projects/pycon/2007/idiomatic/han...
http://www.dabeaz.com/generators/
Поведай уже общественности, какова разгадка Quote:
так называемые "шаблоны проектирования" - от части (и значительной части) следствие убогости C++/Java.
ты путаешь шаблоны проектирования с реализацией шаблонов проектирования.
шаблоны проектирования - есть всегда и везде (хоть в java, хоть в python-е, хоть в bash-е), а вот реализация шаблонов проектирования уже от языка к языку плавает: где-то она более громоздкая как в java, где-то менее.
Quote:
Шаблоны проектирования связаны с объектно-ориентированным проектированием
шаблоны проектирования не связаны с ООП.
но вот реализация шаблонов проектирования с ООП связана - т.к. с помощью ООП шаблоны проектирования проще реализуются в лоб.
ps
например, код, который отвечает в ОС за запуск нужной программы по типу файла - и есть типичная фабрика.
причем, что в win, что в *nix - ООП при этом и не пахнет.
Quote:
Значительная часть так называемых "шаблонов проектирования" - это борьба с тем, что C++/Java не являются полноценными функицональными языками
Какие именно?
Quote:
шаблоны проектирования - есть всегда и везде (хоть в java, хоть в python-е, хоть в bash-е), а вот реализация шаблонов проектирования уже от языка к языку плавает: где-то она более громоздкая как в java, где-то менее
Называть реализацию шаблона на уровне языка программирования шаблоном или нет? Вот в чем вопрос. Грубо говоря, если для реализации стратегии в C# вместо интерфейса использовать делегат, можно ли считать это стратегией или уже нет? А можно ли считать визитором поддержку multimethods на уровне языка программирования?
Quote:
Не надо их тащить везде. Не надо их тащить в питон.
есть понятие "шаблон проектирование", а есть также "каноническая реализация шаблона проектирования в ООП-языке".
ты путаешь первое со вторым.
возьмем ту же самую фабрику: задача фабрики задекларировать какого вида(с поддержкой каких интерфейсов) объекты будут создаваться, но при этом скрыть что именно будет создаваться.
канонический ООП вид этого паттерна довольно громоздкий:
интерфейсы-декларации вида объекта, класс - абстрактная фабрика, классы - конкретные фабрики, конкретные классы - реализующие интерфейс.
но также есть много и не канонических реализаций:
например, первая строчка в следующем коде - это тоже фабрика:
code:
var comparer = sortKind == SortKind.ByName ? item => item.Name : item => item.FullName; return items.SortByKey(comparer);
т.к. все принципы фабрики сохраняются: результат работы этой строчки декларация того, что именно будет уметь comparer(возвращает ключ, который поддерживает сравнение), при этом само создание компарера скрыто внутри строки.
из-за того, что python более гибкий язык, чем Java - понятно, что в python-е скорее будут использоваться вот такие "локальные" реализации шаблонов проектирования, но при этом сами шаблоны проектирования - никуда не денутся.
Quote:
Грубо говоря, если для реализации стратегии в C# вместо интерфейса использовать делегат, можно ли считать это стратегией или уже нет?
конечно, можно. это и будет стратегия.
Quote:
А можно ли считать визитором поддержку multimethods на уровне языка программирования?
тоже, да.
ps
если перечитывать классику по шаблонам проектирования - то можно заметить, что там именно в первую очередь приводится идея шаблона (нахрена мы так делаем), и на много реже приводится как именно это конкретно реализуется на том или ином языке.
Quote:
говорю о практике, а именно - "Users of dynamic programming languages have discussed many design patterns as workarounds for the limitations of languages such as C++ and Java. ... Peter Norvig, in `Design Patterns in Dynamic Programming', discusses the triviality of implementing various patterns in dynamic languages. Norvig and others have described language features that encapsulate or replace various patterns that a C++ user must implement for themselves."
в цитируемых тобой названиях - заложена другая мысль, чем ты высказываешь в этом треде.
там написано, что в динамических языках реализация многих шаблонов проектирования становится тривиальной, а не то, что динамические языки отменяют шаблоны проектирования.
Quote:
конечно, можно. это и будет стратегия.
Тут я согласен.
Quote:
тоже, да.
А тут не согласен.
Одна из задач визитора как шаблона проектирования - определение конткретных типов. При наличии multimethods эта задача решается автоматически. Еще одна из задач визитора - упрощение добавления новых операций над набором операндов. При наличии multimethods эта задача решается, опять же, автоматически: мы просто пишем операцию. Таким образом визитор как шаблон проектирования полностью исчезает.Я согласен, что часть шаблонов все равно остается. Но ответ на вопрос, остаются ли они все, для меня до сих пор неочевиден.
Quote:
, в котором фукнции являются first-class objects, т.е. настолько же полнопрвными объектами
функторы в сях приплюснутых уже давно придумали. Он стал функциональным от этого?
Quote:Да, Си++ можно считать статически типизированным функциональным языком. То есть, правильнее сказать, что там можно программировать в таком стиле.
Он стал функциональным от этого?
То, что там это выглядит некрасиво и ужасно, этого факта не отменяет.
Quote:
функторы в сях приплюснутых уже давно придумали. Он стал функциональным от этого?
нет, потому что из-за отсутствия сборщика мусора - активное использование функционального стиля становится небезопасным.
т.е. есть конфликт между требованиями C++ и требованиями функционального стиля:
С++ требует, чтобы четко было понятно кто именно отвечает за уничтожение данных(освобождение памяти),
ФЯ стиль, наоборот, декларирует другое - не парьтесь с тем, кто именно и как это будет использовать. просто верните/передайте тот кусочек кода/знаний, который у вас есть.