Я давно и успешно применяю ООП - в сущности с самого момента его возникновения. Собственно, даже начала программирования мне преподавали по обьектно-ориентированным языкам, типа ALGOL-68. Большинстве кода на моем сайте вообще выложено на бейсике - а это на сегодня, вне всякого сомнения, САМЫЙ обьектно-ориентированный язык из существующих на этой планете. Которому пытаются подражать множество других языков, например новоиспеченный СиШарп (в котором даже в прошлом году уже даже появились анонимные типы, существовавшие в бейсике еще с 1998 года). Кое-какие элементы подражания обьектным возможностям бейсика есть и Яве и на прочих более простых языках. Но ни один более простой язык пока не приблизился к бейсику даже по количеству квалификаторов у методов/классов (а тем более по количеству всевозможных сокращений и умолчаний для ускорения обьектного программирования). Для примера вы легко можете любую Ява-прогу протранслирвать в более крученый Шарп. Но не наоборот. А шарп, хоть и использует тот же фреймворк, что и бейсик - но это язык подражатель. В нем постарались в более ли менее стандартном и распространившемся синтаксисе сделать доступ к тем же возможностям, которые были в бейсике (для NET и для COM) всегда. Однако, обратите внимание, что в огромном количестве мест в БилоГейтсовской идеологии применение Шарпа даже не декларируется! Никто не говорит, что VBA не будет, а языком автоматизации офисных приложений будет убогий новоиспеченный Шарп. Никто не говорит что НАТУРАЛЬНЫЕ COM-обьекты (без NET) когда-нибудь можно будет создавать на Шарпе. А ведь создание натуральных COM-обьектов - это базовая технология бейсика (ну и на С++ это тоже конечно возможно, только на C++ невозможно в приемлимые сроки сделать почти ничего из того, что обычно делают на бейсике). Никто не декларирует доступ к WMI из убогого новоиспеченного Шарпа. Никто не делает и не будет делать автоматизацию SSIS-пакетов для SQL-сервера на убогом шарпе. Поэтому бейсик-программисты так презрительно относятся к шарперам - что можно сделать на шарпе? Только облизнуться и расписаться в собственном бессилии, когда надо что-нибудь сделать на VBA, для WSH, для SSIS, создать натуральный COM-обьект и так далее. Проще говоря, даже во внутривидовой микрософтовской конкуренции Шарп - лишь убогое отражение/подражание старого и долго развивающегося бейсика. Шарп занимает ислючительно узкую нишу в билогетсовской идеологии и даже не покушается на безраздельное господство бейсика. Ну не говоря уже о межвидовой конкуренции (прогу на Шарпе с продвинутыми возможностями обьектного программирования вы не оттранслируете ни в какой другой язык, кроме конечно бейсика - но не наоборот - любой более убогий язык можно автоматически преобразовать даже в Шарп, не говоря уже о бейсике). Надеюсь этого пояснения достаточно для не владеющих бейсиком людей - чтобы понять, куда они попали - на страничку к бейсик-программисту. К программисту на самом обьектном в мире языке.

И как вы можете видеть по моим OpenSource и моим рецептам на этом сайте - я достаточно реально владею всеми возможностями этого самого продвинутого обьектного языка в мире. Я постоянно пишу Джеренерики, часто переопределяю в своих классах поведение отдельных методов в нижестоящей иерархии классов, постоянно создаю в своих классах события, я пишу свои делегаты с особыми параметрами, у меня горы многопоточных прог, типа прокси серверов, в которых надо тонко управлять синхронизацией ресурсов, я часто применяю маршализацию из одного потока в другой, а когда обрабатываю нерегулярные структуры - я создаю обьекты унаследованными от единого интерфейса. Часто применяю ad-hoc полиморфизм. Ну и так далее - для определенности начните со странички Практическое применение наследования, полиморфизма, интерфейсов, дженериков и делегатов на примерах в Visual Basic .NET. Перечень практически применяемых мною механизмов обьектного программирования бейсика - огромный. Настолько огромный, что для программистов на более простых языках даже затруднительно обьяснить что вообще такое делегат или дженерик - а тем более сложно обьяснить, чем применение того или иного обьектного механизма отличается у начинающего программиста от применения того же механизма опытным программистом. Но...

Но в этой заметке я бы хотел сосредоточится не на достоинствах объектно-ориентированного подхода (ООП), а на его НЕДОСТАТКАХ.

Увы, их так много, что непонятно чего же все-таки в обьектом программировании больше - достоинств или недостатков. Но о достоинствах вы наверняка прочитаете у кого-нибудь другого, кто попал в программирование СЛУЧАЙНО и занимается им совсем недолго 5-10-15 лет и при первой же возможности постарается выйти из этого дела на пенсию, став архитектором, начальником ИТО, тех.директором и так далее. Как правило, контингент таких мелких, случайных людишек является конформистами и старается максимально ПОДДЕРЖИВАТЬ текущую доминирующую струю.

Психологически, порочный круг, из которого трудно выскочить таким неокрепшим мозгам, состоит в том, что чем вещь ХУЖЕ, тем больше необходимо ее НАХВАЛИВАТЬ и, выпячивая НЕСУЩЕСТВЕННОЕ, умалчивать ГЛАВНОЕ. Иначе никак это НЕ ПРОДАТЬ. Особенно в этом гнусном занятии нахваливания ООП преуспела MS - поставив эту технику (которую трудно вообще-то отделить от мошенничества) на поток и зомбируя таким образом биомассу - УВЕЛИЧИВАЯ ОБЬЕМЫ СВОИХ ПРОДАЖ.

Не думаю, что MS смогла бы настолько набить свои карманы - продолжая развивать и совершенствовать Visual InterDev. Ведь он прост и вообще при минимальном опыте программирования легко заменим нотепадом. И как за это сорвать 50 тысяч долларов? Я сам не парясь его напишу весь за месяц (это же простой рич-текст-бокс с подсветкой!) - и куча народу уже сделала это преотлично и выложила бесплатно свои творения.

Но насколько технологии Visual InterDev лучше Visual Studio 2008 - говорить в среде конформистов почему-то совсем не принято. А мы поговорим об этом!

1. ООП-подходы уменьшают срок жизни программного обеспечения.

Реальность такова, что среда программирования меняется каждые пол-года - год. Возьмем наприме .NET FRAMEWORK. На протяжении последних пяти-шести лет среда сменилась множество раз:
NET 1.1 => NET 1.3 => NET 2.0 => NET 3.0 => NET 3.5

Каждый из созданных в некоторой среде объектов невозможно применить в последующей. Причем это верно даже для близко родственных сред, сделанных с совсем небольшим временным лагом - например попытка использовать на сайте NET 3.5 обьектов (зашитых в библиотеки) и сделанных на NET 3.0 приводит к фатальным ошибкам еще даже на этапе компиляции проекта.

Что уж говорить о не столь близкородственных фреймворках. MS публикует огромные списки функционала, который не поддерживается в последующих версиях его среды относительно предыдущих - например вот такой список http://msdn.microsoft.com/en-us/netframework/aa497288.aspx

И каким образом откомпилированный под NET 1.1 обьект должен работать в сайте под NET 4.0? А ведь такая библиотека - обьект собственности, стоимостью сотни тысяч долларов и миллионы. И какой срок жизни этой собственности?

Этот вопрос совсем не праздный, Например мой сайт www.gisis.ru использует 72 библиотеки. Часть из них сделана не мною. Давно. Году скажем в 2002-м. Стоимость этих библиотек весьма немалая. Например три программиста с ЗП в в три тысячи долларов, написавшие такую библиотеку за год - дают ей стоимость 3х3х12 = 108 тысяч долларов (без налогов). И кому нужна такая библиотека, если ею уже через полгода невозможно воспользоватся?

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

2. Текстовые скрипты основаны на ANSI-коде - поэтому дешевле, стабильнее и живут дольше.

Итак, изменчивость среды компиляции относительно ANSI-кода - дает нам первый элемент нестабильности и нежизнеспособности ООП и компилированных DLL относительно простых текстовых скриптов, типа простого ASP или PERL.

Хотя, если бы ANSI-кодом заведовала бы MS - она бы нашла поводы, каждые полгода выпускать новый ANSI-код под новую студию, которую надо было бы КУПИТЬ...

3. MS-cреда объектного программирования стоит безумно дорого.

Ну сколько стоят MS-проги я уже писал на своем хомячке. Повторятся ниахота, но это ДЕСЯТКИ ТЫСЯЧ ДОЛЛАРОВ. Зато ZEND в самой продвинутой профессиональной версии стоит $60 - примерно В ТЫСЯЧУ РАЗ ДЕШЕВЛЕ. А нотепад (с подсветкой ключевых слов) которым часто пользуются в средах программировования без ООП - вообще ничего не стоит.

Зафиксируйте для себя в мозгу этот коэффициент - не в два-три раза дороже обьектное программирование простого, А МИНИМУМ В ТЫСЯЧУ !

Я не имею ввиду усеченные версии для случайных простофиль - такое, что никак невозможно использовать на практике - MS вообще распространяет бесплатно, как наживку. Речь конечно идет о системах профессионального программирования.

4. Алгоритмически, обьектно-ориентированный подход - всего лишь замена параметризации.

Если обратить внимание на идеологическую сторону ООП-программирования - то вообще-то обьектно-ориентированный подход (наследование, полиморфизм и прочая лабуда) - они все-лишь ЗАМЕНЯЮТ параметризацию алгоритмов. Ну типа как развязки с флагами и IF-ами заменяют GOTO.

Не более. Абсолютно любой алгоритм с наследованием и полиморфизмом можно реализовать БЕЗ ООП, просто параметрами, передаваемыми процедурам. Причем это будет в разы быстрее, чем виртуальзация методов, обработки VTAB и прочая лабудень матрешечного программирования.

5. ООП-подходы усложняют программирование и особенно отладку.

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

Ругаемые GOTO и рядом не валялись со сложностью отладки ООП-матрешек...

6. Проектирование систем, основанных на ООП - дорого. А модификация - еще дороже.

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

Идея тут в том, что ТРУДОЕМКОСТЬ модификации внутреннего функционала тысячекратно превышает трудоемкость использования обьекта в целом. В отличии от такого подхода линейные текстовые скрипты не имеют такой разницы в трудоемкости модификации внутренних алгоритмов и внешне-предоставляемого пользователю интерфейса.

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

7. Закрытый функционал объектов - источник багов (и источник наживы).

В среде программистов не вызывает сомнений, что любой ЗАКРЫТЫЙ, потаенный алгоритм - это просто глюк. Это аксиома, на которой стоит криптография, например.

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

Другая сторона закрытости (кроме глюковатости) - такой код является ИСТОЧНИКОМ НАЖИВЫ. В отличие от простых текстовых скриптов, которые доступны ВСЕМ и продавать их практически невозможно. Закрытость и глюкавость - это многомиллиардный плюс для кошелька билла-дебила, ну а для нас?

8. Обьектно ориентированное программирование - это медленно.

Что такое каждый NEW в проге? Это выделение памяти из кучи. Возьмите главу 20 рихтера и почитайте про выделение памяти из кучи. И про алгоритм сборки мусора, который в NET 2.0 содердит аж в 10 000 (десять тысяч раз) БОЛЬШЕ кода, чем в NET 1.1

Какие кучи, какие обьекты, какие сборки мусора? Гугл работает на простых текстовых процессорах (типа PERL) - никогда не слышал ни про какой бред в виде выделения памяти из каких-то управлямых куч - и даже НЕ РАССМАТРИВАЕТ ООП как возможную технологию для примения в своих WEB-технологиях.

Не рассматривает, ИБО ТОРМОЗА...

9. ООП-подходы вообще притянуты к WEB-программированию без оснований.

Что такое Web-программирование? Это ТЕКСТ в ANSI-кодировке, который пришел по протоколу HTTP 1.1 из интернета на Web-сервер. Текст, который должен быть проанализирован и текст же, должен быть отправлен назад и интернет в виде отклика Web-сервера.

И где вы тут видите вообще упоминание каких-то обьектов?

Текст пришел - текст ушел. И множество движков, типа PHP или PERL так и работают. Кто сказал, что надо этот текст надо обрабатывать какими-то обьектами? Которые должны быть ОТКОМПИЛИРОВАНЫ в виде расширения IIS? Что за бред? И что эти обьекты должны итог своей работы СЕРИАЛИЗОВАТЬ ОБРАТНО в текст?

Но MS, паразитируя на рынке информационных технологий, проталкивает этот бред в наши мозги - ВМЕСТО ТОГО ЧТОБЫ ДОВОДИТЬ ДО СОВЕРШЕНСТВА ТЕКСТОВЫЕ ПРОЦЕССОРЫ. И весьма приуспела в этом...

10. Топовые по распространенности языки не имеет ООП-примочек.

Самый распространенный язык - как вы понимаете - HTML. Он не имеет приблуд в виде ООП. (Яваскрипт - не HTML- не путать).

Второй самый распространенный язык XML. Например, каждый мобильник имеет XSLT-преобразовтель для CSS. И где тут обьекты и вся ООП-шизофрения?

И третий по распространенности язык - SQL. Он тоже не имеет никаких матрешечных примочек.

Ну про языки Web-программирования и говорить нечего. Пожалуй лишь пара из них имеет пришлепки в виде матрешечного программирования...

11. Управление контентом откомпилированных сайтов весьма сложно и дорого.

Многие мои заказчики были просто в шоке, когда асазнали, что они не могут просто поправить верстку в нотепаде и разместить новости на сайте, сделанном на ASP.NET. Я рассказал им, что надо что-то поменять в базе - или вручную или для этого нужны НОВЫЕ CMS-формы, которые НАДО ПИСАТЬ...

Ну там про утапливание функционала поглубже - рассказал. Типо это пиридавое - если поменять просто так сложно. Типо есть внешний интерфейс обьектов - он и предназначен для замены, и вся изменчивость - должна быть ПРЕДВАРИТЕЛЬНО оговорена и вынесена ВНАРУЖУ обьектов, а что внутрии - то низзя просто так менять...

"Не, ну я понимаю - это ваши программистские игры" - говорили заказчики - "мне надо просто поменять допустим фамилию Иванов на Петров, но сегодня я пока еще не знаю о том, что мне потребуется поменять - как мне это сделать на твоих ASP.NET формах?"

"Ну а как добавить на сайт пару новостей или сменить верстку? Сейчас у нас сидит девочка и в нотепаде правит страничку и размещает там что хочет. Не морочь нам голову - как это сделать в ASP.NET без всех этих заморочек?"

Что на это ответить? Кроме рассказов о необходимости профинансировать разработку CMS? Иногда брали редактор бинарников и правили Иванова на Петрова... Если новоя фамилия без инициалов было не длинее старого с инициалами!

12. Программы делаются для людей, а не для машин.

Если же вглянуть на OOП с иной стороны - cо стороны MAIN-стрим движений в программировании. То что мы увидим? Этот мейн-стрим - это доступность и понятность всяких технических сложностей для человека. Прозрачность технологий. Ясность и предсказуемость действий машин и механизмов.

То, что ЧИТАЕМО и ПОНИМАЕМО человеком ЯСНО и без гимороя - гут, а там где бинарник с загадочными и глючными алгоритмами - это бед. Собственно, именно на этом посыле основано повсеместное распространение XML, HTTP, WEB-служб и даже XAML или WPF и WPF/E.

В этом аспекте - ASP.NET - полное противопоставление XML, HTTP, WEB-служб, XAML, WPF. Обожаю за это MS - у нее ВСЕГДА левая нога шагает в одну сторону, а правая - в другую. На благодаря технологиям зомбирования биомассы - задница все равно на мешке с деньгами!

МS полностью зациклилась.

Наконец-то, даже MS вынуждена признать недостатки своей идеи строгой типизации, которой она так долго гадила нам в мозг - наконец-то MS ввела АНОНИМНЫЕ ТИПЫ, что и есть фактически отказалась от строгой типизации.

Фактически LINQ - это и есть роспись с печатью в собственной неполноценности. В неполноценности идей, на размусоливании которых так долго MS набивала свои карманы. И в неполноценности своих якобы фантастических по мыслительному потенциалу подразделений - типо MS ресеч.

Жаль только широкая публика не оценила по достоинству этот прикол - все маршировали-маршировали в направлении строгой типизации (например хвалили ImageButton, так непохожий на Image и еще более непохожий на LinkButton!), потом хопа - и развернулись в противоположную сторону и стали хвалить переменные, позволяющие указывать и на ImageButton и на Image и на LinkButton. А стадо баранов этого и не заметило и продолжает послушно маршировать за билом-дебилом...

Похоже, МS думает - не имеет значение чем гадить в мозг программистам - лишь бы карманы набивать. А нам остается только удивлятся - с чего вдруг было хорошо ASP, все книги были расписаны от корки до корки ДОСТОНСТВАМИ неоткомпилированных программ на чистых текстах в Visual InterDev, потом вдруг в MS все умолкли про достоинства ASP, и стали говорить, что наоборот хорошо, когда все утоплено из текстов в библиотеки в Visual Studio 2002. Потом оказалось что не только хорошо, когда все ПРОСТО утоплено в библиотеки, а даже хорошо, что все очень-очень типизированно (и даже код заполнения DATALIST полностью отличается от кода заполенения GRIDVIEW !!!), потом вдруг это перестало считаться достоинством, а стало считаться недостатком и появились анонимные типы. Наверное дальше разработчиков анонимных типов и их дебильного LINQ в MS заклеймят как глупцов и давай опять по кругу. Не важно, о чем трещать - лишь бы карманы набивать.

Все это приемлимо лишь для случайных проходимцев, попавших в программирование ненадолго - на 5-10-15 лет и желающих побыстрее соскочить с этого дела. Но для тех, кто этим все занимается достаточно долго, профессионально и с удовльствием - смотреть на это безобразие отвратительно.

Comments ( )