|
16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454
|
|
Недостатки ООП16.05.2014, 16:35. Показов 22242. Ответов 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, сейчас учу основы ООП, где можно найти задачи по ООП |
|
236 / 196 / 21
Регистрация: 04.06.2014
Сообщений: 1,309
|
|||
| 14.09.2016, 17:29 | |||
|
Добавлено через 2 часа 50 минут
0
|
|||
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||
| 14.09.2016, 20:56 | ||
|
0
|
||
|
Заблокирован
|
|
| 02.11.2016, 21:48 | |
|
Вот существует стереотип, что якобы ООП якобы помогает бороться со сложностью задачи.
Что в ООП путем разбивки задачи на классы и уменьшения связности/зависимости мы уменьшаем сложность задачи. Что разделение задачи на «интерфейс» и «реализацию» упрощает решение задачи. Вообщем, не буду рассказывать все стереотипы об ООП, про которые мы все знаем. Но давайте разберемся и вникнем в детали (реализации). Ведь, как известно, «дьявол в деталях»©. Говорят «интерфейс» и «реализация». А что такое «интерфейс» класса? А это ни что иное как список заголовков PUBLIC методов. А что такое «заголовок метода»? Это имя метода плюс список ТИПОВ его параметров. И вот мы подходим к ключевому моменту: А что такое «типы параметров»? А это не что иное как КЛАССЫ, которые описаны вне данного класса, и которые также имеет интерфейс. Бинго! Получается, что раскрутив всю логическую цепочку, мы видим, что фактически интерфейсом класса является СПИСОК ОПИСАННЫХ ВОВНЕ ДРУГИХ КЛАССОВ. А у тех классов интерфейс – это тоже список описанных вне их классов. И т.д. Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ. Т.е. при ООП никакого упрощения программирования не происходит. Напротив, из-за того, что «ВСЕ СВЯЗАНО СО ВСЕМ» произошло существенное усложнение программирования. Миф об ООП развенчан. Спасибо за внимание. © Все права защищены. При цитировании этой информации где-бы то ни было, ссылки на меня обязательны
0
|
|
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
||
| 03.11.2016, 10:11 | ||
|
(Для доказательства того, что это неверно, достаточно привести пример двух классов, не связанных между собой.) Соответственно, не верны и все Ваши последующие выводы.
0
|
||
|
Заблокирован
|
||||
| 04.11.2016, 10:09 | ||||
|
Добавлено через 13 часов 40 минут Получается что мало того, интерфейс "раздувается" настолько, что с ним просто невозможно работать. Так еще получается что никакой "инкапсуляции" нет. Так как ты не можешь ПРОИЗВОЛЬНО менять описанные вовне классы, так как от них у тебя зависят "кишки" данного класса Добавлено через 5 минут
0
|
||||
|
3258 / 2060 / 351
Регистрация: 24.11.2012
Сообщений: 4,909
|
||
| 04.11.2016, 10:38 | ||
|
Булщит начинается со слов:
0
|
||
|
Заблокирован
|
||
| 04.11.2016, 20:07 | ||
|
У Вас есть какое-то альтернативное определение? Тогда озвучьте. А "посылать в гугль" я тоже умею.
0
|
||
|
3258 / 2060 / 351
Регистрация: 24.11.2012
Сообщений: 4,909
|
|
| 04.11.2016, 20:12 | |
|
0
|
|
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
||
| 04.11.2016, 20:44 | ||
|
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
|||
| 04.11.2016, 21:14 | |||
|
Добавлено через 56 секунд
0
|
|||
|
Заблокирован
|
||
| 04.11.2016, 21:21 | ||
|
0x10,
"Существует 4675 определений понятия "вероятность". И что удивительно: все правильные"© Так что о чем мы спорим? Добавлено через 1 минуту Смело ![]() Добавлено через 1 минуту 0x10, И не надо мне цитировать то, что Вы сами не понимаете. Вы своими словами, на пальцах, объясните, что такое интерфейс класса в С++, как это сделал я
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
||
| 04.11.2016, 21:39 | ||
|
0
|
||
|
Заблокирован
|
||
| 04.11.2016, 21:59 | ||
|
Поэтому я и попросил, чтобы 0x10, не копипасту давал, а то, как он сам это понимает. На пальцах.
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
|
| 04.11.2016, 23:32 | |
|
0
|
|
|
3258 / 2060 / 351
Регистрация: 24.11.2012
Сообщений: 4,909
|
|
| 05.11.2016, 02:36 | |
|
0
|
|
|
Заблокирован
|
||
| 05.11.2016, 08:51 | ||
|
0x10, Спасибо за ответ. Он очень информативен.
Добавлено через 42 минуты ![]() А если класс не "чисто абстрактный", то у него и иникакого интерфейса нет?
0
|
||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
|
| 05.11.2016, 13:06 | |
|
ИсмаилПркопенко,
Функции принимают аргументы. И это 1) не является недостатком, и 2) присуще не только ООП. Например, метод Sin класса Math принимает аргумент класса Double. Какую проблему Вы в этом видите?
0
|
|
|
3258 / 2060 / 351
Регистрация: 24.11.2012
Сообщений: 4,909
|
||
| 05.11.2016, 13:06 | ||
|
0
|
||
|
Заблокирован
|
|||
| 05.11.2016, 22:24 | |||
|
Добавлено через 2 минуты На вопрос, я так понимаю, не ответите? У НЕ абстрактного класса нет интерфейса?
0
|
|||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
||
| 05.11.2016, 23:57 | ||
|
Если у Вас "Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ.", то это недостатки дизайна, а не недостатки ООП.
0
|
||
| 05.11.2016, 23:57 | |
|
Недостатки React
Недостатки AnyLogic Какие недостатки недостатки системы Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Нейтральные знания ..., ... чистая наука. Пока что-то проходит модерацию на Хабре, стоит развить мысль ...
Hrethgir 20.07.2026
К таким радикальным взглядам я конечно в той публикации не приходил, но чтобы скоротать вечер, решил углубиться немного.
1. Почему показания термометра заряжены целью?
Цель заложена в самом. . .
|
Установка нескольких штампов электронной подписи в строго определенных местах файла docx
ВладимирСамохин 19.07.2026
(В!) Работа с Электронной подписью - это неотъемлемая часть современного документооборота. Но что делать, если нужно поставить несколько штампов электронной подписи в строго определенных местах. . .
|
сукцессия 35. Научная статья о проделанной работе
anaschu 19.07.2026
Написал в формате латекс и пдф
|
Вангую, что это не пройдёт модерацию, и на неделе я запущу свой сервер.
Hrethgir 19.07.2026
Эта публикация сейчас в песочнице и ждёт приглашения.
https:/ / habr. com/ ru/ sandbox/ 295048/
По ссылке 403. Не очень информативно такую ссылку постить.
Запись от Usaga размещена Сегодня в 06:46 . . .
|
|
сукцессия 33. открытые вопросы от клауде
anaschu 19.07.2026
"Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .
|
32 сукцессия
anaschu 19.07.2026
сукцессия 28‑мерное ядро стабилизировано
Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .
|
сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических
anaschu 18.07.2026
Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано
Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .
|
сукцессия 30. Массив проверяющих друг друга моделей
anaschu 18.07.2026
Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0)
Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона
Уважаемые коллеги!
В продолжение. . .
|