Теология ООП
В последние годы появились весьма неочевидные прогнозы, и даже чуть ли не констатация факта о провале объектной парадигмы, ООП. Крайнюю позицию высказал Ричард Гейбриэл в своем выступлении на OOPSLA. И в этом выступлении есть слишком много правды, а в ответах оппонентов слишком мало рационального, чтобы можно было не задумываясь пройти мимо этой дискуссии. дальше...
Комментарии:
Почему-то по моим наблюдениям программы и библиотеки на C++
содержат гораздо больше ошибок чем аналгичные написанные на C. Одна из причин (или следствий?) -
то что программы на С++ гораздо больше размером.
Посмотрите код Мозиллы. Там есть множество подпрограмм, состоящих из одной простой строчки.
Так почему эту строчку нельзя вставить непосредственно в то место где была вызвана эта функция?
Потому что нарушится закрытость "Чёрного Ящика" - ООП мешает писать нормальные читабельные программы.
Для того чтобы писать хорошие программы на С++ нужно отказаться от ключевых слов class, private, friend и protected и
от желания засунуть все действия в функции-члены каких-нибудь классов.
2 Сергей
Я бы не стал говорить так категорично. Нужно лишь избегать использования объектов там, где их на самом деле нет. А в целом ООП весьма неплохая парадигма, я бы даже сказал, самая практичная из придуманных на сегодняшний день. Другой дело, что она не идеальна и в будущем может быть заменена более совершенной (если её придумают, конечно).
Просто не стоит злоупотреблять ООП, всегда нужно подходить ко всему рационально, ведь большую часть времени программист тратит не на написания кода.
90% решения задачи содержит сама задача.
ООП помогает писать большие проекты, ведь всегда лучше описать GUI в отдельном классе, кнопки и т.п. также лучше описывать в отдельных классах, почему? Да потому что если заказчик попросит в последнюю минуту (как это часто бывает) изменить, например одну или две кнопочки, Вы спокойно можете это сделать без потерь времени.
Не стоит ругать ООП, это совершенно другой образ мышления и программистам на Си это не всегда сразу понятно.
Я пишу на Джаве уже достаточно долго, начинал с Си, затем был Си++.
В статье было сказано об не эффективности Джава, так попробуйте указать мне конкретные доводы неэффективности программирования на данном языке.
Необходимость скрытия кода в классах и библиотеках оправлывается комерческими интересами, а наиболее успешная реализация классов присходит в рамках программных платформ, когда программист в совершенстве владеет платформой, среда иразработки способствует быстрой разработке приложения,а среда исполнения - эффективной реализации. Широкое использование ООП в "обычном" варианте в большей степени несет за собой баласт излишней нереализованной функциональности классов и библиотек в виде объема программы и низкой производительности, хотя с развитием технической базы, ростом производительности процессоров и емкости устройств памяти это становится не критичным. Критичным это станет при необходимости оптимизации энергосбережения (космос, например)или скорости обработки (военная техника).
Я постоянно наблюдаю людей, которые, не осилив объеткно-ориентированную парадигму, занимают позицию стойких ее противников. И почти каждый раз я убеждался, что причиной их разочарования в ООП является отсутсвие у них ЗНАНИЙ о ООП, и нежелания получать эти знания.
Я отнюдь не хочу сказать, что ООП является той самой серебряной пулей, что спасет мир. Но я многократно, в самых различных ситуациях убеждался в необходимости применения ООП в каждой, конкретной задаче.
По вашим словам выходит, что несколько миллионов программистов, которые с успехом применяют этот подход, заблуждаются? Что корпорации, чья прибыль напрямую зависит от качества производимого ими ПО, поросту не знают, что делают? Вы что, в конце концов, самый умный? В таком случае приводите реальные, экспериментальные подтверждения вашим словам. Это было бы куда эффективнее, чем рассуждать о сферических конях в вакууме. Что-то я не припомню сколь-либо значительных продуктов, написанных на чисто функциональных языках - примитивную поделку Пола Грехема на Лиспе в виде коструктора сайтов просьба не упоминать.
Руслан,
Сказать что я не осилил ООП будет несправедливо, потому что я применял эту методологию в течение наверное 15 лет, причем на самых разных языках со всеми вариациями объектных моделей.
Какие-то примеры из реальной жизни я уже привел в обеих статьях, и могу привести еще если потребуется. И замечу, я не за отмену ООП вообще, а скорее за то, чтобы программисты были в курсе, что эта методология не является единственной. "Всё есть объекты" - утверждение не только неверное, но и опасное, поскольку легко порождает много лишнего кода, которого могло не быть, если бы программисты умели комбинировать разные методологии - вот о чем эти две статьи. Я скорее против чисто-объектных языков вроде Джавы, которые навязывают определенный стиль мышления и сильно ограничивают выбор и поле для творчества.
Корпорации "чья прибыль напрямую зависит от качества производимого ими ПО" могут заблуждаться. Когда-то на исследование нейронных сетей, к примеру, были брошены миллиарды корпоративных денег, и как теперь оказалось - зря. Корпорации не то чтобы заблуждаются взяв за основу ООП - нет, но они могут не осознавать, что производят слишком много кода и таким образом работают неэффективно.
С другой стороны, чисто функциональные языки - такя же крайность, как и чисто ОО-языки. Ясно одно: некоторые парадигмы ФП чрезвычайно мощны, и не даром уже постепенно перекочевывают в обычные языки программирования. Python, Ruby и даже JavaScript уже имеют "безымянные функции", когда как в Java их нет (а в С++ принципиально и не могут быть).
>. Но я многократно, в самых различных ситуациях >убеждался в необходимости применения ООП в каждой, >конкретной задаче.
KDE написано на с++,
Gnom на c-- :).
никакой существенной разницы в функциональности,
производительности (в смысле скорости разработки),
количестве строчек кода нет
вот попытка формализовать понятия ооп и
использовать их в языках функционального программирования:
users.i.com.ua/~agp1/ru/oopFormalizm.html
класс удобно рассматривать как абстрактный автомат,
а тип, как множество состояний абстрактного автомата
Я только начинаю толком вникать в ООП, сейчас читаю Майерса, поэтому пример из его книги:
///////////////////////////////
class Lock
{
public:
explicit Lock(Mutex *pm):
mutexPtr(pm)
{
lock(mutexPtr);
}
~Lock()
{
unlock(mutexPtr);
}
private:
Mutex *mutexPtr;
};
// т.е. мне достаточно написать:
{ // - Начало блока
Mutex m;
Lock m1(&m);
} // - Конец блока (мне не важно как я его покину, но Мьютекс будет освобожден, даже если возникнет исключение, или кто-то изменит код, например, добавив return в середине блока)
у противников ООП есть более разумный вариант гарантированного освобождения ресурса?
T, это чисто С++-ный фокус с конструкторами и деструкторами, и к ООП едва ли имеет отношение.
Инкапсуляции должно быть *вмеру*! Это как косвенная адресация, только здесь она удлинняет вычисления в головах! И от самого себя, (да и от своих друзей) закрываться глупо. Также как и не закрываться от чужих.
Автор писал, что нельзя жить в пределах одной религии, а мыслить конструктивно. Сам же он явный стронник UNIX-философии. Я тоже. Но автар как-то извращенно понимает эту философию, философию простоты и минимализма. Вот мое мнение: проблема не в ООП, а в языках. Я абсолютно уверен, что можно для простоты сказать, что все есть объект, только во многих языках, напрмер в С++ возникает проблема с описание простого объекта, т.е. проблема в том, что простые объектные задачи, которых очень много, решаются избыточно и не естетсвенно. Всем советую попробовать Ruby.
Да какая там ваша жава объектно-ориентированная, у нее циклы и ветвления по условию не являются объектами. Не то что в православном лиспе ;).
java-lover: :)
В "православном" Лиспе всё есть списки, всё унифицированно до невозможности и дает преимущества, каких нет ни в одном языке, например: безымянные функции являются естественной частью языка, а не притащенными за уши как скажем в C#, далее язык макросов - тот же Лисп, а не отдельный язык, итд., и наконец, Лисп позволяет описать макросами объектную модель на любой вкус и цвет не меняя самого языка. Лисп фантастически мощный язык, но его освоение требует интеллектуальных усилий.
<< В начало