|
16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454
|
|
Недостатки ООП16.05.2014, 16:35. Показов 21776. Ответов 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
|
|
|
Модератор
3138 / 2286 / 469
Регистрация: 26.03.2015
Сообщений: 8,894
|
||
| 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
|
|
|
Модератор
3138 / 2286 / 469
Регистрация: 26.03.2015
Сообщений: 8,894
|
||
| 04.11.2016, 20:44 | ||
|
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,781
|
|||
| 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,781
|
||
| 04.11.2016, 21:39 | ||
|
0
|
||
|
Заблокирован
|
||
| 04.11.2016, 21:59 | ||
|
Поэтому я и попросил, чтобы 0x10, не копипасту давал, а то, как он сам это понимает. На пальцах.
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,781
|
|
| 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
|
||
|
Модератор
3138 / 2286 / 469
Регистрация: 26.03.2015
Сообщений: 8,894
|
|
| 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
|
|||
|
Модератор
3138 / 2286 / 469
Регистрация: 26.03.2015
Сообщений: 8,894
|
||
| 05.11.2016, 23:57 | ||
|
Если у Вас "Короче, получается, что ВСЕ СВЯЗАНО СО ВСЕМ.", то это недостатки дизайна, а не недостатки ООП.
0
|
||
| 05.11.2016, 23:57 | |
|
Недостатки React
Недостатки AnyLogic Какие недостатки недостатки системы Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
[golang] Pipeline
alhaos 08.06.2026
Pipeline
Pipeline — паттерн конкурентной обработки данных в Go.
Суть: данные проходят через цепочку независимых стадий, каждая из которых работает в своей горутине и общается с соседями через. . .
|
Свет внутри себя
kumehtar 07.06.2026
Пусть это будет здесь
lIs4oanZS9Y
|
Программа для com-порта
Uhbif79 05.06.2026
Всем привет, давно хотел изучить Qt, начинал, бросал, потом снова начинал. И сейчас вот смог написать свою первую программу.
До этого имел опыт программирования микроконтроллеров, писал прошивки на. . .
|
Транскрипция 55-минутного видео через Whisper: WhisperDesktop облажался, спас Google Colab[
anaschu 01.06.2026
Понадобилось получить текст из свежезагруженного видео на YouTube. Казалось бы, задача на пять минут. Заняла полтора часа. Делюсь опытом — может кому пригодится последовательность решений.
. . .
|
|
21 мат мед. Планы на развитие модели здравоСохранения
anaschu 01.06.2026
AnyLogic: план развития симуляционной модели рабочего коллектива — динамический абсентеизм, реальные данные, три сценария сравнения
Продолжаю серию постов о дискретно-событийной модели рабочего. . .
|
20. Мат мед. Абсентеизм как отдельный тип простоя
anaschu 29.05.2026
Апдейт модели: исправленные баги, абсентеизм и новые механизмы
Продолжаю развивать ранее описанную модель рабочего коллектива на AnyLogic. За последние несколько дней был проведён серьёзный. . .
|
19. здоровье, усталость и психотип работника влияют на производительность предприятия, и наоборот, производительность на здоровье, усталось и психотип
anaschu 28.05.2026
Дискретно-событийная модель рабочего коллектива на AnyLogic: здоровье, выгорание, психотипы и микростимуляция
Привет, коллеги. Хочу поделиться итогами нескольких недель работы над симуляционной. . .
|
"Прокси" для последовательного порта
Eddy_Em 28.05.2026
Эту штуку написал я достаточно давно. Но сейчас вот понадобилось настроить датчик грозы, но при этом не отключать его от "метеодемона". Соответственно, надо запустить этот "прокси": метеодемон будет. . .
|