Недостатки ООП

Недостатки ООП
Парадима ООП не нова. ООП приобрело популярность во второй половине 80-х вместе с такими языками, как Smalltalk, С++, Objective C (другое расширение C) и некоторыми другими. 25 лет назад никто не ожидал, что “новый” феномен ООП проживет столь долго и сегодня большинство современных языков поддерживают эту парадигму.
ООП стоит на трёх китах:
1.Первый — инкапсуляция — это определение классов — пользовательских типов данных, объединяющих своё содержимое в единый тип и реализующих некоторые операции или методы над ним. Классы обычно являются основой модульности, инкапсуляции и абстракции данных в языках ООП.
2.Второй — наследование — способ определения нового типа, когда новый тип наследует элементы (свойства и методы) существующего, модифицируя или расширяя их. Это способствует выражению специализации и генерализации.
3.Третий, известный как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программ, основанных на них.
Инкапсуляция, наследование и полиморфизм — фундаментальные свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах). Различные ОО языки используют совершенно разные подходы. Мы можем различать ОО языки, сравнивая механизм контроля типов, способность поддерживать различные программные модели и то, какие объектные модели они поддерживают.
Преимущества этих языков всем известны: повторное использование кода, упрощение разработки больших программ, более логичная структура программы и многие другие. Разберём некоторые недостатки.
Недостатки есть абсолютно у всего – с этим нужно просто смириться. Важно адекватно их оценивать и стараться минимизировать их влияние. То же самое касается и объектно-ориентированной парадигмы программирования.
Есть несколько причин, почему узкие места ООП часто вылазят наружу. Я считаю, что это прежде всего непонимание самой сути объектно-ориентированной техники программирования - восприятие этой парадигмы как серебряной пули. Часто программисты стараются решать абсолютно все задачи, где даже не предвидится конкретных сущностей с их свойствами с помощью объектов, наследования и с помощью объектов. Это очень усложняет процесс. То есть вместо написания парочки функций в процедурной манере и передачи аргументов туда-обратно, программист часто пытается нагромоздить целую иерархию классов и после разгребает проблемы с видимостью классов, доступа к скрытым инкапсуляцией данным.
Таким образом, можно выделить один недостаток объектно-ориентированных языков программирования – избыточность их средств при решении большинства простых задач.
Нужно помнить, что применение ООП это прежде всего моделирование. Для построения хорошей, легко читаемой и сопровождаемой программы необходимо в самом начале разработки предусмотреть сценарии её использования и, что очень важно, изменения – заказчик легко в корне может поменять задачу. Это нетривиальный процесс, в котором часто задействуются даже отдельные языки моделирования. Не каждый способен выделить отдельные сущности и сделать их классами. Ещё меньше людей способны адекватно распределить функции, работающие с данными программы в методы и упаковать их в классы. Для этого нужно уметь мыслить объектно-ориентированными категориями. На всё это уходит драгоценное время. Оно обязательно окупится, если программист имеет дело с большим и сложным проектом, но вряд ли в других случаях, когда требуется просто решить задачу и перейти к другой.
Для меня вывод один, всем известный и общепринятый – не стоит воспринимать парадигмы и языки, их поддерживающие, как божество. Это всего лишь инструмент для решения определенного круга задач. Я думаю, что для объектно-ориентированных языков такие задачи начинаются, когда их решение укладывается более чем в тысячу строк и задачи, которые требуют масштабирования.
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп

HACKNET REVIEW 01/98
Интервью Bjarne Stroustrup, данное 1 января 1998 года
для журнала Computer.
© 1998, Computer
перевод: Mike Bluesman

Первого Января 1998 года Bjarne Stroustrup давал интервью журналу 'Computer'. Вообще-то редакторы предполагали, что он расскажет о семи годах объектно-ориентированного программирования с применением языка, который он и разработал.
К окончанию беседы выяснилось, что интервьюер извлек больше информации, чем предполагал, и, естественно, редакторы решили урезать содержание 'для пользы индустрии', но, как обычно получается в таких случаях, произошла утечка информации.
Вот полный и нередактированный протокол интервью - это не похоже на обычные запланированные вопросы/ответы.
Вам наверняка покажется это интересным.

Интервьюер - далее И., Stroustrup - далее C..

И. Прошло несколько лет с тех пор, как Вы изменили мир разработки программного обеспечения. Что Вы теперь чувствуете, оглядываясь назад?

C. Вообще-то я думал об этих днях как раз перед тем как Вы приехали. Помните - все писали свои версии 'C', и проблема была в том, что все это делали чертовски замечательно. Университеты тоже чертовски замечательно преподавали этот язык. Это привело к понижению компетенции. Под 'компетенцией' в данном случае я подразумеваю феноменальность. Вот что породило проблему.

И. Проблему?

C. Да, проблему. Помните когда все писали на Cobol?

И. Конечно, я тоже это делал.

C. Ну вот, в начале эти ребята были как боги. Им платили кучу денег и относились как к королям.

И. Да уж, вот это были времена...

С. Именно. Ну и что же случилось? IBM прямо заболела этим и вложила миллионы в подготовку программистов, пока их не стало до ужаса много.

И. Вот так и я вылетел из этой сферы. Втечение года зарплата упала настолько, что даже журналистом можно было зарабатывать больше...

С. Точно. То же самое случилось и с программистами, писавшими на 'C'.

И. Понятно, ну и что же Вы все-таки хотите этим всем сказать?

C. Однажды я сидел у себя в оффисе, и мне пришла в голову небольшая идейка, как хоть немного восстановить баланс. Я подумал: интересно, что произойдет, если будет язык программирования такой запутанный и такой сложный для изучения, что никто бы уже не сможет заполнить рынок толпой программистов, пишуших на этом нем? У меня уже были тогда кое-какие мысли по этому поводу. Вот, знаете наверно, X10 и X windows. Это тогда была такая графическая система, которая работала на Sun 3/60. У нее были все ингредиенты, которые мне были нужны - комплексный синтаксис, сложные для понимания мрачные функции, псевдо объектно-ориентированная структура. Даже сейчас никто не пишет напрямую под X-windows. Motif - единственный путь, если вы хотите сохранить рассудок.

И. Шутите?

C. Ничуть. Есть еще одна проблема. Unix был написан на 'C' - это значило то, что любой программист, пишущий на 'C', мог очень легко стать системным программистом. Помните сколько обычно зарабатывали большинство системных программистов?

И. Да, я же ведь тоже этим занимался.

С. Так вот, этот новый язык должен был отделять себя от Unix путем скрывания всех системных вызовов, которые так здорово связывают 'C' и Unix. Тогда ребята, знающие только DOS, тоже смогли бы прилично зарабатывать.

И. Не верится в то, что Вы это сказали...

С. Это уже происходит достаточно долго, но вроде сейчас большинство людей уже уяснили для себя, что C++ - это пустая трата времени, но должен сказать, что осознание этого происходило дольше чем я ожидал.

И. Ну расскажите поточнее, как же Вы все-таки сделали это?

C. Это была просто шутка, я никогда не думал, что люди воспримут эту книгу всерьез. Любой человек, даже с половиной мозга, может понять что объектно-ориентированное программирование интуитивно, нелогично и неэффективно.

И. Что?

С. И относительно 'повторно-используемого кода' - Вы когда-нибудь слышали, чтобы хоть одна компания 'повторно-использовала' что-либо?

И. Ну, вообще-то не слышал, но...

С. Вот так-то. Некоторые, кстати, пытались. Была такая компания из Орегона - Mentor Graphics, в которой просто заболели тем, что пытались переписать все что можно на C++ в '90 или '91 году. Я на самом деле им сочувствовал, но думаю, что люди по крайней мере, научились чему-то на их ошибках.

И. Очевидно у них ничего не вышло?

С. Вообще ничего. Но было бы сложно объяснить держателям акций компании ущерб в 30 миллионов долларов и вот, надо отдать им должное , они все-таки заставили это работать в итоге.

И. Так все-таки у них получилось? Это доказывает что 'объектное-ориентирование' работает.

C. Почти. Запускаемый файл получился такой огромный, что загружался 5 минут на рабочей станции HP со 128Mb оперативной памяти. Я думал, что это станет камнем преткновения, но это никого особенно не заботило. Sun и HP были очень рады продавать до ненормальности мощные ящики с огромными ресурсами для выполнения на них тривиальных программ. Знаете, когда мы в AT&T откомпилировали нашим первым компилятором C++ программку 'Hello World', я не мог поверить своим глазам: запускаемый файл получился размером 2.1Mb.

И. Да уж... Но компиляторы с тех пор прошли долгий путь.

C. Вы так думаете? Попробуйте тот же пример 'Hello World' с последней версией g++ - вы получите примерно пол-мегабайта. А кроме этого есть еще множество примеров со всего мира. У British Telecom чуть было не возникли большие проблемы, но к своему счастью они вовремя догадались свернуть проект и начать все заново. И им больше повезло, чем Australian Telecom. А теперь я слышал, что Siemens cоздает какого-то динозавра и все больше и больше волнуется по поводу размера того, что у них получается. Не правда ли забавно смотреть на это всеобщее заблуждение?

И. Да, но C++ -то, в общем, вполне нормальный язык.

С. Вы в это так верите? Попробовали ли вы когда-нибудь сесть и поработать над проектом на C++ ? Во первых, я расставил достаточно ловушек, чтобы просто так работали только тривиальные проекты. Под конец проекта получается что одни и те же операторы в разных модулях означают совершенно разные вещи. А теперь попробуйте соединить все эти модули в единое целое, особенно если у вас их штук 100. Боже, я иногда не могу удержаться от смеха, когда слышу о проблемах разных компаний, которые не могут сделать так, чтобы их модули общались между собой.

И. Я должен сказать, что совершенно сбит с толку всем что Вы сказали. Вы сказали что сделали это для того, чтоб повысилась оплата труда программистов. Но это же бессмыслица.

С. Не совсем так. У каждого есть его выбор. Я не предполагал, что все это так выйдет из-под контроля. Но все-равно, практически все у меня получилось. C++ cейчас уже умирает, а труд програмистов продолжает нормально оплачиваться - особенно тех, кто имеет дело со всей этой чепухой - вы же понимаете, что невозможно использовать эффективно большой программный модуль на C++ , если не вы сами его написали.

И. Как это?

С. Не понятно что-ли? Помните typedef ?

И. Конечно.

С. А теперь вспомните сколько времени приходится копаться в заголовках для того, например, чтобы просто найти, что какое-нибудь там 'RoofRaised' - число с двойной точностью. Представьте теперь сколько времени уйдет на нахождение всех определений типов в большом проекте.

И. Значит, Вы утверждаете, что Вам все, что Вы хотели удалось...

C. Ну, вспомните сколько занимает реализация проекта среднего размера на 'C'. Это около 6 месяцев. Не достаточно долго чтобы парень с женой и детьми мог заработать себе на нормальное существование. Попробуйте тот же проект реализовать на C++ , и что получится? Вам понадобится 1-2 года. Не правда ли, это замечательно? Кроме этого: в университетах уже так давно не преподают 'C', что теперь стало мало людей программирующих на 'C', особенно таких, которые знают все о программировании под Unix. Как вы думаете : сколько парней смогут сообразить что делать с 'malloc' , после того как втечение многих лет они пользовались 'new' и никогда не заботились о проверке кода возврата? Большинство программистов на C++ вообще не выбрасывают этот код возврата. Что произошло со старой доброй '-1' ? По крайней мере было сразу понятно, что у тебя где-то ошибка без всяких там 'throw', 'try' и 'catch'...

И. И все же, наследование экономит кучу времени?

С. Нет, я же говорил... Замечали, в чем разница между стадиями планирования проектов на 'C' и C++ ? Для проекта на C++ эта стадия в три раза дольше. Время уходит на то, чтоб убедиться что все что надо наследуется, а все что не надо - нет. И все-равно без ошибок не обходится. Кто слышал когда-нибудь об утечке памяти в программе на 'C' ? Теперь нахождение этих утечек - целый труд. Большинство компаний сдаются, так и выпускают продукт, зная что утечка памяти существует.

И. Но есть различные программные инструменты...

С. Большинство из которых написаны на C++.

И. Если мы опубликуем все это, то Вас просто могут линчевать, понимаете ?

C. Сомневаюсь. Как я сказал C++ уже уходит в прошлое. Ни одна компания без предварительного тестирования теперь не начнет проект на C++, а если будет тестирование, то они поймут, что это путь к неудаче. Если не поймут - то так им и надо. Знаете, я пытался убедить Dennis'a Ritchie переписать Unix на C++.

И. О Боже. И что же он сказал?

C. К счастью у него присутствует хорошее чувство юмора. Я думаю и он, и Brian понимали что я тогда делал. Он ответил, что может мне помочь написать версию DOS на C++, если я захочу.

И. Ну и как? Вы захотели?

С. Я написал DOS на C++. Могу дать вам demo. Она у меня работает на Sparc 20 в другой комнате. Просто летает на четырех процессорах и занимает всего то 70 мегабайт на диске.

И. На что же это похоже на PC ?

С. Вы, очевидно, шутите. Видели же вы Windows'95 ? Я о них думаю как о своем величайшем успехе.

И. Знаете, эта идея насчет Unix++ заставила меня задуматься. Ведь где-то может сидеть парень, которому придет в голову сделать это...

С. Но не после того, как он прочитает это интервью.

И. Я сожалею, но врядли мы сможем опубликовать даже часть этого интервью.

С. Но это же история века. Я просто хотел чтоб мои приятели-программисты помнили меня за то, что я для них сделал. Знаете как сейчас оплачивается программирование на C++ ?

И. Последнее, что я слышал - настоящие профессионалы зарабатывают $70-80 в час.

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

И. Имеете ввиду, что раньше Вам C++ не нравился?

С. Ненавидел его. Он даже выглядит неуклюже, вы не согласны? Но когда стали там выходить разные книги... вот, тогда-то я и увидел полную картину.

И. Погодите, а как насчет ссылок? Вы подтверждаете что улучшили указатели 'C' ?

С. Хмм. Я и сам не знаю. Вообще я думал, что да. Потом я как-то говорил с парнем, который писал на C++ с самого начала. Он говорил, что не мог запомнить были ли ссылки на его переменные или нет, поэтому он всегда использовал указатели.

И. Обычно на этой стадии я говорю 'большое спасибо за интервью', но сейчас это как-то не к месту.

С. Пообещайте мне, что опубликуете это.

И. Я извещу Вас, но мне кажется, что я знаю, что скажет мой редактор по этому поводу.

С. А все-равно, кто этому поверит? Кстати, не могли бы вы мне прислать копию этой записи?

И. Это я могу.

Примечание переводчика :

Я не программирую на C++. Я не являюсь знатоком русской словестности. Посему прошу извинения за возможные ошибки в переводе.

специальный перевод для Hacknet Review выполнил Mike Bluesman, март 1998

©

Например, мне сложно понять (не запуская), что делает эта программа: