Критика классического ООП
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
Критика классического ООП - 2008-10-28 20:07:35.260000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
о великие гуру всея сети, к вам я обращаюсь
давно меня мучает один вопрос, да всё никак мысли в кучу не собираются - может поможете? расскажите мне пожалуйста о недостатках классического ООП (инкапсуляция, наследование, полиморфизм). когда <i>не стоит</i> применять ООП и почему?
заранее отмечу - вопрос производительности, дополнительные long jump'ы по таблице виртуальных функций - это меня интересует меньше всего. прежде всего - проектирование, архитектура, дизайн если хотите. уверен, что многие из вас пишут на языках с поддержкой ООП, да и опыт должно быть немаленький…в общем, приглашаю к дискуссии
да, альтернативы можно рассматривать любые. как иных парадигм - процедурную там, функциональную, логическую, объектно-базированную…так и иных ООП (основанных на делегировании, прототипировании, с актёрами…в общем, кому что ближе)
ну, поехали
|
|
|
|
|
RE: Критика классического ООП - 2008-10-28 20:36:07.380000
|
|
|
VENOM4X
Сообщений: 246
Оценки: 0
Присоединился: 2008-02-18 22:49:08.960000
|
ИМХО в драйверах ООП как-то не прижился :-)
Хотя, может кто-то и пишет дрова с ООП.
OFFTOP:
Читали? "Глава «Руссофт» предложил создать великий русский фаерволл"
http://www.securitylab.ru/news/361854.php
Скоро будем как китайцы…
|
|
|
|
|
RE: Критика классического ООП - 2008-10-28 20:43:05.740000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: VENOM4X
ИМХО в драйверах ООП как-то не прижился :-)
Хотя, может кто-то и пишет дрова с ООП.
ну, это не ответ. вопрос в том, почему он там не прижился? и действительно ли он там не нужен?
кстати, дрова с применением ООП как раз пишут на ура, неоднократно наблюдал: как правило там используется урезанный C++. советую ещё посмотреть исходники M$ Singularity, там умеренно ООП'шный Sing# вполне себе живёт, bleeding edge современного CS так сказать
|
|
|
|
|
RE: Критика классического ООП - 2008-10-28 21:16:27.206666
|
|
|
SmanxX1
Сообщений: 208
Оценки: 0
Присоединился: 2007-07-31 14:33:56.650000
|
Какой-то странный и не понятный вопрос… Подобные вопросы по ООП было бы уместно задать лет 40 назад, сейчас уже все разжевано и реализовано.
Или просто поболтать нескем?! Тогда лучше перенести этот топик в треп.
|
|
|
|
|
RE: Критика классического ООП - 2008-10-28 21:33:40.463333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: SmanxX1
Какой-то странный и не понятный вопрос… Подобные вопросы по ООП было бы уместно задать лет 40 назад, сейчас уже все разжевано и реализовано.
Или просто поболтать нескем?! Тогда лучше перенести этот топик в треп.
что непонятно - спрашивай, поясню. кстати, покажи мне ООП которое было лет 40 назад - это ты чудесно, конечно, ляпнул. насчёт "разжёвано и реализовано" - просьба говорить по существу. если по существу сказать нечего - лучше молчать
касательно актуальности скажу так: серебряной пули нет. у любого подхода есть недостатки. вот и прошу перечислить недостатки ООП. то что ты можешь не знать ни одного, говорит только о твоём плохом понимании ООП и архитектуры ПО, но никак не о неактуальности вопроса в целом
|
|
|
|
|
RE: Критика классического ООП - 2008-10-29 02:47:19.046666
|
|
|
_SaZ_
Сообщений: 4329
Оценки: 398
Присоединился: 2008-01-30 02:18:05.553333
|
Модульность и С++. Ещё те грабли. Все, рано или поздно, сталкиваются с тем, в каком порядке инклюдать заголовочные файлы и вообще, что следует в них выносить.
|
|
|
|
|
RE: Критика классического ООП - 2008-10-29 04:13:04.390000
|
|
|
kreol
Сообщений: 823
Оценки: 0
Присоединился: 2007-03-08 03:13:06.876666
|
ИМХО, главный минус ООП в том, что оно слишком популярно. Из-за этого его стремятся присобачить везде, куда не лень, даже туда, где оно сто лет на надо. Был пример в самый разгар ООП, когда одну систему на Си решили переписать на С++. В результате система получилась в три раза более громоздкой и медленной. Последние языки, такие как C# и Java, решая в основном задачи классического процедурного программирования, тем не менее полностью перешли на модель классов. Именно классы в них являются единицей компиляции и загрузки. Из-за этого возник ряд проблем, например, необходимость вручную создавать объекты-синглтоны, которыми в старых языках являлись простые файлы модулей.
Изначально в Smalltalk расширение типа (наследованием оно вроде ещё не называлось) использовалось для передачи сообщений (так же, как сейчас используется в драйверах). Объект принимал сообщения определённого класса или наследников этого класса, которое мог принять и обработать или переслать другому объекту (это, как я понимаю, была основная фишка - пересылать задание до тех пор, пока его не сделает объект, который лучше всего с этим справляется :)). Принцип "сообщение - расширяемый класс" делает некоторые задачи просто элементарными. Например, видел классную реализацию широковещания на Обероне, когда сообщение посылалось всем зарегистрированным модулям. Каждый модуль "просеивал" сообщение через цепочку проверок типа, и если тип сообщения не совпадал ни с одним из них, то оно просто отбрасывалось, иначе проводилась обработка. Как мне кажется, это самое правильное применение ООП.
Соответственно, как альтернативу объектно-ориентированному программированию я бы предложил модульное программировние. Насколько мне позволяет судить мой опыт, для большинства задач нет необходимости плодить кучу объектов одного типа. В любом случае, всегда остаются старые добрые записи (record, struct). Абсолютно не вижу смысла пихать процедуры обработки данных в сами эти структуры. В Обероне-2, если я не ошибаюсь, расширяемые записи даже на хранят таблицы виртуальных методов - границы модуля обеспечивают свободное переопределение методов. Не то, чтобы это давало какие-то большие преимущества, но такая архитектура мне кажется более простой и красивой, чем использование десятков классов. К тому же видел работы по разработке так называемых аддонов к модулям, позволяющим расширять и сами модули (см. работы Сурковых на oberoncore.ru).
Где-то в загашнике лежали аргументы против ООП посильнее, чем некрасивая архитектура и неправильное использование расширяемости класса, но сейчас в голову ничего не приходит. Вспомню - напишу.
|
|
|
|
|
RE: Критика классического ООП - 2008-10-29 12:58:32.700000
|
|
|
_SaZ_
Сообщений: 4329
Оценки: 398
Присоединился: 2008-01-30 02:18:05.553333
|
Оффтоп: P.S. Сурковы у нас лекции читают =)
|
|
|
|
|
RE: Критика классического ООП - 2008-10-29 13:16:00.846666
|
|
|
SmanxX1
Сообщений: 208
Оценки: 0
Присоединился: 2007-07-31 14:33:56.650000
|
quote:
кстати, покажи мне ООП которое было лет 40 назад
Simula 67 (1967г.)
quote:
просьба говорить по существу. если по существу сказать нечего - лучше молчать
Т.е. тебе лучше молчать? )))) Сам то для начала расскажи "по существу".
|
|
|
|
|
RE: Критика классического ООП - 2008-10-29 19:00:47.010000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
спасибо за развёрнутый ответ, рад что таки есть с кем поговорить :)
однако по существу: приведённые проблемы в массе своей являются следствиями недостатков классической модели ООП. кстати, вообще говоря, придумывая термин ООП Алан Кей имел в виду менно Smalltalk…
|
|
|
|
|
RE: Критика классического ООП - 2008-10-29 19:05:54.683333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: _SaZ_
Модульность и С++. Ещё те грабли. Все, рано или поздно, сталкиваются с тем, в каком порядке инклюдать заголовочные файлы и вообще, что следует в них выносить.
какое отношение недостатки конкретно C++ имеют к недостаткам ООП?
|
|
|
|
|
RE: Критика классического ООП - 2008-10-30 03:08:35.856666
|
|
|
_SaZ_
Сообщений: 4329
Оценки: 398
Присоединился: 2008-01-30 02:18:05.553333
|
Считай это оффтопом для поддержания дискуссии.
|
|
|
|
|
RE: Критика классического ООП - 2008-10-30 13:40:49.843333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: _SaZ_
Считай это оффтопом для поддержания дискуссии.
это провокативный увод дискуссии от основного вопроса
а вообще активность этого топика весьма показательна: по существу вопроса отвечает один человек. ну да посмотрим что будет дальше
|
|
|
|
|
RE: Критика классического ООП - 2008-11-14 20:15:34.916666
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
по теме (мало ли, вдруг кто осилит):
http://cliffordbeshers.blogspot.com/2008/11/functional-programming-and-universe.html
|
|
|
|
|
RE: Критика классического ООП - 2008-11-22 17:22:31.466666
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
ООП возникло, если мне не изменяет память, для решения задач моделирования (см. Simula 67). ООП рассматривает сущности программы (переменные или даже саму программу ("глобальное ООП")) как совукупность взаимодействующих объектов с собственным поведением, которые могут быть связаны отношением наследования. Т. е. задачи, допускающие подобные абстракции, разумно решать с помощью ООП.
Суть ООП кратко можно описать так:
quote:
Центральным понятием здесь являются объекты (по-существу являющиеся записями в традиционной терминологии) и классы объектов (=типы записей), которые могут быть связаны отношениями наследования. Например, все односвязные списки состоят из элементов (записей), имеющих поле-указатель на следующую запись. Процедурам, работающим со списками в простейшем случае, достаточно знать только о наличии этого поля. Все типы записей, у которых кроме этого поля есть еще и другие, "содержательные" поля, можно объявить "потомками" ("расширениями") некоего общего типа-предка, у которого только и есть поле-указатель. Если написать процедуру, скажем, добавления в список нового элемента типа-предка, то она будет использовать только поле-указатель. Но такая процедура будет в принципе работать корректно, если вместо параметра типа-предка подставить любую запись любого расширенного типа-потомка. Языковый механизм, обслуживающий подобное абстрагирование, и есть механизм ООП: связь между типом-предком и типами потомками называется не вполне удачным термином наследование [inheritance], а возможность подставлять потомков вместо предка — полиморфизм [polymorphism]. Этот достаточно простой смысл ООП (изначально явный в Симуле-67) был затемнен в языках типа Smalltalk, где ему в порыве типичного энтузиастического восторга был придан универсальный статус. В частности, множественное наследование (С++ и т.п.) уже невозможно рассматривать как естественно-неизбежное развитие языковых средств — оно и приводит к большим трудностям как при реализации, так и в использовании.
Как уже сказал kreol, главная проблема ООП в том, что его используют везде, где можно и нельзя. Плюс в популярных ЯП оно смешалось с модульностью (инкапсуляция, вообще-то, отдельная от наследования и полиморфизма вещь), что зделало нерациональным системное программирование (СП) с использованием объектов. В СП имеется необходимость иметь группы маленьких классов, которые могли бы взаимодействовать без дополнительных накладных расходов.
Фундаментальная проблема ООП при создании надежных крупных программных систем представляет собой наличие хрупких базовых типов.
quote:
проблема может проявиться при попытке изменить реализацию типа-предка, когда может оказаться, что изменить реализацию типа-предка даже при неизменных интерфейсах его методов невозможно, не нарушив корректность функционирования типов-потомков.
А "апгрейд" ООП - это созданное Виртом КОП (Компонентно-ориентированное программирование).
|
|
|
|
|
RE: Критика классического ООП - 2008-11-22 20:51:49.386666
|
|
|
rtw
Сообщений: 1372
Оценки: 0
Присоединился: 2004-08-19 00:28:05
|
Патерны решают ибо кровью и потом программистов всего мира написаны. Так что где-бы то не было- ООП поможет коду пожить подольше.
|
|
|
|
|
RE: Критика классического ООП - 2008-11-23 15:13:40.240000
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
quote:
ORIGINAL: rtw
Патерны решают ибо кровью и потом программистов всего мира написаны. Так что где-бы то не было- ООП поможет коду пожить подольше.
Это здесь причем?
|
|
|
|
|
RE: Критика классического ООП - 2008-11-23 15:16:00.990000
|
|
|
_SaZ_
Сообщений: 4329
Оценки: 398
Присоединился: 2008-01-30 02:18:05.553333
|
Как это причём? Без помощи ООП реализация читабельных (в смысле кода) правтически невозможна.
|
|
|
|
|
RE: Критика классического ООП - 2008-11-23 15:50:52.596666
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
Ну это спорно. И речь не о читабельности.
|
|
|
|
|
RE: Критика классического ООП - 2008-11-23 16:35:17.020000
|
|
|
_SaZ_
Сообщений: 4329
Оценки: 398
Присоединился: 2008-01-30 02:18:05.553333
|
Ну поспорь. Можно и курицу петухом называть, только вот не факт, что так и окажется.
|
|
|
|
|
RE: Критика классического ООП - 2008-11-23 19:36:33.870000
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
А может и оказаться! :D
Читабельность кода обеспечивают, во-первых, модульность - разбиваем задачу на подзадачи и, во-вторых, структурность конструкций внутри модулей - секции описаний и процедуры (в том числе вложенные). Вроде очевидно. Но я уже писал, что модульность (инкапсуляция) к ООП значения, вообще то, не имеет.
Так что, Вы поете не о том. ;)
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 12:06:48.950000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: _SaZ_
Как это причём? Без помощи ООП реализация читабельных (в смысле кода) правтически невозможна.
маркетоидный бред
http://www.md.chalmers.se/~rjmh/Papers/whyfp.pdf (оригинал)
http://www.softcraft.ru/paradigm/fp/whyfp.shtml (перевод на русский)
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 12:09:58.090000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: rtw
Патерны решают ибо кровью и потом программистов всего мира написаны. Так что где-бы то не было- ООП поможет коду пожить подольше.
http://homepages.mcs.vuw.ac.nz/~tk/fps/
коротко говоря, если в ООП-коде появились паттерны (хотя бы GoF), то ООП в задаче, скорее всего, неуместен - и задачу стоит решать другими методами. советую ознакомиться с работами Коплиена (мультипарадигменное проектирование) и Вайсса (программные семейства), чтобы иметь хотя бы общее представление о предмете дискуссии
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 12:12:09.543333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
А "апгрейд" ООП - это созданное Виртом КОП (Компонентно-ориентированное программирование).
более-менее согласен во всём, единственно отмечу что это не единственный апгрейд ООП; более того, я бы не назвал его лучшим
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 17:16:27.473333
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
А какие еще есть? Непосредственно ООП? Вроде бы КОП объективно устраняет указанные выше недостатки… В обчем, заинтересовало. Поясни, если не лень :)
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 20:03:41.150000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
А какие еще есть? Непосредственно ООП? Вроде бы КОП объективно устраняет указанные выше недостатки… В обчем, заинтересовало. Поясни, если не лень :)
метаобъектный протокол из CLOS:
http://en.wikipedia.org/wiki/Metaobject_Protocol
ООП на делегировании в Tcl:
http://en.wikipedia.org/wiki/Snit
классы типов и семейства типов в Haskell:
http://haskell.org/haskellwiki/OOP_vs_type_classes
http://haskell.org/haskellwiki/GHC/Type_families
а есть ещё, например, прототипное программирование:
http://en.wikipedia.org/wiki/Prototype-based_programming
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 21:29:31.196666
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
Спасибо.
Вот намутили… :):)
Но это все скорее разновидности ООП, причем, на мой взгляд, весьма сомнительные. Явных преимуществ не вижу, если рассматривать это как универсальные эффективные и надежные средства. Короче, а почти задеревенелый приверженец КОП. :D
——————
Настоятельно рекомендую почитать статью Вирта "Хорошие идеи: взгляд из Зазеркалья".
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 22:23:54.530000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
Спасибо.
Вот намутили… :):)
Но это все скорее разновидности ООП, причем, на мой взгляд, весьма сомнительные. Явных преимуществ не вижу, если рассматривать это как универсальные эффективные и надежные средства. Короче, а почти задеревенелый приверженец КОП. :D
ну, не совсем. CLOS/MOP - это, в общем-то, лучшее, что может дать классическое ООП - включая множественную диспетчеризацию и самое позднее связывание; Snit - доведённая до предела техника code reuse: с любым кодом (хоть двадцатилетней давности) он позволяет работать как с объектно-ориентированным; Haskell Type Classes - ну, там описано чем они лучше ООП :) достаточно детально
а задеревеневать не стоит - если технология выбрана верно, то расширение горизонтов только упрочнит отношение к ней; а в чём-то и поможет более эффективно её применять
quote:
ORIGINAL: linuxoid
Настоятельно рекомендую почитать статью Вирта "Хорошие идеи: взгляд из Зазеркалья".
спасибо, почитаю
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 23:37:06.416666
|
|
|
linuxoid
Сообщений: 87
Оценки: 0
Присоединился: 2007-04-15 11:11:15.030000
|
quote:
ну, не совсем. CLOS/MOP - это, в общем-то, лучшее, что может дать классическое ООП - включая множественную диспетчеризацию и самое позднее связывание; Snit - доведённая до предела техника code reuse: с любым кодом (хоть двадцатилетней давности) он позволяет работать как с объектно-ориентированным; Haskell Type Classes - ну, там описано чем они лучше ООП :) достаточно детально
C англицкой мовой у меня хреново - так что как следует прочитал не все. [:(]
Хочется обратить внимание на присутствие средств метапрограммирования в Обероне (динамическая модульность, виртуальные функции на уровне экземпляров типов, проверка динамического типа) - и без всяких наворотов. ;)
quote:
а задеревеневать не стоит - если технология выбрана верно, то расширение горизонтов только упрочнит отношение к ней; а в чём-то и поможет более эффективно её применять
Конечно! :)
Немного оффтоп, но интересно: http://forum.xakep.ru/fb.aspx?m=1275063. В том числе предлагается строить ортогональные системы ЯП разных уровней и парадигм (О языках реализации в проекте новой ОС, Ортогональная система языков в проекте "Роса").
|
|
|
|
|
RE: Критика классического ООП - 2008-11-24 23:41:52.310000
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
quote:
ORIGINAL: linuxoid
Немного оффтоп, но интересно: http://forum.xakep.ru/fb.aspx?m=1275063. В том числе предлагается строить ортогональные системы ЯП разных уровней и парадигм (О языках реализации в проекте новой ОС, Ортогональная система языков в проекте "Роса").
извини, но работы Богатырёва вызывают у меня зевоту. слишком много амбиций и слишком мало здравого смысла
|
|
|
|
|
RE: Критика классического ООП - 2008-11-25 18:32:58.953333
|
|
|
Denaturat
Сообщений: 1741
Оценки: 453
Присоединился: 2008-10-27 20:50:06.380000
|
http://lambda-the-ultimate.org/node/3101
вот ещё к вопросу немного
|
|
|
|
|
|
