Почему вы против ООП ? (Обращаюсь к тем кто действительно против)

День добрый.

На wasm.ru не мало противников ООП Я бы хотел, чтобы программисты-противники ООПа сформулировали свои мысли и выложили их здесь. Если это конечно не сложно.

Просьба:
Не нужно устраивать очередную святую войну, нужно только сформулировать и написать. Подумал и написал.

ЗЫ:
Очень нада

 

Не могу сказать, что я категорически против ООП как такового, но однозначно против той жуткой "матрёшечной" реализации (с не найдёшь концов уровнями вложенности), в которую он в 99% случаев выливается на практике. И ещё категорически против той зауми которую разводят вокруг ООП подавляющее большинство посвящённых ему книг

А из объективных недостатков ООП я бы назвал затруднительность удаления части кода из готового объекта. Если в чужом объекте что-то недоделано (забыли пуговицу пришить , то добать это легко. А вот если сделано что-то лишнее (нужна такая же сорочка но с перламутровыми пуговицами), то отпороть "не правильные" и пришить нужные пуговицы в подавляющем большинстве случаев не удастся - остаётся только искать/реализовывать новый объект или пришивать заплатку, закрывающую не подходящие пуговицы, а поверх заплатки пришивать уже свои - перламутровые. В комплекте с вышеупомянутой "матрёшечностью" получается нечто жутковатое

В общем ООП это хорошо, но требует очень аккуратного обращения как со стороны создателей объектов, так и со стороны их пользователей-совершенствователей

 

Y_Mur Спасибо, что не начал святую войну, а выполнил мою просьбу и написал конкретизированные мысли.
Ustus Спасибо, за то что в 2007-Авг-6 23:01:50 ответил выполяя мою просьбу.

временно:
Ustus Сегодня 23:17:37 прошу убрать за это время сообщение. Если есть вопросы почему, пиши пожалуйста в приват. Всего доброго

 

EvilsInterrupt
Меня вообще можно скорее отнести к сторонникам ООП, чем к противникам, но несколько проектов я делал принципиально без ООП, хотя и на С++. Получается примерно С, плюс всякие удобные фиговины. В моем случае это было обусловлено проектами, которые носили скорее характер утилит, чем полноценных приложений. Их не планировалось развивать, от них требовалась высокая производительность и что самое главное - их требовалось накарябать Очень Быстро, В Идеале - Вчера. Можно было, конечно, написать то же самое с использованием ООП, но ИМХО это было бы неоправданое усложнение проекта, так как плюсы ООП - как то локализация данных, легкость повторного использования, гибкость интерфейсной части - в данном конкретном случае не перекрыли бы основного минуса ООП - некоторой громоздскости, поскольку просто-напросто были бы невостребованы.

 

Y_Mur

Да, такое есть, к сожалению. И именно С++ -реализация ООП слишком далека от идеала, чтобы отсекать такие вольности на уровне языка. Но кто соблюдет сие - будет вознагражден стократно, особенно в проектах монструозных масштабов.

 

ООП нужен так где он нужен.

Конкретно :

Крупные проекты которые пишет несколько программистов не один год.
Как правило это бизнес приложения уровня предприятия.

Если чел пишет:

1) Небольшие и быстрые утилиты
2) Вирусы
3) Руткиты
4) Драйвера
5) Полиморфные движки
6) Эксплоиты и т.д.

ООП ему совершенно не нужен.

 

http://kalinin.ru/dcforum//DCForumID1/134.html

вот интересная штука

 

Proteus Читать умеем нет? Я же на русском и вежливо попросил, только и и только по делу!

 

EvilsInterrupt

Причина довольно неочевидна, но вот пример. Мой друг уже 3 года работает на предприятии, где в основном программирование ведется на делфи, и крайне широко используется ООП для доступа к базам данных. Так вот, после выхода в отпуск человека, который все это настраивал, и сопровождал вдруг перед его заместителем была поставлена задача - разобрать и сархивировать файлы баз данных + записать все вместе с программой просмотра на флешку, а последняя - это был подарок директору фирмы, корпус типа из золота и т.д., но самое важное 128 метров. Так вот люди работающие в фирме и использующие давным-давно написанные для ООП классы, так и не смогли этого сделать в приемлемые сроки - настолько "отупляет" ООП. На все уговоры использовать в качестве носителя хотя бы ноутбук, директор сказал, а вот с такой-то фирмы (фирма крупнее) мне все данные сбросили на флешку и все ок, а вы оста..пы не можете...

 

Не вижу связи между ООП и золотой флешкой

Некорректное сравнение .... Да и глупое моршить попу что бы показать что ме не хуже. Ярмарка тчеславия ...

Помню мне руководство тож давало задание сделать офлайновую версию на флешке - динамического сайта (MS SQL + ASP)


Я им пояснил что это невозможно ...

 

Я задал эту тему не с целью развести очередной базар по поводу хорошо это или плохо. Вы че читать разучились? Я же просил высказаться тех и только тех, кто против ООП. Все же просто, если ты против ООП, значит подумай и сфулировав свои мысли напиши их. Че сложного?

Еще раз Для Особобо одарееннных: Я прошу всего лишь высказаться тех, кому ненравится ООП и почему? А не плюсы или минусы! Или хорошо это или плохо! Давайте же уважать друг друга и говорить по темам?!

 

Си простой, понятный, близкий к железу. Нет никакой непонятной примитивному разуму системного программиста заумности - шаблонов, динамик-кастов, виртуальных функций и прочего. Все это замечательно можно реализовать более простыми, "сишными" средствами. Кроме того, я решительно против возможности объявлять переменные в любом месте кода - потом концов найти невозможно. Да и иерархии классов в большинстве своем, исключая только, пожалуй, VCL, оставляют весьма грустное впечатление.

 

Недостатки ООП:
1 - Низкая производительность кода.
2 - Большой размер кода.
3 - Крайнее ухуджение читабельности и модифицируемости кода содержащего чужие классы.
4 - Крайне высока опасность наткнуться на чужие баги, которые пофиксить самому будет трудно, и потенциальная нестабильность программы связаная с отсутствием у программиста полного понимания работы всего кода в целом, что нередко приводит к глюкам с совершенно неясной причиной.
5 - Зависимость кода от конкретного компилятора под который он пишеться (совместимость с++ кода куда хуже, чем у чистого ansi c)
6 - Зависимость кода от c++ RTL библиотек.
7 - Неэффективное использование памяти (фрагментация кучи) при частом создании/удалении обьектов.
8 - Плохая совместимость бинарных библиотек между разными компиляторами.

Достоинства ООП:
1 - Возможность использования огромных библиотек классов на все случаи жизни. (достоинство спорное, т.к. существует немало чисто процедурных библиотек).
2 - Большая скорость разработки (спорный факт).
3 - Наконец, это просто модно.

Вывод:
Область применения ООП - это некачественные программы делаемые на скорую руку, GUI интерфейсы и прочее, к чему предьявляются только требования по скорости разработки, но не по качеству результата.
ООП категорически противопоказано в: драйверах, системных библиотеках, маленьких утилитах, программах требующих высокой производительности работы, программах для особо надежных систем.


З.Ы. я высказал свое мнение, и те кто захотят его обосрать могут сразу отправляться по ссылке на три буквы, в дискуссии по этому поводу я вступать не буду.

 

категорически против ООП все кому приходилось дебажить его без сорсов
палец болит ;(

 

1. Покажите мне ассемблер, поддерживающий ООП
2. Инкапсуляция? Кому надо, тот всё равно залезет. Россия, всё-таки...
3. Наследование? А зачем? Взять полный набор функций по всей иерархии и исползовать только те, что нужно.
4. Интерфейсы? С их задачей прекрасно справляются комментарии.
5. Шаблоны? Появившиеся из-за строгой типизации и жутко раздувающие код?
6. Что такое реализуемо с помощью ООП, чего нельзя сделать без него? Ничего. Машкод-то тот же.
- мхо

 

немножко нефтему;

жаль, что нельзя было тест опросник сюда повесить. было бы интересно посмотреть на итоговое процентное соотношение тех, кто против к тем, кто за.

 

Ассемблер поддерживающий ООП - TASM. Читайте документацию :Р

 

JAPH wrote:

TASM

1. ИМХО самый большой недостаток, это то, что начинающие кодеры, еще не усвоив добром концепции ООП, начинают такой лес городить, что тошно становится. И со временем настолько привыкают к этому, что по другому просто не могут. К тому же применяют его абсолютно везде, даже там где оно как пятое колесо в телеге Просто сама концепция ООП поощряет добавление в объекты избыточного функционала, на все случаи жизни. И это не случайность, т.к. очень сложно что то добавлять/изменять в готовых сорсах. А если это чужие, то лучше сразу повеситься(кто нибудь пробовал вырезать из Turbo Vision лишнее?). Вот и плодят классы для простого 2+2, забывая про простую истину - в проге не должно быть ничего лишнего, так съэкономишь уйму времени, в том числе и при отладке.
2. При создании больших проектов просто необходимо специализированное IDE, иначе запутаешься в своих же классах и их методах и свойствах
3. Очень сложно правильно разбить проект на объекты. Одна ошибка приводит к переделке огромных объемов кода, или созданию "заплат", friends, etc.
4. Девиз ООП - "у каждого объекта свои данные". Логично, но на практике гораздо эффективнее использовать глобальные и локальные переменные, нежели выделять под них память в объектах. Да и отказ от глобальных переменных приводит к появлению дополнительного кода, надо же объектам как то взаимодействовать.
5. Отвратительная читаемость сорсов. Когда я вижу strcmp(s1, s2) я понимаю что это сравнение строк. А вот строка a.cmp(b.get) станет понятной только тогда, когда на зубок запомнишь все объекты. А если сорсы мегабайтные? Теряешь море времени.

Если брать на конкретных примерах, то самую неудачную реализацию видно каждый день - VCL. Хорошим примером отказа от ООП является библиотека jpeglib, в которой все построено на структурах (для совместимости?).

 

Не надо смешивать парадигму программирования и конкретные примеры использования. ООП также поощаряет добавление избыточного функционала, как и все другие. Любая процедурная библиотека может быть переполнена избыточныи функционалом.

С таким же успехом можно запутаться в проекте с процедурныи стилем.

Это слдествие неправильного применения ООП. Не надо делать "тяжеловесные" объекты. Объект должен выполнять одну задачу.

На практике гораздо менее эффективно использовать глобалные данные. При увеличении числа глобальных объектов до 100 штук и больше программу становится невозможно сопровождать. Попробуйте свою такую программу разобрать через год после написания.

пять пример неправильного применения ООП. При правильно подходе можно было бы написать a == b приче быть точно уверенным, что сравнивается строка со строкой, независимо от внутреннего пердставления обоих строк.

MFC еще хуже VCL.


Лично я против ООП в следющих случаях:
1)При написании небольших программ до 5000 строк (примерно). В таких случаях ООП только ухудшает читаемость, увеличивает объем кода и уменьшает скорость работы
2)При использовании классов, как оберток API функций (hWnd->GetWindowText(...) на мой взгляд хуже, чем GetWindowText(hWnd,...) )
3)Использование ООП в критичных по времени участках кода
4)Когда ООП использует человек, не умеющий этого делать.

В остальных случаях ООП полезно, на мой взгляд.

 

Легко. Добавить гораздо сложнее. Впрочем, клонов и переделок TV хватает - та же IDA.