Хотя да, меру знать обязательно надо.

жжешь. ты еще скажи что там макросы -- верх совершенства:)

с другой стороны, любую вещь можно довести до абсурда. вообще, классы должны описывать типы, а не содержать логику.

с другой стороны, любую вещь можно довести до абсурда. вообще, классы должны описывать типы, а не содержать логику.

Из одного холивара:150+ кАмментов, вытащил пару вменяемых. Орфография цинично сохранена.  http://blogerator.ru/page/oop_why-objects-have-failed

 http://blogerator.ru/page/oop_why-objects-have-failed#comment-97

Clr

06.11.2010 в 06:45

Статья - эпик вин, тред комментариев успешно выведен в режим автотроллинга. По сути, изобретён новый уникальный вид холивара: Лисп против теории относительности - это реально круто.

Статистика очень интересная получается:

* На все 93 комментария только два адекватных - номера 58 и 59.

* Некоторые из представителей (как я понимаю) семейства ООП-кодеров-а-ля-освой-сишарп-за-31-день ничего другого, кроме процедурного и объектно-ориентированного подхода, не знают и искренне полагают, что на этом инженерная мысль благополучно и остановилась.

* Другие представители фауны путают методику с языком, а ООП с С++.

* Третьи берутся сравнивать Си (который, на минуточку, по своей сути является "высокоуровневым ассемблером") с ПХП. Напомню, что ПХП вообще начинал своё существование как шаблонизатор для подстановки переменных в HTML (и очень жаль, что там же и не закончил).

* НИ ОДИН не вспомнил о том, что ООП бывает классовое и прототипное, а это две большие разницы. Да и откуда такие слова-то знать, в самоучителе сишарпа об этом не пишут, а значит тру крутому пасану прогеру это и не надо.

* Ну и фееричное "спервадобейся" на тему отсутствия крупного софта, написанного на Сях. Ядро Линукс, ядро макоси, Апач, MySQL, интепретаторы большинства скриптовых языков, все Гномы, ну и вообще большая часть софта, существующего в рамках проекта GNU. Из другой "оперы": ядро винды, драйвера винды, графическая и десктопная обвязка винды - тоже Си. А Фряха так вообще ВСЯ написана на Сях, полноценная серверная операционка, да. Фактически, можно сказать, что наоборот, нет НИ ОДНОГО успешного случая применения статически типизированного ООП языка (С++, Ада, объектный паскаль, Оберон... ау?) в крупном, стабильном, развивающемся в течение десятилетий проекте, имеющем критическое значение для современной IT-индустрии. Подавляющаяя часть того, что крутится в наших компьютерах и стабильно работает годами, написано на Си.

Конечно, для тех, кому движок "Сталкера" кажется верхом технологичности, стабильности и качества - трудно представить, что есть программы, которые работают и не падают, натурально, годами: от включения сервера после установки в серверной и до его обесточивания через 5 лет.

Теперь что касается непригодности ООП. В том виде, в каком оно проталкивается уже 20 лет в массы, оно не пригодно для хоть сколько-нибудь сложных и ответственных проектов. Зато отлично подходит, чтобы посадить 20 индусов лабать код по заказу через аутсорсинг.

Конечно, есть годные ООП языки, такие как Руби, Питон... Реально хорошие и мощные языки, позволяющие прямо сказать машине, что нужно сделать, не ***хая мозг созданием нового класса на каждый чих. Но эти языки хороши не потому, что они ООП, а потому что это динамические рефлективные высокоуровневые языки. (Хых, для кого я это пишу... Из всех, кто тут писал комментарии, слово рефлективный поймёт 3 с половиной человека, не больше.)

Фактически, Руби и Питон - это Лисп с человеческим лицом. "Лисп для бедных." А все языки по своей внутренней сути, как известно, сводятся либо к ассемблеру, либо к Лиспу - третьего не дано. А если кто-то пытается усидеть на двух стульях сразу, в итоге получается получается С++, templates (тьюринг-полный язык в языке, адская жесть), бинарники HellowWorld на 4 мегабайта, и рефакторинг, рефакторинг, рефакторинг...

 http://blogerator.ru/page/oop_why-objects-have-failed#comment-128

[Свернуть] Беларус 15.11.2010 в 04:32

К ООП тоже отношусь спокойно, отрицательно.

Так вот, написание кода - это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять куда-то намыливается... И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение!

Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как. И вот тут, в объектно-ориентированных языках типа Java, С# начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, монстроидальным шаблонным метапрограммированием, полиморфизмом, исключительными ситуациями... Увидев вызов простой функции, как правило сразу понятно что происходит, можно сходить и посмотреть, что она делает. В объектно ориентированных языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, не поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.

Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, не сомневаясь, удаляет его. Программа перестает работать. Что случилось? Оказывается, конструктор этой переменной устанавливает связь с другим объектом. Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но что написано пером - не вырубишь топором. В результате программист (по-хорошему) вынужден прочитать описания всех конструкторов и деструкторов по всей цепочке наследования всех локальных cтруктурных переменных процедуры. Кому хочется шариться по 40 файлам, чтобы понять, что делается в процедуре? - да никому. Никто этого и не делает, в результате через 3 года в программе, лихо написанной на объектно ориентированном языке, не разберется никто. Посему, и надежность программ, размашисто написанных на таких языках, оставляет желать лучшего. Я уже не говорю про перекрытие операторов, конструкторов копирования и прочее. Творческое пользование темплейтами также сможет доставить потомкам немало приятных минут. А чего стоят исключительные события? Почему-то получается, что код, написанный на языке программирования без скрытого поведения, поддерживать и сопровождать гораздо легче. Просто уже потому, что вероятность наступить на грабли меньше. Описана переменная -- можно быть уверенным, что ничего больше это не означает. Вышли из блока -- значит, вышли, и нечего кроме. Что написано, то и происходит. Когда же приходится докапываться до третьего слоя истины -- это бардак. К сожалению, на объектно ориентированных языках наломать дров проще простого, что мы и наблюдаем изо дня в день.

Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен, иначе человек, который заменит Вас через 2-4 года, не справится. Хотите проинициализировать переменную? Вызовите процедуру. Надо вызвать функцию? Вызовите ее напрямую. Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает около 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?

Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, - чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен. Наконец, необходимым требованием является 100% обратная совместимость библиотек. Ну скажите мне, хоть одна библиотека для Java удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о вопросах совместимости, инсталляции и прожорливости разных версий фреймворков под C# .NET и о том, что на изучение постоянно изменяющихся спецификаций различных новомодных библиотек может уйти полжизни, не говоря уже о проблемах стабильности их работы на практике.

Смежная проблема. Возраст языка. Чем старше язык, тем лучше и глубже его знают программисты. Всем известно, что можно делать, чего нельзя, а что можно, но лучше не нужно. С новомодными языками дело обстоит сложней, и опыт, равно как устав караульной службы, пишется кровью программистов. Наконец, не следует забывать, что разработчики компиляторов тоже не боги и могут ошибаться, а чтобы найти баги в компиляторе с Java или, в особенности Сановском, напрягаться не нужно - баги Вас сами найдут.

Вообще, за последние 20 лет вышла масса литературы на тему дизайна программного обеспечения. Авторы книг статей постарались на славу. Были выделены и формализованы основные конструкции в виде паттернов проектирования. Сформированы основные практики и рекомендации. Однако, у этой большой и красивой медали есть обратная сторона - очень редко говорится О РЕАЛЬНОЙ НЕОБХОДИМОСТИ ПРИМЕНЕНИЯ тех или иных методик, а также о трудозатратах при этом. Подавлющая масса молодых программистов из-за отсутсвия опыта воспринимает все подобные материалы совершенно неадекватно, стремясь де-факто реализовать в одном месте практически все то, о чем они когда-либо читали и слышали (а слышали они в силу возраста как раз все последние веяния). Им трудно дифференцировать рациональные зерна от бесполезных "бантиков" и программирование превращается не столько в создание требуемого функционала, сколько в продумывание деталей как это будет написано. Внешнее и второстепенное выдвигается на первое место. Значительную часть времени начинает занимать бесполезный рефакторинг программного текста и мысли о том как же организовать очередное хитрое зацепление классов, в то время как создание полезнго функционала уходит на задний план. Например, в игровой индустрии подобные повадки особенно вредны. Нужен функционал, не нужен лишний текст. 99% текста выполняют 100% работы.

Например, когда-то одному разработчику был дан проект очень незатейливой игры. Предполагалось, что эта игра займет около месяца разработки. Но месяца не хватило. Спустя шесть недель выяснилась причина. Программист попался очень педантичный и вместо того чтобы взять чистый СИ и написать игру, он 80% времени занимался тусовкой классов в сложнейшей иерархии. Когда посчитали - оказалось порядка 210 классов. Движок получился, была написана чудовищная гора текста. В объекты было завернуто все, начиная от объектов межпоточной синхронизации и кончая экранными виджетами со своей собственной системой сообщений. Да только вот беда - сама игра была в совершенно зачаточном состоянии и не работала. Старые игры для GBA, C64, NES, SNES, Megadrive, ZX Spectrum, Atari, N64 всегда, с неизменным постоянством работали как часики. Можно конечно сейчас сказать "ну знаешь ли, не сравнивай сложность продуктов". А ничего подобного! Просто нужно знать как писались эти вещи и на чем писались. Раньше ведь даже не было IDE, и дебаггеров с одним тычком мыши. Не было самих мышей. Загружались с дискет (а еще раньше с кассет!). Иногда не было возможности отлаживаться или даже запускать код на самом устройстве. Так может уделять внимание эффективности, задачам которые пытаемся сделать?

Информация к размышлению:  http://www.softpanorama.org/SE/anti_oo.shtml