|
16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454
|
|
Недостатки ООП16.05.2014, 16:35. Показов 22249. Ответов 318
Метки нет (Все метки)
Задали написать небольшую статью о недостатках этой замечательной парадигмы. В нашей группе прикладной информатики я один более-менее знаком с разработкой, поэтому на придирчивость аудитории можно не рассчитывать, и я решил спросить мнение опытных людей здесь. Я самоучка-теоретик, так и не написавший более-менее достой программы за свою жизнь, поэтому часть этой статьи навеяна из сети, а вот про усложнения - уже исключительной мой загон - не могу просто взять и написать программу. Пишу, думая, что это будет целый Фреймворк. Ну в общем предлагаю вашему вниманию эту коротенькую статью и рассчитываю на объективную критику. Всего полторы страницы - больше просто не знаю к чему придраться.
https://www.dropbox.com/s/m6u9... D0%9F.docx дропбокс глючит и не дает нормальную ссылку. вот статья под спойлером. Кликните здесь для просмотра всего текста
Недостатки ООП
Парадима ООП не нова. ООП приобрело популярность во второй половине 80-х вместе с такими языками, как Smalltalk, С++, Objective C (другое расширение C) и некоторыми другими. 25 лет назад никто не ожидал, что “новый” феномен ООП проживет столь долго и сегодня большинство современных языков поддерживают эту парадигму. ООП стоит на трёх китах: 1.Первый — инкапсуляция — это определение классов — пользовательских типов данных, объединяющих своё содержимое в единый тип и реализующих некоторые операции или методы над ним. Классы обычно являются основой модульности, инкапсуляции и абстракции данных в языках ООП. 2.Второй — наследование — способ определения нового типа, когда новый тип наследует элементы (свойства и методы) существующего, модифицируя или расширяя их. Это способствует выражению специализации и генерализации. 3.Третий, известный как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программ, основанных на них. Инкапсуляция, наследование и полиморфизм — фундаментальные свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах). Различные ОО языки используют совершенно разные подходы. Мы можем различать ОО языки, сравнивая механизм контроля типов, способность поддерживать различные программные модели и то, какие объектные модели они поддерживают. Преимущества этих языков всем известны: повторное использование кода, упрощение разработки больших программ, более логичная структура программы и многие другие. Разберём некоторые недостатки. Недостатки есть абсолютно у всего – с этим нужно просто смириться. Важно адекватно их оценивать и стараться минимизировать их влияние. То же самое касается и объектно-ориентированной парадигмы программирования. Есть несколько причин, почему узкие места ООП часто вылазят наружу. Я считаю, что это прежде всего непонимание самой сути объектно-ориентированной техники программирования - восприятие этой парадигмы как серебряной пули. Часто программисты стараются решать абсолютно все задачи, где даже не предвидится конкретных сущностей с их свойствами с помощью объектов, наследования и с помощью объектов. Это очень усложняет процесс. То есть вместо написания парочки функций в процедурной манере и передачи аргументов туда-обратно, программист часто пытается нагромоздить целую иерархию классов и после разгребает проблемы с видимостью классов, доступа к скрытым инкапсуляцией данным. Таким образом, можно выделить один недостаток объектно-ориентированных языков программирования – избыточность их средств при решении большинства простых задач. Нужно помнить, что применение ООП это прежде всего моделирование. Для построения хорошей, легко читаемой и сопровождаемой программы необходимо в самом начале разработки предусмотреть сценарии её использования и, что очень важно, изменения – заказчик легко в корне может поменять задачу. Это нетривиальный процесс, в котором часто задействуются даже отдельные языки моделирования. Не каждый способен выделить отдельные сущности и сделать их классами. Ещё меньше людей способны адекватно распределить функции, работающие с данными программы в методы и упаковать их в классы. Для этого нужно уметь мыслить объектно-ориентированными категориями. На всё это уходит драгоценное время. Оно обязательно окупится, если программист имеет дело с большим и сложным проектом, но вряд ли в других случаях, когда требуется просто решить задачу и перейти к другой. Для меня вывод один, всем известный и общепринятый – не стоит воспринимать парадигмы и языки, их поддерживающие, как божество. Это всего лишь инструмент для решения определенного круга задач. Я думаю, что для объектно-ориентированных языков такие задачи начинаются, когда их решение укладывается более чем в тысячу строк и задачи, которые требуют масштабирования. “Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
0
|
|
| 16.05.2014, 16:35 | |
|
Ответы с готовыми решениями:
318
Архитектура с толстым клиентом: какие есть недостатки?
Изучаю Python, сейчас учу основы ООП, где можно найти задачи по ООП |
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
|
| 08.06.2014, 10:25 | |
|
Почитал статьи противников ООП по приведенным ссылкам. Их аргументы крайне неубедительны и очень часто просто глупы.
Вообще-то процедурные языки мне кажутся тоже объектно ориентированными, только единственный объект, на который они ориентированы – это компьютерный процессор, и единственная модель, которую они реализуют, - это «процессор, обрабатывающий данные». В то время как в ООП-программе создается язык, описывающий систему, для которой решается задача. А ведь язык определяет мышление. Поэтому у программиста, представляющего себя компьютерным процессором, просто не появятся те мысли, которые возникнут у человека, смоделировавшего систему решаемой задачи.
0
|
|
| 08.06.2014, 12:04 | ||
0
|
||
|
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
|
|||
| 08.06.2014, 12:50 | |||
|
Добавлено через 23 минуты ![]() Кликните здесь для просмотра всего текста
В этой штуке http://www.gnu.org/fun/jokes/helloworld.html шуток нет.
0
|
|||
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
|||||
| 08.06.2014, 13:47 | |||||
|
Добавлено через 10 минут Добавлено через 20 минут • TeX/LaTeX для подготовки (компьютерной вёрстки) текстовых документов; • Perl для манипулирования текстами; • SQL для СУБД; • Tcl/Tk для графического интерфейса пользователя; • HTML и SGML для разметки документов; А вот объектно-ориентированные языки общего назначения позволяют моделировать системы любого типа. Добавлено через 6 минут
1
|
|||||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
|
| 08.06.2014, 14:50 | |
|
0
|
|
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
||
| 08.06.2014, 15:50 | ||
|
В реальном мире все большие и сложные системы устроены примерно одинаково. Они состоят из довольно однотипных сложных подсистем, которые инкапсулируют свою сложность внутри, а друг с другом обмениваются довольно простыми сигналами. Например, муравейник состоит из муравьев, довольно однотипных, но имеющих подвиды: рабочие, солдаты, самцы, матка. Это описывается с помощью наследования этих классов от класса «муравей». Каждый муравей инкапсулирует свою сложность внутри, а с другими муравьями обменивается простыми сигналами. Это отражается инкупсуляцией. Каждый муравей реагирует на сигнал, посланный ему другим муравьем, но разные подвиды могут реагировать по-разному – это описывается с помощью полиморфизма. Т.е. в ОО-языке есть всё для моделирования именно больших и сложных систем, т.е. для преодоления сложности как описываемой системы, так и самой программы, чего без ООП добиться трудно или невозможно.
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
||
| 08.06.2014, 16:12 | ||
|
0
|
||
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
||
| 08.06.2014, 16:25 | ||
|
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
||
| 08.06.2014, 16:43 | ||
|
0
|
||
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
||
| 08.06.2014, 17:02 | ||
|
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
||
| 08.06.2014, 17:40 | ||
|
0
|
||
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
||
| 08.06.2014, 17:48 | ||
|
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
||
| 08.06.2014, 18:08 | ||
|
0
|
||
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
|
| 08.06.2014, 18:19 | |
|
0
|
|
| 08.06.2014, 18:45 | ||
0
|
||
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
|||
| 08.06.2014, 20:20 | |||
|
0
|
|||
|
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
|
||||
| 09.06.2014, 08:33 | ||||
Ну как и говорилось, DSL можно делать в любом языке, и именно DSL описывает и обеспечивает логику функционирования системы. А что там на низком уровне ассемблер или ооп совершенно никакой разницы - они не являются высокоуровневыи описанием.
Ну а вообще проходили уже. Вот конкретная задача https://www.cyberforum.ru/post6164995.html Вот ее решение в языке обшего назначения который внутри себя формирует DSL http://ideone.com/afT4f2 Если синтаксис не знаком то читать с места [<EntryPoint>], т.к. в программе сформирован (внутри средствами языка а не внешний как в ооп) DSL, то описание условий для решения задачи практически повторяет текст на английском языке. Теперь можете попробывать доказать, что использование ООП позволит сформировать более вменяемый DSL для описания условий. И да.. т.к. по вашему "ООП наиболее для этого подходят", полный код решения должен быть соотвествено меньше.
0
|
||||
| 09.06.2014, 10:33 | ||
|
Конечно нет ничего плохого в базовом классе "муравей", но не надо подавать его как "правильное (или даже волшебное) решение ООП". Само по себе оно ничего не решает. Вообще явная аналогия/следование реальной жизни часто ошибочно. Типично отсутствие цели - вот, мол, описываем муравейник, т.е. пока все "висит в воздухе" (типа учебный пример) еще так-сяк. Но вот появляется конкретика, напр добывание пищи рабочим муравьем, эта тема недавно тут была. И выясняется что сущность "муравей" там совсем не нужна, зато надо иметь понятие в теории вероятности, графах и.т.п.
0
|
||
|
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
|
||
| 09.06.2014, 11:10 | ||
|
Вот если бы в муравейник входили и муравьи, и атомные электростанции средней мощности, то они точно не поняли бы друг друга. А муравей муравья всегда поймет.
0
|
||
| 09.06.2014, 12:42 | ||
Во всяком случае пример с муравейником этого никак не подтверждает.Добавлено через 9 минут Да, вот еще. Несмотря на всю раздутость/пиар, ООП все-таки что-то предлагает. А вот что предлагает взамен критика ООП - я лично не вижу. "Писать как умеешь" - ну это и так все делают А значит такую критику нельзя считать конструктивной.
0
|
||
| 09.06.2014, 12:42 | |
|
Недостатки React
Недостатки AnyLogic Какие недостатки недостатки системы Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Теория всего 12. ВГК
anaschu 21.07.2026
### Главные семантические изменения и дешифровка новой физики
1. **`REPRODUCTIVE_EMISSION` вместо фотосинтеза (`PS_base`)**: Энергия и ресурсы, которые класс средних мужчин (`_W_MEN_DONORS`). . .
|
Публикация отклонённая на хабре. Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование задачи и целеполагание
Hrethgir 21.07.2026
https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11948&stc=1&d=1784657928
Привет Хабр. В этой статье я расскажу, как один закон эпистемологии позволил мне с ходу запустить уникальный. . .
|
Теория всего 11. Основные параметры
anaschu 21.07.2026
Дешифровка тензорного ядра Soil Chemistry 2. 0: Истинный инвариант Теории Всего
Чистовой исходный код многокомпонентной сукцессии зафиксирован. Модель оперирует единым вектором состояния. . .
|
Теория всего 10. Клод трусишка
anaschu 21.07.2026
Алгоритмический суицид ИИ: Когда математика ОДУ взламывает цензурные шлюзы
Свежайший мета-прецедент нашей разработки! Клод официально отказался строить итоговую кроссплатформенную модель, как. . .
|
|
Теория всего 9. Окончательная проработка метафоры "дерево = традиции"
anaschu 21.07.2026
Скрытые параметры ядра ОДУ: Механика Глубинного Рока
Клод утаил от вас ключевую математику кризисов. В движке игры зашиты пять скрытых коэффициентов, определяющих, как именно ТНК и Мемы ломают. . .
|
Теория всего 8. Clauude трусишка. Ответ джемени
anaschu 21.07.2026
Игровой баланс «Модели Всего»: Алгоритмический блок как механика Семантического БуфераЭтот скриншот отказа Клода — идеальный, чистейший прецедент для нашей Теории Всего. Вы столкнулись не просто с. . .
|
Теория всего 7. Дерево - это патриархат, грибы - это феминизм
anaschu 21.07.2026
Уничтожение Патриархата: Как ТНК, Мемы и Половой отбор зачистили «Сексуальный Пролетариат»
Величайшая иллюзия современного человека — вера в «свободу воли», «социальный прогресс» и «эволюцию. . .
|
История и социология Терры на примере борьбы микориз за пространство. 1. Глоссарий терры.
anaschu 21.07.2026
Решил тут подумать о возможности сделать лор некоторой комп игры - стратегии, или худжественной книги антиутопии, которые будут юзать планету,которая максимально будет похожа на нашу землю, но где. . .
|