|
16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454
|
|
Недостатки ООП16.05.2014, 16:35. Показов 22224. Ответов 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, сейчас учу основы ООП, где можно найти задачи по ООП |
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
|||
| 01.09.2016, 04:43 | |||
|
Добавлено через 29 минут Кстати еще одним подтверждением есть постоянные вопросы об утечках памяти у пользователей языков с мусоросборниками (в мертвых слушателей течет) которая возникает при попытке пользования этих языков для задач более-менее серьезных чем формирование SQL-запроса или форматирование на его основе результатов веб-страницы, ну или банальных хеллоувердов с массивами. А вот вопросы по поводу утечки памяти в C++ днем с огнем искать надо.
0
|
|||
|
Заблокирован
|
|||
| 01.09.2016, 09:25 | |||
0
|
|||
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
|||
| 01.09.2016, 09:29 | |||
|
0
|
|||
|
Заблокирован
|
||
| 01.09.2016, 09:31 | ||
|
0
|
||
|
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
|
||
| 01.09.2016, 09:31 | ||
|
0
|
||
|
Заблокирован
|
|||||
| 01.09.2016, 09:47 | |||||
|
Добавлено через 7 минут
1
|
|||||
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||||||
| 01.09.2016, 10:30 | ||||||
|
А время там такое же реальное как я балерина. От того что оно не вовремя мусоросборник запустит ничего не случится. В отличии к примеру от промышленных роботов а тем более чего то связанного с транспортными или энергетическими системами, когда неспособность системы выдать управляющий сигнал в нужный лимит времени с требуемой точностью ведет к катастрофе. Добавлено через 26 минут
0
|
||||||
|
Заблокирован
|
|||||||||||||
| 01.09.2016, 10:59 | |||||||||||||
Добавлено через 5 минут
1
|
|||||||||||||
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
|||||||||||||||||
| 01.09.2016, 13:02 | |||||||||||||||||
|
Добавлено через 4 минуты Добавлено через 2 минуты Добавлено через 3 минуты Добавлено через 47 секунд Добавлено через 55 секунд Добавлено через 6 минут Добавлено через 7 минут Добавлено через 1 час 15 минут Добавлено через 4 минуты Добавлено через 1 минуту Добавлено через 7 минут
0
|
|||||||||||||||||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
|||||||
| 01.09.2016, 21:30 | |||||||
|
Джава создавалась как простой, объектно-ориентированный, надёжный, безопасный, независящий от архитектуры, переносимый язык. За основу взяли С++, но выкинули оттуда всё лишнее, упростили работу с памятью, добавили более строгий статический контроль типов, добавили возможность динамического контроля типов, убрали адресную арифметику.
То есть, по сути при создании Джава взяли С++ и убрали всё то, что мешает программировать. Но нельзя сказать, что цель была достигнута на 100%. Избавившись от очевидных недостатков С++, получили другие недостатки. C# создавался позже, поэтому его создатели пошли по пути Джава, но учли те проблемы, которые не смогли предвидеть создатели Джава. Если ты пишешь на С++, то ты должен обладать высокой квалификацией, чтобы "не выстрелить себе в ногу". Ситуацию усугубило то, что С++ стал культовым среди псевдохакеров. Причём, чем короче и запутанней был код, тем круче считалась программа. На Джава можно писать хорошие программы, если ты обладаешь высокой квалификацией, но при этом твои программы не будут такими ужасными, как программы на С++, если ты не обладаешь высокой квалификацией. Это позволяет эффективно разделять работу между высококвалифицированными и "начинающими или бестолковыми" программистами. На Джава есть обширная библиотека стандартных классов для типичных задач. На С++ в каждой конторе своя библиотека. Это сильно мешает, когда ты находишь новое место работы. К тому же, многие учебники для С++ переделывались из учебников для С. Поэтому часто программы на С++ представляют из себя смесь кода, написанного на С++ и С. А когда создавался стандарт С++, то каждый из участников считал своим долгом впихнуть в стандарт как можно больше возможностей. В результате язык получился перегруженным излишними возможностями. Добавлено через 1 минуту Добавлено через 1 минуту Добавлено через 8 минут Добавлено через 4 минуты Добавлено через 2 минуты Добавлено через 4 минуты Более того, выделение памяти - дорогая операция. Поэтому критические участки кода (по требованию к скорости работы) обычно пишутся так, чтобы не выделялась дополнительная память. И, как следствие, память не освобождается - сборщик мусора остаётся без работы.
0
|
|||||||
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||||||||||||||||||||
| 01.09.2016, 23:56 | ||||||||||||||||||||
|
Добавлено через 1 минуту Добавлено через 1 минуту Добавлено через 6 минут Добавлено через 4 минуты Добавлено через 23 минуты Что касается оффисных/информационных и т.п. систем то задача абсолютно другая. Т.е. распределение ресурсов и процессорного времени по принципу чтобы хватило как можно большему количеству клиентов. т.е. фактически разделение ресурсов по времени а не по назначению. При этом обычно с полной изоляцией данных одного клиента от данных другого. Посему без интенсивной аллокации/деаллокации памяти информационным системам жить нельзя. При этом на простейших задачах форматирования ввода-вывода/проверки корректности входных данных с этим справляется автоматика. Соответственно - не надо пытаться играть в кошки-мышки с автоматом сборки мусора там где он вообще не нужен и не надо пытаться прыгнуть выше его назачения/возможностей там где он используется. Добавлено через 18 минут Добавлено через 2 минуты Добавлено через 5 минут Добавлено через 6 минут Добавлено через 3 минуты Добавлено через 7 минут Добавлено через 9 минут Добавлено через 3 минуты Добавлено через 1 минуту Добавлено через 5 минут Добавлено через 12 минут
0
|
||||||||||||||||||||
|
Заблокирован
|
||
| 02.09.2016, 00:01 | ||
|
0
|
||
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||||
| 02.09.2016, 00:18 | ||||
|
Добавлено через 8 минут
0
|
||||
|
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
|
||
| 02.09.2016, 02:11 | ||
|
Кодер - это административная должность в больницах такая. Программистов за рубежом называют программистами
0
|
||
|
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
|
||
| 02.09.2016, 02:57 | ||
|
Как
0
|
||
|
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
|
|
| 02.09.2016, 04:34 | |
|
0
|
|
| 02.09.2016, 08:37 | ||
|
С др стороны потребность в максимально быстром коде (пусть даже ценой безопасности) всегда была и будет, а здесь другим языкам тягаться с "очевидными недостатками" C/C++ трудновато. Одна адресная арифметика чего стоит ![]() Что на мой взгляд в плюсах "не фонтан" - поясню на примере. Вот пару дней назад потребовался ассоциативный контейнер (ключ-значение) который умеет хранить значения разных типов. Да, есть множество способов это сделать: QVariant, boost::any, boost::variant, свой велосипед, с темплейтами или без, и еще бог весть что. Но все они "под капотом" имеют довольно большой (и часто трудный) код. Сделать это легко и просто средствами языка невозможно. А всякие "парадигмы ООП" мало помогают. Это надо заводить базовый полиморфный класс, от него всех наследовать, приложенные усилия явно не соответствуют копеечной цели - всего-навсего хранить в мапе. Конечно пришивать к переменной тип никто не будет, это уже не C/C++. Но подобные вещи часто возникают там и сям порождая очень "заумный" код.
0
|
||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
||||
| 02.09.2016, 09:39 | ||||
|
Или ключевое слово mutable, единственное назначение которого, чтобы я, видя const метод, понимал, что на самом деле он может вести себя не как const. Зачем нужен оператор ->, хотя из контекста всегда понятно, слева у нас ссылка или объект... при том что некоторые другие ключевые слова могут иметь по несколько различных смыслов в зависимости от контекста. Кривые правила перегрузки функций, приводящие к неприятным эффектам. Добавлено через 11 минут Добавлено через 5 минут
0
|
||||
|
Заблокирован
|
|||
| 02.09.2016, 09:41 | |||
|
По твоей логике программист еще должен быть бухгалтером, художником, медиком, музыкантом и вообще специалистом по всем областям, где используется ПО. Это полный бред расцветший на постсоветском пространстве. Программисту настолько же необходимы занания физики, насколько и медицины. Зарплаты у всех программистов примерно на одном уровне на любом языке из рассмотренных в теме. И ни о какой разнице в 5 раз речи точно не идет. Ты за свои слова ответить не можешь.
0
|
|||
|
Модератор
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
|
||
| 02.09.2016, 09:42 | ||
|
0
|
||
| 02.09.2016, 09:42 | |
|
Недостатки React
Недостатки AnyLogic Какие недостатки недостатки системы Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических
anaschu 18.07.2026
Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано
Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .
|
сукцессия 30. Массив проверяющих друг друга моделей
anaschu 18.07.2026
Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0)
Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона
Уважаемые коллеги!
В продолжение. . .
|
Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины.
anaschu 18.07.2026
ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии
Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .
|
Текстовый слайдер с нумерацией страниц и кроссбраузерность.
russiannick 18.07.2026
Один мой друг написал текстовый слайдер с нумерацией страниц. Сегодня я расскажу как он умудрился подружить его с кроссбраузерностью.
Очевидно сложно угодить с шириной каждому браузеру. Один крадет. . .
|
|
Грибы - это мемы, дерево - это человек. Применение микоризной модели к теории меметики Докинза.
anaschu 18.07.2026
Меметический изоморфизм теории «всего»: Грибная сукцессия как модель эволюции идей Докинза
Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а универсальную. . .
|
Грибы - это корпорации, деревья - это государства. Механизм массонского захвата власти
anaschu 18.07.2026
Макроэкономический изоморфизм теории «всего»: Грибная сукцессия как модель транснационального капитализма
Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а. . .
|
Расчёт периметра прямоугольника по координатам вершин
Maks 18.07.2026
Решение задачи по прикладной информатике средствами 1С.
Задача:
Вычислить периметр прямоугольника, заданного координатами своих вершин на плоскости.
Решение:
Создан документ со следующими. . .
|
Подсчёт частоты трёхбуквенных слов в тексте
Maks 18.07.2026
Решение задачи по прикладной информатике средствами 1С.
Задача:
Выясните, сколько раз в предложенном тексте встречается каждое трехбуквенное слово.
Решение:
Создан документ с единственным. . .
|