// I am not sure why this works but it fixes the problem.
ООП -- парадигма весьма мощная и во многом интуитивно понятная, поэтому и более-менее популярная. Студент 2-3 курса, попрактиковавшись несколько лет в программировании и научившись ООП на отладке программ объемом 3-5 тысяч строк кода, вполне может этот опыт смасштабировать на задачу практически любого объема. Индусский код в Windows тому пример. Декомпозируй постепенно на достаточно очевидные сущности, и в принципе всё.
Но на практике требования со временем меняются, уточняются, добавляются, система быстро запутывается, и в конечном итоге такой ООП приводит к нескончаемой череде багов, крайней неповоротливости системы, нечитабельности кода и зависимости от автора программы.
Вопрос, в чём такое мэйнстримовское ООП отличается от некоего идеального ООП.
Если автор большой системы, созданной "мэйнстримовским ООП" (которое может быть и не обязательно объектным в классическом понимании, возможна обычная структурная декомпозиция на обычные модули), потом перепишет ее заново, она заработает уже гораздо лучше. На практике, достаточно 2-5 итераций, дабы добиться неплохой производительности и устойчивости. Windows опять же хороший пример.
Если посмотреть на разницу между первой версией и последней, то во многих случаях она будет заключаться в объектной/функциональной чистоте и минимизации взаимосвязей -- оригинальным идеям Smalltalk, сформулированным Аланом Кеем сотоварищи.
Прежде всего, это:
- "всё есть объект" (в том числе и неинтуитивные особенности системы -- функционал, обычно размазанный по разным модулям/объектам мэйнстримовского ООП и в таком виде активно тормозящий и генерирующий баги -- этот функционал умники из Xerox PARC сообразили формализовывать и выделять в так называемые "аспекты", и данная методологическая заплата оказалась столь удачной, что IBM её каким-то образом приватизировала, и затем оперативно запатентовала под брендом аспектно-ориентированное программирование);
- метаклассы;
- менять можно всё, в том числе и сам исходный код и синтаксис языка;
- вся логика работы реализуется путем обмена сообщениями между объектами. В частности, "условный оператор" формально определяется именно таким образом.
Отсюда мы плавно переходим, к монадам и функциональной парадигме:)
ООП при этом оказывается ненужной во многом оболочкой, лишь усложняющей процесс.
return null; //Not really null
Но на практике требования со временем меняются, уточняются, добавляются, система быстро запутывается, и в конечном итоге такой ООП приводит к нескончаемой череде багов, крайней неповоротливости системы, нечитабельности кода и зависимости от автора программы.
Вопрос, в чём такое мэйнстримовское ООП отличается от некоего идеального ООП.
Если автор большой системы, созданной "мэйнстримовским ООП" (которое может быть и не обязательно объектным в классическом понимании, возможна обычная структурная декомпозиция на обычные модули), потом перепишет ее заново, она заработает уже гораздо лучше. На практике, достаточно 2-5 итераций, дабы добиться неплохой производительности и устойчивости. Windows опять же хороший пример.
Если посмотреть на разницу между первой версией и последней, то во многих случаях она будет заключаться в объектной/функциональной чистоте и минимизации взаимосвязей -- оригинальным идеям Smalltalk, сформулированным Аланом Кеем сотоварищи.
Прежде всего, это:
- "всё есть объект" (в том числе и неинтуитивные особенности системы -- функционал, обычно размазанный по разным модулям/объектам мэйнстримовского ООП и в таком виде активно тормозящий и генерирующий баги -- этот функционал умники из Xerox PARC сообразили формализовывать и выделять в так называемые "аспекты", и данная методологическая заплата оказалась столь удачной, что IBM её каким-то образом приватизировала, и затем оперативно запатентовала под брендом аспектно-ориентированное программирование);
- метаклассы;
- менять можно всё, в том числе и сам исходный код и синтаксис языка;
- вся логика работы реализуется путем обмена сообщениями между объектами. В частности, "условный оператор" формально определяется именно таким образом.
Отсюда мы плавно переходим, к монадам и функциональной парадигме:)
ООП при этом оказывается ненужной во многом оболочкой, лишь усложняющей процесс.
return null; //Not really null