|
16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454
|
|
Недостатки ООП16.05.2014, 16:35. Показов 22281. Ответов 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, сейчас учу основы ООП, где можно найти задачи по ООП |
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
||||
| 03.09.2016, 21:10 | ||||
|
0
|
||||
|
Заблокирован
|
||
| 03.09.2016, 22:28 | ||
|
Это и называется "сложность"
0
|
||
|
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||||
| 04.09.2016, 03:13 | ||||
|
Добавлено через 10 минут Добавлено через 1 минуту Но для этого нужна абстрактная модель того что делаешь. Это и называется сложность. Но ее на любом языке никто не отменит Добавлено через 1 час 56 минут
0
|
||||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
|||
| 04.09.2016, 03:29 | |||
|
0
|
|||
|
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
|||
| 04.09.2016, 05:57 | |||
|
Добавлено через 3 минуты
0
|
|||
| 04.09.2016, 09:04 | |||
|
Однако результат оказывается далеко не таким уж хорошим. Да, сэкономлено немало времени на рутинную работу, но с др стороны человек не понимает многих вещей, ведь он просто "прочитал и запомнил", и все. Нет того понимания которое дает "изобретение своего велосипеда". Нет аккуратности которая приобретается при работе с примитивным char *. Не получал по ушам с "коровой" (std::string). Ну и, может, самое главное - "подрезаны крылья". Ничего придумывать сам он уже не хочет, все его усилия направлены на поиск "готовых решений/классов".
0
|
|||
|
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
|
||
| 04.09.2016, 12:34 | ||
|
1
|
||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
|||
| 04.09.2016, 13:13 | |||
|
0
|
|||
|
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||||
| 04.09.2016, 13:27 | ||||
|
Добавлено через 1 минуту Добавлено через 4 минуты Так что если не хочешь вязаться на какой то определенный оконный фреймверк а строки нужны с нормальными возможностями то свои строки будут полюбому.
0
|
||||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
||||
| 04.09.2016, 13:37 | ||||
|
С другой стороны, программа, написанная на "хорошем" языке, может работать медленнее, чем программа, написанная на "плохом". Но это уже недостатки компилятора. В зависимости от решаемой задачи эти недостатки могут быть более или менее критичными. По мере развития софта (компиляторы) и железа (мощность компьютеров) влияние этих недостатков постоянно уменьшается. Но всё равно при выборе языка для работы приходится учитывать текущий уровень развития софта/железа. Добавлено через 4 минуты
0
|
||||
|
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||
| 04.09.2016, 13:37 | ||
|
0
|
||
|
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
|
||
| 04.09.2016, 13:48 | ||
|
0
|
||
| 04.09.2016, 13:49 | |||
На плюсах, как и в любом языке, ее никогда не было. Другое дело бывает нелегко выбрать подходящее. Подключение Qt выльется в заботы с либами, std::string не так уж удобен как хотелось бы и.т.п. Бывает посмотрел - та, тут и char * можно обойтись, а потом задача разрослась и этот выбор оказался неоправданным. Но это никак не "недостаток языка"
0
|
|||
|
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
|||
| 04.09.2016, 14:00 | |||
|
Добавлено через 4 минуты Добавлено через 1 минуту Реально что не укладывается в одном типе строк - это к примеру обязаловка на 0-терминатор и возможность делать подстроки указателем на исходную строку. Добавлено через 1 минуту Ну и разный тип символа тоже обычно к разным инстансам одного шаблона строки приводит.
0
|
|||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
|||
| 04.09.2016, 14:04 | |||
|
0
|
|||
|
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
|
|
| 04.09.2016, 14:05 | |
|
0
|
|
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
|||
| 04.09.2016, 14:07 | |||
|
Добавлено через 1 минуту
0
|
|||
|
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
|||
| 04.09.2016, 14:09 | |||
|
0
|
|||
| 04.09.2016, 14:12 | ||
|
Есть 2 полупрозрачных цветных стекла: переднее и заднее (front & back). Это 2 структуры данных ARGB, каких конкретно - на Ваше усмотрение, можно использовать любые готовые классы. Нужно посчитать итоговый цвет как это делает фотошоп и др приложения. Формально: вычитающая прозрачность, цветовая модель (A)RGB. Вот я не уверен что есть язык на котором этой крохотной задачке будет посвящено столько строк сколько она заслуживает. Вот со своими великами да, а так... ну не знаю, не знаю
0
|
||
|
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||
| 04.09.2016, 14:17 | ||
|
0
|
||
| 04.09.2016, 14:17 | |
|
Недостатки React
Недостатки AnyLogic Какие недостатки недостатки системы Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Был праздник вчера, а я и не знал.
kumehtar 28.07.2026
27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет
Новости компьютерного мира и их обсуждение (4)
Салют, шампанское, овации!
:drink:
|
Нейтральные знания, чистый код - бла-бла-бла-бла, на самом деле кликбейт и самореклама, плагиат, и вот почему
Hrethgir 27.07.2026
То-есть отклонение такой публикации говорит само за себя, и пусть только возьмут на вооружение после отклонения публикации - это будет чистейшим актом плагиата. Отклонял Хабр.
Дословно, отклонённая. . .
|
тв 16 бой ии
anaschu 27.07.2026
Великий Перелом ИИ: Как уравнения ОДУ Radau дожали цензурные фильтры Алисы
Фиксируем в мемофонде Теории Всего беспрецедентный факт в истории ИИ-зондирования. В затяжном многораундовом. . .
|
мв 15. непроверенное, возможно, глюк
anaschu 27.07.2026
НАУЧНО-АНАЛИТИЧЕСКИЙ ОТЧЕТ. РАЗДЕЛ 1. 1: «НАУКА» (РАСШИРЕННАЯ СТЕХИОМЕТРИЧЕСКАЯ И ГЕНЕТИЧЕСКАЯ ВЕРСИЯ)Тема: Теоретическое обоснование инвариантности 19-мерного тензорного ядра непрерывных ОДУ и. . .
|
|
Очистка реквизитов и табличных частей документа при копировании (вариант 2)
Maks 26.07.2026
Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРаботу", разработанного в КА2.
Задача: Заменить алгоритм запрета копирования документов для сотрудников с ролью "Стажер",. . .
|
Доктрина интенционального знания - Доктрина для портала "Срез".
Hrethgir 25.07.2026
Может найдётся кто захочет оценить доктрину. . . Написания правил участия для меня роскошь, требующая лимита времени, поэтому все сообщения не прошедшие модерацию будут видны только участникам портала,. . .
|
сукцессия 44. Решил подать на припринт в межународные сервисы препринтов. Но нужно одобрение от ученых
anaschu 25.07.2026
Английский вариант. Пока кто то не одобрит мою личность, мне не получиться это опубликовать на препринте. Но заявку на публикацию статьи я сегодня подам.
|
сукцессия 43. Вторая научная статья за месяц- прайминг и гатгил
anaschu 25.07.2026
две стороны одной монеты
|