python vs шаблоны проектирования
import this
то бишь в стандартной поставке есть фабрика, стратегии и прочие паттерны?
то бишь тебе рекомендуется выполнить этот код и задуматься.
есть ли для питона аналог c++шного boostа - библиотека с шаблонами?ужость. В пистоне есть конечно кривые места, но блин в качестве эталона брать цепепешные либы это как-то слишком.
ну я осилил документацию из /usr/share/doc/python-2.5 и так и не понял как мне правильно поступить:
писать шаблоны проектирования самому, или не изобретать велосипед и найти подходящую либу
писать шаблоны проектирования самому, или не изобретать велосипед и найти подходящую либу
import thisда уж, странный и прямой метод размещать документацию по проекту.
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!
Перечитай import this еще раз.
Ты решил осваивать python. Совсем не обязательно писать C++/Java код на питоне. так называемые "шаблоны проектирования" — от части (и значительной части) следствие убогости C++/Java. Они не настолько нужны в питоне.
Я понимаю, да. Real programmer can write Fortran in any language.
Ты решил осваивать python. Совсем не обязательно писать C++/Java код на питоне. так называемые "шаблоны проектирования" — от части (и значительной части) следствие убогости C++/Java. Они не настолько нужны в питоне.
Я понимаю, да. Real programmer can write Fortran in any language.
Шаблоны проектирования - это ведь именно средство проектирования
А как они в разных языках реализуются или не реализуются - это уже дело языка. Очевидно, что в питоне все типичные шаблоны проектирования можно сделать достаточно легко. Язык хорошо надстраивается и расширяется, существования AOP - хороший тому пример.
Шаблоны проектирования связаны с объектно-ориентированным проектированием и существуют в его рамках, питон ООП поддерживает. Почему же нельзя реализовать библиотеки для реализации? Неужели я буду первым таким любителем ООП.
Или концепция Питона настолько выше ООП, что ему этого не нужно, просто я ещё не заметил?
А как они в разных языках реализуются или не реализуются - это уже дело языка. Очевидно, что в питоне все типичные шаблоны проектирования можно сделать достаточно легко. Язык хорошо надстраивается и расширяется, существования AOP - хороший тому пример.
Шаблоны проектирования связаны с объектно-ориентированным проектированием и существуют в его рамках, питон ООП поддерживает. Почему же нельзя реализовать библиотеки для реализации? Неужели я буду первым таким любителем ООП.
Или концепция Питона настолько выше ООП, что ему этого не нужно, просто я ещё не заметил?
Надоело мне сегодня прогать под баш, решил попробовать другой язык.а в баше есть паттерны проектирования "Фабрика" и "Стратегия" ?
Шаблоны проектирования связаны с объектно-ориентированным проектированием и существуют в его рамках, питон ООП поддерживает. Почему же нельзя реализовать библиотеки для реализации? Неужели я буду первым таким любителем ООП.Помимо ООП, питон является еще и более-менее полноценным функциональным языком. Значительная часть так называемых "шаблонов проектирования" - это борьба с тем, что 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где-то нестыковочка
Я говорю не об истории (да, Design patterns - концепция 1977 года, понимаю).
Я говорю о практике, а именно - "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."
Я говорю о практике, а именно - "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."
ну так слово за слово. Полез в документацию, обнаружил что питон больше чем просто замена баша и мне стало любопытно.
питон является еще и более-менее полноценным функциональным языком.Не думал, что это настолько важно. Мне казалось что функциональные языки сродни брейнфаку. То бишь большой проект на функциональном языке не сделаешь - неудобно делать декомпозицию без инкапсуляции.
Правильно ли я понимаю, что единственный признак, по которому питон - функциональный язык - это наличие лямбда функций?
то бишь ты предлагаешь заменить одну концепцию проектирования на другую, более натуральную. Как выглядит концепции питона на UML? Можешь дать только ключевые слова для поиска.
Неправильно. Примитивное определение какое-то такое: функциональный язык - это язык, в котором фукнции являются first-class objects, т.е. настолько же полнопрвными объектами, как и, скажем, числа, строки и т.п. Кстати, полноценных лямбда-функций в питоне как раз нет.
Чтобы проникнуться питоном, рекомендуется для прочтения, на вскидку:
http://python.net/~goodger/projects/pycon/2007/idiomatic/han...
http://www.dabeaz.com/generators/
Чтобы проникнуться питоном, рекомендуется для прочтения, на вскидку:
http://python.net/~goodger/projects/pycon/2007/idiomatic/han...
http://www.dabeaz.com/generators/
Я вот все пытаюсь разгадать этот паззл, --- что можно собрать из "модуля для автоматической распаковки архивов любой степени вложенности" и шаблонов "фабрика", "стратегии"и прочих, --- да не выходит 
Поведай уже общественности, какова разгадка
Поведай уже общественности, какова разгадка так называемые "шаблоны проектирования" — от части (и значительной части) следствие убогости C++/Java.ты путаешь шаблоны проектирования с реализацией шаблонов проектирования.
шаблоны проектирования - есть всегда и везде (хоть в java, хоть в python-е, хоть в bash-е а вот реализация шаблонов проектирования уже от языка к языку плавает: где-то она более громоздкая как в java, где-то менее.
Шаблоны проектирования связаны с объектно-ориентированным проектированиемшаблоны проектирования не связаны с ООП.
но вот реализация шаблонов проектирования с ООП связана - т.к. с помощью ООП шаблоны проектирования проще реализуются в лоб.
ps
например, код, который отвечает в ОС за запуск нужной программы по типу файла - и есть типичная фабрика.
причем, что в win, что в *nix - ООП при этом и не пахнет.
Значительная часть так называемых "шаблонов проектирования" - это борьба с тем, что C++/Java не являются полноценными функицональными языкамиКакие именно?
шаблоны проектирования - есть всегда и везде (хоть в java, хоть в python-е, хоть в bash-е а вот реализация шаблонов проектирования уже от языка к языку плавает: где-то она более громоздкая как в java, где-то менееНазывать реализацию шаблона на уровне языка программирования шаблоном или нет? Вот в чём вопрос. Грубо говоря, если для реализации стратегии в C# вместо интерфейса использовать делегат, можно ли считать это стратегией или уже нет? А можно ли считать визитором поддержку multimethods на уровне языка программирования?
Не надо их тащить везде. Не надо их тащить в питон.есть понятие "шаблон проектирование", а есть также "каноническая реализация шаблона проектирования в ООП-языке".
ты путаешь первое со вторым.
возьмем ту же самую фабрику: задача фабрики задекларировать какого вида(с поддержкой каких интерфейсов) объекты будут создаваться, но при этом скрыть что именно будет создаваться.
канонический ООП вид этого паттерна довольно громоздкий:
интерфейсы-декларации вида объекта, класс - абстрактная фабрика, классы - конкретные фабрики, конкретные классы - реализующие интерфейс.
но также есть много и не канонических реализаций:
например, первая строчка в следующем коде - это тоже фабрика:
var comparer = sortKind == SortKind.ByName ? item => item.Name : item => item.FullName;
return items.SortByKey(comparer);
т.к. все принципы фабрики сохраняются: результат работы этой строчки декларация того, что именно будет уметь comparer(возвращает ключ, который поддерживает сравнение при этом само создание компарера скрыто внутри строки.
из-за того, что python более гибкий язык, чем Java - понятно, что в python-е скорее будут использоваться вот такие "локальные" реализации шаблонов проектирования, но при этом сами шаблоны проектирования - никуда не денутся.
Грубо говоря, если для реализации стратегии в C# вместо интерфейса использовать делегат, можно ли считать это стратегией или уже нет?конечно, можно. это и будет стратегия.
А можно ли считать визитором поддержку multimethods на уровне языка программирования?тоже, да.
ps
если перечитывать классику по шаблонам проектирования - то можно заметить, что там именно в первую очередь приводится идея шаблона (нахрена мы так делаем и на много реже приводится как именно это конкретно реализуется на том или ином языке.
говорю о практике, а именно - "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."в цитируемых тобой названиях - заложена другая мысль, чем ты высказываешь в этом треде.
там написано, что в динамических языках реализация многих шаблонов проектирования становится тривиальной, а не то, что динамические языки отменяют шаблоны проектирования.
конечно, можно. это и будет стратегия.Тут я согласен.
тоже, да.
А тут не согласен.
Одна из задач визитора как шаблона проектирования - определение конткретных типов. При наличии multimethods эта задача решается автоматически. Ещё одна из задач визитора - упрощение добавления новых операций над набором операндов. При наличии multimethods эта задача решается, опять же, автоматически: мы просто пишем операцию. Таким образом визитор как шаблон проектирования полностью исчезает.Я согласен, что часть шаблонов всё равно остаётся. Но ответ на вопрос, остаются ли они все, для меня до сих пор неочевиден.
, в котором фукнции являются first-class objects, т.е. настолько же полнопрвными объектамифункторы в сях приплюснутых уже давно придумали. Он стал функциональным от этого?
Он стал функциональным от этого?Да, Си++ можно считать статически типизированным функциональным языком. То есть, правильнее сказать, что там можно программировать в таком стиле.
То, что там это выглядит некрасиво и ужасно, этого факта не отменяет.
функторы в сях приплюснутых уже давно придумали. Он стал функциональным от этого?нет, потому что из-за отсутствия сборщика мусора - активное использование функционального стиля становится небезопасным.
т.е. есть конфликт между требованиями C++ и требованиями функционального стиля:
С++ требует, чтобы четко было понятно кто именно отвечает за уничтожение данных(освобождение памяти
ФЯ стиль, наоборот, декларирует другое - не парьтесь с тем, кто именно и как это будет использовать. просто верните/передайте тот кусочек кода/знаний, который у вас есть.
функторы в сях приплюснутых уже давно придумали. Он стал функциональным от этого?в С++ даже с ООП-то есть проблемы, т.к. приходится использовать такие костыли, как smart-pointer-ы, ref-count-pointer-ы и т.д.
из-за того, что python более гибкий язык, чем Java - понятно, что в python-е скорее будут использоваться вот такие "локальные" реализации шаблонов проектирования, но при этом сами шаблоны проектирования - никуда не денутся.вот именно так мне и казалось. А ещё мне кажется, что нужная мне библиотека должна просто определять класс. То есть говоришь функции: хочу составить класс из таких-то стратегий - и она тебе генерирует класс, который эти стратегии использует. Потом берёшь наследуешь от этого класса - и всё готово.
в С++ даже с ООП-то есть проблемы, т.к. приходится использовать такие костыли, как smart-pointer-ы, ref-count-pointer-ы и т.д.То есть для ООП необходимо наличие сборщика мусора? Или ты считаешь, что для ООП просто необходима поддержка кольцевых отношений в иерархии классов, или я что-то не так понял?...
Одна из задач визитора как шаблона проектирования - определение конткретных типов.в классике про визитор - как про шаблон проектирования - написано только о разделении, что должно быть две разных сущности:
одна умеет обходить элементы
а другая умеет что-то делать с каждым элементом,
ни о каких типах там речи нет.
в классике про визитор - как про шаблон проектирования - написано только о разделении, что должно быть две разных сущности:В какой классике? Обходить элементы умеет паттерн итератор. Визитор вовсе не обязан уметь этого делать. Он отделяет операцию от данных.
одна умеет обходить элементы
а другая умеет что-то делать с каждым элементом,
ни о каких типах там речи нет.
есть понятие "шаблон проектирование", а есть также "каноническая реализация шаблона проектирования в ООП-языке"
из-за того, что python более гибкий язык, чем Java - понятно, что в python-е скорее будут использоваться вот такие "локальные" реализации шаблонов проектирования, но при этом сами шаблоны проектирования - никуда не денутся.Согласен с этим. Но не кажется ли, что таким образом можно любую программу нарезать на паттерны, и утверждать, что она состоит только из них, пусть часто в не очень канонических реализациях?
Но не кажется ли, что таким образом можно любую программу нарезать на паттерны, и утверждать, что она состоит только из них, пусть часто в не очень канонических реализациях?нет, не кажется. приглядись к своей программе.
Да, во всех моих постах слова "шаблоны проектирования" заменить на "канонические универсальные реализации шаблонов проектирования для данного языка", так будет точнее, чтобы к буквам не придирались. Немного притянутый приемер того, что получится если везде видеть шаблоны - следующим постом.
Пригляделся, и понял, что не правильно я все таки пишу. Есть же чудесный шаблон Builder, че ж я раньше-то им не пользовался?
Это сразу ответ тебе, и обещанный пример для 'я.
Это сразу ответ тебе, и обещанный пример для 'я.
class TwoArgOperation(object):
def setFirstArg(self, arg): self.arg1 = arg
def setSecondArg(self, arg): self.arg2 = arg
def setOperation(self, operation): self._operation = operation
def getResult(self): return self._operation(self.arg1, self.arg2)
class TwoArgOperationBuilder(object):
def __init__(self): self._operation = TwoArgOperation
def getOperation(self): return self._operation
def BuildFirstArg(self): raise NotImplementedError
def BuildSecondArg(self): raise NotImplementedError
def BuildOperation(self): raise NotImplementedError
class TwoPlusThreeBuilder(TwoArgOperationBuilder):
def BuildFirstArg(self): self._operation.setFirstArg(2)
def BuildSecondArg(self): self._operation.setSecondArg(3)
def BuildOperation(self): self._operation.setOperation(int.__add__)
class FourByFiveBuilder(TwoArgOperationBuilder):
def BuildFirstArg(self): self._operation.setFirstArg(4)
def BuildSecondArg(self): self._operation.setSecondArg(5)
def BuildOperation(self): self._operation.setOperation(int.__mul__)
class RangeFromTwoToFiveBuilder(TwoArgOperationBuilder):
def BuildFirstArg(self): self._operation.setFirstArg(2)
def BuildSecondArg(self): self._operation.setSecondArg(5)
def BuildOperation(self): self._operation.setOperation(range)
class TwoArgOperationProcessor(object):
def setBuilder(self, builder): self._builder = builder
def getOperation(self): return self._operation.getOperation
def ConstructOperation(self):
self._operation = self._builder
self._operation.BuildFirstArg
self._operation.BuildSecondArg
self._operation.BuildOperation
def main:
processor = TwoArgOperationProcessor
processor.setBuilder(RangeFromTwoToFiveBuilder)
processor.ConstructOperation
for i in processor.getOperation.getResult:
processor.setBuilder(TwoPlusThreeBuilder)
processor.ConstructOperation
print processor.getOperation.getResult
processor.setBuilder(FourByFiveBuilder)
processor.ConstructOperation
print processor.getOperation.getResult
if __name__=='__main__':
main
Все, релизация которых тривиальна в динамических функциональных языках.
Есть же чудесный шаблон Builder, че ж я раньше-то им не пользовался?Совсем не ясна мысль, которую ты пытался донести до нас этим постом. Таким образом можно обосрать что угодно. Ты же сам привёл в пример Norvig-а, он там описывает паттерн билдер, а так же для чего он нужен и как его сделать.
Есть же чудесный шаблон Builder, че ж я раньше-то им не пользовался?так опять же ты все сводишь к канонической реализации.
взять какой-нибудь Linq - это тоже например, типичный пример шаблона Builder
return items.Where(item => item.Level > 5).Select(item => item.Name).OrderBy(name => name).ToArray;
но никакой канонической реализации нет и не будет.
Согласен с этим. Но не кажется ли, что таким образом можно любую программу нарезать на паттерны, и утверждать, что она состоит только из них, пусть часто в не очень канонических реализациях?ошибка в самом вопросе.
да, в каждой строчке кода скорее всего можно выделить какой-нибудь паттерн, но это не означает, что программа состоит лишь из паттернов.
фактически, это тоже самое, что сказать, что человек лишь состоит лишь из химических элементов: кислорода, водорода и т.д.
Все, релизация которых тривиальна в динамических функциональных языках.конкретнее, пожалуйста.
раз по твоим словам их много, то тебе легко будет назвать первый попавшийся
ps
То есть говоришь функции: хочу составить класс из таких-то стратегий - и она тебе генерирует класс, который эти стратегии использует. Потом берёшь наследуешь от этого класса - и всё готово.а вот здесь я согласен с -ом, чем правильнее язык, тем меньше шансов, что такое будет.
паттерн проектирования - это лишь идея, а у идеи - не может быть какого-то готового наполнения.
то, что ты хочешь (и здесь я опять согласен с -ом) - есть в громоздких языках (например, Java и т.д. т.к. там да, вот такой вот генератор создает некий готовый каркас под идею. но в более гибких языках - весь этот костыль в виде каркаса не нужен, можно сразу писать без него.
если посмотреть на паттерны проектирования, то они скорее говорят о том, как код надо поделить на части:
фабрика - делит на код, который выбирает исполнителя, и на самих исполнителей,
и т.д.
и вот это самое "поделить" - ни какими готовыми классами не опишешь.
если посмотреть на паттерны проектирования, то они скорее говорят о том, как код надо поделить на частиСогласен. В этом, на мой взгляд, как раз и кроется загадка паттернов "они вроде и нужны, а вроде и не нужны" — часто "как поделить код" можно решить, не прибегая к промежуточному звену — паттернам, а просто взять код (плюс некоторые возможные сценарии его развития) да поделить.
Немного притянутый приемер того, что получится если везде видеть шаблоны - следующим постом.как раз видеть шаблоны - это хорошо, это улучшает структуру кода.
а вот каждый увиденный шаблон заменять на каноническую реализацию - вот это уже конечно ужасно.
ты уверен, что надо было воротить столько кода ради того, что есть лямбда-функции?..
как мне правильно поступить:писать шаблоны проектирования самомуДа, именно так: возьми произвольный паттерн проектирования, попытайся написать реализующий его темплейтный класс на питоне, обнаружь (сам или запостив сюда что это удаление гланд через жопу (т.е. любая решаемая с помощью твоей реализации задача решается в десять раз проще встроенными средствами повторяй до достижения просветления.
@: я правильно понял, что это была шутка юмора? А то тут, кажется, кое-кто этого не понял, так что теперь и мне сомнительно.
правильно понял.
Первый попвышийся: Visitor на любом языке, где есть multiple dispatch, например CLOS.
кольцевых отношений в иерархии классовЧто это?
Первый попвышийся: Visitor на любом языке, где есть multiple dispatch, например CLOS.он не выпадает, он становится тривиальным, и поддерживаемый самим языком.
все равно про этот паттерн помнить надо, потому что если про него забыть, то можно сделать не так, и решение не ляжет на multiple dispatch.
т.е. если кому-то рассказывать решение реализованное на clos-е, то все равно будут слова: "а здесь у нас visitor".
ps
Паттерны проектирования - это зафиксированные "слова/термины", которые использует один разработчик при рассказе на пальцах своего решения другому разработчику.
Что это?Я имел ввиду что-то вроде (там плоховатая статья на эту тему, но понять идею можно) http://en.wikipedia.org/wiki/Circular_dependencies
Конкретно мой ответ -ю был на счёт прмерно вот этого:
Circular dependencies may also cause memory leaks by preventing certain very primitive automatic garbage collectors (those that use reference counting) from deallocating unused objects.Я хотел выяснить, почему он считает, что наличие new/delete как-то сказывается на хороших ООП решениях в языке, если эти решения полностью избавляют архитектуру программы от кольцевых зависимостей.
То есть для ООП необходимо наличие сборщика мусора? Или ты считаешь, что для ООП просто необходима поддержка кольцевых отношений в иерархии классов, или я что-то не так понял?...начнем с более простого: для ООП важно уметь получить в метод(или вернуть из метода) объект/коллекцию объектов
причем раз это базовая вещь - то это должно делаться максимально простым и максимально единообразным(стандартным) способом.
как правильно вернуть объект из метода? (какой из этих способов максимально безошибочный, простой и стандартный):
A GetA;
A* GetA;
A& GetA;
void GetA(A*a);
void GetA(A**a);
void GetA(A&a);
auto_ptr<A> GetA;
ref_count_ptr<A> GetA;
void GetA(auto_ptr<A>& a);
void GetA(ref_count_ptr<A>& a);
Какой процент библиотек/людей использует именно этот стандартный способ?
а сколько есть вариантов для возвращения коллекции?
Сколько библиотек/людей использует именно этот стандартный способ?Мы говорим про ООП или про то, как можно написать плохой код работы с коллекциями на каком-то языке? Тогда нужно сказать, что и C# так же далёк от идеала, как Си++. Особенно если говорить о теме коллекций в стандартной поставке.
а сколько есть вариантов для возвращения коллекции?
Я совсем не вижу в твоей теме проблемы ООП решений на Си++
что это за ООП, если я объект из метода без гемора вернуть не могу...
что это за ООП, если я объект из метода без гемора вернуть не могу...Без какого гемора?
C#
MyClass Create { return new MyClass; } C++
my_class_ptr Create { R(new my_class }my_class_ptr Create { R(new my_class }со скольки библиотеками это будет работать?
ps
предыдущее (C#) работает со всеми.
со скольки библиотеками это будет работать?Какое отношение это имеет к ООП?
my_class_ptr Create { R(new my_class }в интерфейсе - это кстати так же задекларировано будет?
Какое отношение это имеет к ООП?т.е. ООП - это круто, C++ с ООП тоже круто, но использовать ООП реально можно только дома в уголке, потому что в реальном приложении есть куча библиотек - которые возвращает каждая по своему.
но использовать ООП реально можно только дома в уголкеИспользовать можно где и как угодно, я не вижу никаких проблем. Я в упор не понимаю, как описанные тобою недостатки и разногласия в языке относятся к ООП.
Я в упор не понимаю, как описанные тобою недостатки и разногласия в языке относятся к ООП.Вот, например, проблема в C# в моём текущем проекте: из-за отвратительной библиотеки стандартных коллекций для сериализации множества (set) с помощью .NET библиотеки NHibernate необходима ещё одна библиотека для работы с коллекциями. Но это, опять же, слабо соотносится с ООП. То есть нельзя же из-за этого сказать, что всё... ООП в C# никакое.
Использовать можно где и как угодно, я не вижу никаких проблем. Я в упор не понимаю, как описанные тобою проблемы языка относятся к ООП.Мы говорим про реальные приложения, или про программы одного автора на 100 строчек?
реальное приложение - типичная ООП- задача:
необходимо написать адаптер, который из интерфейса IZzz делает интерфейс IXxx
interface IXxx
{
void GetItem(IItem ** item);
}
interface IZzz
{
ref_count_ptr<IItem> GetItem;
}
и как это сделать? а задача-то вроде элементарнейшая...
в итоге, и получается, что на чистом C++ - писать большие ООП-приложения не возможно (большое приложение - это приложение над которым работает больше, чем одна независимая команда)
необходимы всякие доп. соглашения: типа COM/ и т.д.
кстати под *nix скорее всего именно из-за этого продвигается идея: что каждый модуль должен жить в отдельном процессе, т.к. внутри одного процесса нормально модули связать на C++ все равно не получается.
ООП в C# никакое.да, никакое - но лучше, чем в C++, и еще лучше, чем в C.
и как это сделать? а задача-то вроде элементарнейшая...Я использовал паттерн адаптер в моём предыдущем коммерческом приложении на Си++, и действительно элементарно адаптировал интерфейс одного объекта к другому интерфейсу.
Я не вижу связи между термином ООП и проблемами линковки, скорости компиляции, кроссплатформенностью, и прочее, и прочее.
да, никакое - но лучше, чем в C++, и еще лучше, чем в C.Ну а где же тогда "такое"?
Желательно из языков, на которых вообще реально что-то разрабатывать (учитывая все факторы от наличия специалистов и так далее).Я не вижу связи между термином ООП и проблемами линковки, скорости компиляции, кроссплатформенностью, и прочее, и прочее.если на языке C++ на ООП писать дороже, чем без ООП на C++, или с ООП но на C# - то значит, много ООП на C++ и не будет, что мы в принципе и видим.
Ну а где же тогда "такое"? Желательно из языков, на которых вообще реально что-то разрабатывать (учитывая все факторы от наличия специалистов и так далее).более такое - будет в следующем поколении языков, в котором будут убраны явные проблемы текущих языков.
если на языке C++ на ООП писать дороже, чем без ООП на C++, или с ООП но на C# - то значит, много ООП на C++ и не будет, что мы в принципе и видим.Я не понял, как ты посчитал, что дороже? Я сейчас имею столько же (ООП) проблем с C#, сколько совсем недавно имел с Си++, вообще никакой разницы не чувствую.
более такое - будет в следующем поколении языков, в котором будут убраны явные проблемы текущих языковМне страшно подумать, что именно ты считаешь ООП... По мне трёх основных принципов достаточно, остальное - это уже удобства, но не такие, чтобы можно было безаппеляционно утверждать, что ООП в Си++/C#/Java никакое.
Я не понял, как ты посчитал, что дороже?при оплате моего времени по тарифной ставке: 120$/час приведу калькуляции времени, которое тратит средний программист на поддержание ООП в C++ и на поддержание ООП в C#.
Я сейчас имею столько же (ООП) проблем с C#, сколько совсем недавно имел с Си++, вообще никакой разницы не чувствую.сколько сторонних библиотек ты использовал в первом и во втором случае? в каком виде в них было ООП?
Я подумал, что под кольцом тут понимается то же самое что и в математике и испугался, что с ООП связан какой-нибудь эквивалентный машине Тьюринга формализм, типа как лямбда калкулюс в ФП.Я имел ввиду что-то вроде (там плоховатая статья на эту тему, но понять идею можно) http://en.wikipedia.org/wiki/Circular_dependenciesдля ООП просто необходима поддержка кольцевых отношенийЧто это?
ООП в Си++/C#/Java никакоеА где ООП с блэкджеком и шлюхами? Smalltalk/Ruby?
сколько сторонних библиотек ты использовал в первом и во втором случае? в каком виде в них было ООП?При чём тут сторонние библиотеки и ООП в языке программирования? Опять вернулись к теме проблем в языках.
Я же не спрашиваю, в каком виде ООП в стандартных winforms, понимая, что там вообще форсируется программирование в стиле MainClass. В стандартном .NET почему-то упорно не решают ООП проблемы по-человечески.
при оплате моего времени по тарифной ставке: 120$/час приведу калькуляции времени, которое тратит средний программист на поддержание ООП в C++ и на поддержание ООП в C#.У среднего программиста это время ничем не различается. ООП (в понимании Си-подобных языков) поддерживается абсолютно одинаково во всех этих языках. Проблемы линковки, библиотек для языка, кроссплатформенности и системных ресурсов с ООП связаны мало.
my_class_ptr Create { R(new my_class }Поясни, что это за фигня, пожалуйста. А то от каждой интерпретации, приходящей мне в голову, у меня начинают шевелиться волосы по всему телу.
Причём заметь, что проблема возвращения heap-allocated объекта из метода в принципе не очень стрёмная, ну, люди это делают как-то. Напрягаясь, вспоминая текущие соглашения и глядя в описание метода каждый раз (если это хорошие программисты но делают. Я даже не буду указывать на тот очевидный факт, что подразумеваемое утверждение: "в недалёком будущем конпелятор будет оптимизировать нах весь этот десяток вызовов конструкторов копирования" дико напоминает сходные утверждения фанатов хаскеля, но применительно к плюсам обретает особую глубину ироничности. Ох, указал всё-таки.
Есть ведь и другие, гораздо более мучительно реализуемые на языке без GC вещи, например, анонимные функции. И ленивые списки, и итераторы — естественно, как first-class objects, чтобы их можно было куда-нибудь передавать. Ни один человек в здравом уме никогда не захочет руками прописывать, что функцию, переданную в map, диспозить не надо, потому что она нам здесь ещё понадобится, а функцию, повешенную на эвент, наоборот евент должен сам отдиспозить, а здесь её совсем не надо диспозить. И что надо сделать с функцией, переданной в некую функцию f, про которую конпелятор не знает.
Как обычно, большой пост, который по моему субъективному мнению мало попадает в тему. Мы говорим о необходимости GC для ООП языка.
Поясни, что это за фигня, пожалуйста. А то от каждой интерпретации, приходящей мне в голову, у меня начинают шевелиться волосы по всему телу.Какая разница? Что изменится с точки зрения темы данной дискуссии, если я поясню? Если ты знаешь Си++ и все понятные тебе решения ужасны, это значит лишь то, что лично тебе не нравится этот язык. Можно долго флудить и приводить тонны различных аргументов, но это никак не входит в рамки обсуждаемой темы.
Причём заметь, что проблема возвращения heap-allocated объекта из метода в принципе не очень стрёмная, ну, люди это делают как-то. Напрягаясь, вспоминая текущие соглашения и глядя в описание метода каждый раз (если это хорошие программисты но делают. Я даже не буду указывать на тот очевидный факт, что подразумеваемое утверждение: "в недалёком будущем конпелятор будет оптимизировать нах весь этот десяток вызовов конструкторов копирования" дико напоминает сходные утверждения фанатов хаскеля, но применительно к плюсам обретает особую глубину ироничности. Ох, указал всё-таки.Как отсюда сделать вывод о пригодности языка для ООП решений? По-моему, никак. Точно так же в моих глазах будут выглядеть аргументы о том, что Ruby непригоден для ООП, потому что его виртуальная машина может работать только в одном экземпляре на процесс. (Честно скажу, я давно не смотрел, поправили разработчики эту проблему или нет.)
Есть ведь и другие, гораздо более мучительно реализуемые на языке без GC вещи, например, анонимные функции. И ленивые списки, и итераторы — естественно, как first-class objects, чтобы их можно было куда-нибудь передавать. Ни один человек в здравом уме никогда не захочет руками прописывать, что функцию, переданную в map, диспозить не надо, потому что она нам здесь ещё понадобится, а функцию, повешенную на эвент, наоборот евент должен сам отдиспозить, а здесь её совсем не надо диспозить. И что надо сделать с функцией, переданной в некую функцию f, про которую конпелятор не знает.Наличие этих более мучительно реализуемых вещей никак не связано с тем, насколько пригоден язык для ООП. Как пример я мог бы привести Lua. Наличие в нём полноценных (lexical) closures лишь позволяет некоторым способом реализовать инкапсуляцию. В C++/C#/Java это делается ограничением области видимости и интерфейсами. Другие принципы ООП (полиморфизм и наследование) в Lua реализовать тоже достаточно тяжело, и пользоваться ими будет скорее всего не удобно. Таким образом, наличие GC, lexical closures, higher-order functions и anonymous functions никак не повлияло на пригодность языка программирования для ООП. А ведь набор этих фич в Lua получше, чем в C#
То бишь большой проект на функциональном языке не сделаешь - неудобно делать декомпозицию без инкапсуляции.А чем плохи хаскелловские модули как инструмент инкапсуляции?
Оставить комментарий
yroslavasako
есть ли для питона аналог c++шного boostа - библиотека с шаблонами?