Зачем нужно объектно-ориентированное программирование в разработке
В мире есть много способов программирования. Но один из самых популярных и эффективных — это объектно-ориентированная методология или ООП. Она отличается от других подходов своей уникальной структурой и принципами, которые делают код более организованным и масштабируемым. Подробнее об этом — в статье от разработчиков компании DST Global.
Что такое ООП
Рассмотрим, какие преимущества может принести работа с объектно-ориентированный программированием. Ее основные элементы — объекты, которые обладают свойствами и методами. Каждый объект представляет собой хранилище данных и функций, что позволяет уменьшить сложность кода и повысить его читаемость и переиспользуемость.
Объект — это конкретный экземпляр класса, который обладает конкретными значениями своих полей. Объекты могут взаимодействовать друг с другом, вызывая методы других объектов или изменяя их состояние, что позволяет моделировать сложные системы и процессы.
Идея объектно-ориентированного программирования в том, что программисты могут создавать программы, которые представляют собой совокупность взаимосвязанных объектов. При этом каждый из них обладает особыми свойствами и методами. Принципы ООП помогают организовать код таким образом, чтобы он был более упорядоченным, гибким и масштабируемым.
Принципы ООП и их применение в разработке
Ключевые концепции, на которых строится объектно-ориентированное программирование — это абстракция, наследование, инкапсуляция и полиморфизм. Каждый из этих принципов играет важную роль в проектировании и разработке программного обеспечения, помогая создавать более гибкие и эффективные решения для сложных задач.
Один из важных принципов ООП — инкапсуляция. Она позволяет скрыть детали реализации объекта от внешнего мира и предоставить только необходимый интерфейс для работы с ним. Благодаря этому программисты могут повторно использовать код, упрощая тем самым разработку приложений.
Абстракция — очередной принцип объектно-ориентированного подхода. С ним разработчики могут представлять сложные системы с использованием абстракций, которые описывают только необходимые для решения задачи детали, скрывая сложность реализации.
Наследование — еще один ключевой принцип ООП. Он позволяет создавать новые классы на основе существующих, расширяя функциональность и повторно используя код. Это повышает эффективность разработки и облегчает поддержку программного обеспечения.
Класс — это абстрактное представление о типе данных, которое определяет состояние (поля) и поведение (методы) объектов. Класс можно рассматривать как чертеж или блок, из которого создаются объекты.
Полиморфизм — третий принцип, который позволяет обрабатывать объекты различных классов через общий интерфейс. Это упрощает написание гибких и расширяемых программ, где взаимодействие объектов может быть разнообразным и динамическим.
Применение принципов ООП в разработке программного обеспечения помогает создавать более структурированный, модульный и понятный код. Это помогает увеличивать производительность, улучшать качества продукта и облегчает его дальнейшее развитие.
Преимущества ООП в разработке и поддержке ПО
Применение ООП при разработке и поддержке программного продукта позволяет создавать более гибкий и модульный код, что упрощает его анализ, тестирование и изменение в будущем. Благодаря использованию объектов и их взаимодействию, разработчики могут легко добавлять новую функциональность, исправлять ошибки и разрабатывать новые версии программного обеспечения.
Но также у ООП есть и недостатки. Например, высокий порог вхождения для тех, кто хочет начать им пользоваться. Также этот метод снижает производительность и делает код более громоздким.
Введение в объектно-ориентированное программирование (ООП)
Объектно-ориентированное программирование (ООП) — это парадигма программирования, которая использует "объекты" для представления данных и методов, работающих с этими данными. В отличие от процедурного программирования, где основной акцент делается на функции и процедуры, в ООП основными строительными блоками являются объекты и классы.
ООП помогает разработчикам создавать более организованные и управляемые программы. Представьте, что вы создаете программу для управления библиотекой. В процедурном подходе вам придется писать множество функций для работы с книгами, читателями и транзакциями. В ООП вы можете создать классы "Книга", "Читатель" и "Транзакция", которые будут содержать как данные (например, название книги или имя читателя), так и методы для работы с этими данными. Это позволяет вам сосредоточиться на логике работы с объектами, а не на отдельных функциях, что делает код более структурированным и понятным.
ООП также способствует лучшему управлению сложностью программного обеспечения. Когда проект становится более масштабным, количество функций и процедур может значительно увеличиться, что делает код трудным для понимания и поддержки. Использование объектов и классов позволяет разбивать сложные задачи на более мелкие и управляемые компоненты, что облегчает разработку и поддержку программного обеспечения.
Основные принципы ООП: инкапсуляция, наследование, полиморфизм и абстракция
Инкапсуляция
Инкапсуляция — это принцип, который позволяет скрывать внутренние детали реализации объекта и предоставлять доступ к ним только через публичные методы. Это помогает защитить данные от некорректного использования и упрощает изменение внутренней реализации объекта без изменения его интерфейса.
Пример: Представьте класс "Банк". Внутренние данные, такие как баланс счета, могут быть скрыты от внешнего мира и доступны только через методы, такие как пополнитьСчет или снятьДеньги. Это позволяет защитить баланс счета от прямого изменения и обеспечивает контроль над тем, как данные изменяются.
Инкапсуляция также способствует улучшению модульности кода. Каждый объект отвечает за свою часть функциональности и взаимодействует с другими объектами через четко определенные интерфейсы. Это облегчает тестирование и отладку, так как можно проверять каждый модуль отдельно, не затрагивая остальную часть системы.
Наследование
Наследование позволяет создавать новые классы на основе уже существующих. Это помогает повторно использовать код и создавать более иерархически организованные структуры.
Пример: Вы можете создать базовый класс "Транспортное средство" и унаследовать от него классы "Автомобиль" и "Велосипед". Оба класса будут иметь общие свойства и методы, такие как скорость и передвижение, но также могут добавлять свои уникальные характеристики. Это позволяет избежать дублирования кода и упрощает поддержку и расширение системы.
Наследование также способствует улучшению читабельности кода. Когда вы видите, что класс унаследован от другого класса, вы можете легко понять, какие свойства и методы он наследует, и как они могут быть использованы. Это делает код более понятным и структурированным, особенно в больших командах разработчиков.
Полиморфизм
Полиморфизм позволяет объектам разных классов обрабатывать данные через один и тот же интерфейс. Это делает код более гибким и расширяемым.
Пример: Метод передвижение может быть реализован по-разному в классах "Автомобиль" и "Велосипед", но вы можете вызвать этот метод для любого объекта типа "Транспортное средство" и получить корректное поведение. Это позволяет создавать более универсальный и гибкий код, который может работать с различными типами объектов без необходимости изменения самого кода.
Полиморфизм также способствует улучшению модульности кода. Вы можете создавать универсальные функции и методы, которые работают с различными типами объектов, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые типы объектов, не изменяя существующий код.
Абстракция
Абстракция позволяет выделить только значимые характеристики объекта и скрыть все ненужные детали. Это помогает сосредоточиться на важных аспектах и упростить разработку.
Пример: Класс "Банк" может предоставлять методы для работы с счетами, не раскрывая, как именно эти счета хранятся и обрабатываются внутри. Это позволяет сосредоточиться на логике работы с счетами, не отвлекаясь на детали их реализации.
Абстракция также способствует улучшению читабельности кода. Когда вы видите, что класс предоставляет определенные методы, вы можете легко понять, как они могут быть использованы, не вдаваясь в детали их реализации. Это делает код более понятным и структурированным, особенно в больших командах разработчиков.
Преимущества использования ООП в разработке программного обеспечения
Повторное использование кода
ООП позволяет создавать повторно используемые компоненты, что сокращает время разработки и уменьшает количество ошибок. Например, класс "Банк" можно использовать в различных проектах, связанных с финансовыми операциями. Это позволяет сократить время разработки и уменьшить количество ошибок, так как вы можете использовать уже проверенный и отлаженный код.
Повторное использование кода также способствует улучшению модульности кода. Вы можете создавать универсальные компоненты, которые могут быть использованы в различных проектах, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Упрощение поддержки и расширения
Код, написанный с использованием ООП, легче поддерживать и расширять. Новые функции можно добавлять, создавая новые классы или расширяя существующие, не затрагивая при этом остальную часть системы. Это позволяет сократить время разработки и уменьшить количество ошибок, так как вы можете сосредоточиться на добавлении новых функций, не изменяя существующий код.
Упрощение поддержки и расширения также способствует улучшению читабельности кода. Когда вы видите, что класс предоставляет определенные методы, вы можете легко понять, как они могут быть использованы, не вдаваясь в детали их реализации. Это делает код более понятным и структурированным, особенно в больших командах разработчиков.
Улучшение модульности
ООП способствует созданию модульного кода, где каждый объект отвечает за свою часть функциональности. Это облегчает тестирование и отладку, так как можно проверять каждый модуль отдельно. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Улучшение модульности также способствует улучшению читабельности кода. Когда вы видите, что класс предоставляет определенные методы, вы можете легко понять, как они могут быть использованы, не вдаваясь в детали их реализации. Это делает код более понятным и структурированным, особенно в больших командах разработчиков.
Улучшение читабельности кода
Код, написанный с использованием ООП, часто более понятен и структурирован. Это облегчает его понимание и поддержку, особенно в больших командах разработчиков. Когда вы видите, что класс предоставляет определенные методы, вы можете легко понять, как они могут быть использованы, не вдаваясь в детали их реализации. Это делает код более понятным и структурированным, особенно в больших командах разработчиков.
Улучшение читабельности кода также способствует улучшению модульности кода. Вы можете создавать универсальные компоненты, которые могут быть использованы в различных проектах, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Примеры применения ООП в реальных проектах
Разработка игр
В разработке игр ООП используется для создания различных игровых объектов, таких как персонажи, враги, предметы и уровни. Каждый объект может иметь свои уникальные свойства и методы, что упрощает разработку и управление игрой. Например, вы можете создать класс "Персонаж", который будет содержать свойства, такие как здоровье и уровень, и методы, такие как атака и защита. Это позволяет создать более организованную и управляемую структуру кода, что облегчает разработку и поддержку игры.
Разработка игр также требует высокой гибкости и расширяемости кода. ООП позволяет создавать универсальные компоненты, которые могут быть использованы в различных играх, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Веб-разработка
В веб-разработке ООП помогает создавать компоненты, такие как формы, кнопки и таблицы, которые можно повторно использовать на разных страницах сайта. Это упрощает разработку и поддержку веб-приложений. Например, вы можете создать класс "Форма", который будет содержать свойства, такие как поля ввода и кнопки, и методы, такие как отправка данных и валидация. Это позволяет создать более организованную и управляемую структуру кода, что облегчает разработку и поддержку веб-приложений.
Веб-разработка также требует высокой гибкости и расширяемости кода. ООП позволяет создавать универсальные компоненты, которые могут быть использованы в различных веб-приложениях, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Разработка мобильных приложений
В мобильных приложениях ООП используется для создания различных экранов и элементов интерфейса, таких как кнопки, текстовые поля и списки. Это позволяет создавать более организованные и управляемые приложения. Например, вы можете создать класс "Экран", который будет содержать свойства, такие как заголовок и элементы интерфейса, и методы, такие как отображение и обновление данных. Это позволяет создать более организованную и управляемую структуру кода, что облегчает разработку и поддержку мобильных приложений.
Разработка мобильных приложений также требует высокой гибкости и расширяемости кода. ООП позволяет создавать универсальные компоненты, которые могут быть использованы в различных мобильных приложениях, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Финансовые системы
В финансовых системах ООП помогает моделировать различные финансовые операции, такие как переводы, депозиты и снятие средств. Это упрощает разработку и поддержку сложных финансовых приложений. Например, вы можете создать класс "Операция", который будет содержать свойства, такие как сумма и дата, и методы, такие как выполнение и отмена. Это позволяет создать более организованную и управляемую структуру кода, что облегчает разработку и поддержку финансовых систем.
Финансовые системы также требуют высокой гибкости и расширяемости кода. ООП позволяет создавать универсальные компоненты, которые могут быть использованы в различных финансовых системах, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Заключение и дальнейшие шаги для изучения ООП
Объектно-ориентированное программирование — мощный инструмент, который помогает создавать более организованные, управляемые и масштабируемые программы. Изучение ООП требует времени и практики, но это инвестиция, которая окупается в долгосрочной перспективе.
Для дальнейшего изучения ООП специалистами DST Global рекомендуется:
- Прочитать книги по ООП, такие как "Объектно-ориентированный анализ и проектирование" Гради Буча.
- Изучить примеры кода на популярных языках программирования, таких как PHP,Java, C++ или Python.
- Практиковаться в написании кода, создавая свои собственные проекты и решая задачи на платформах, таких как LeetCode или HackerRank.
Изучение ООП откроет перед вами множество возможностей и поможет стать более эффективным и продуктивным разработчиком. ООП позволяет создавать более организованные и управляемые программы, что облегчает разработку и поддержку программного обеспечения. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Изучение ООП также способствует улучшению читабельности кода. Когда вы видите, что класс предоставляет определенные методы, вы можете легко понять, как они могут быть использованы, не вдаваясь в детали их реализации. Это делает код более понятным и структурированным, особенно в больших командах разработчиков.
Изучение ООП также способствует улучшению модульности кода. Вы можете создавать универсальные компоненты, которые могут быть использованы в различных проектах, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Изучение ООП также способствует улучшению модульности кода. Вы можете создавать универсальные компоненты, которые могут быть использованы в различных проектах, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Изучение ООП также способствует улучшению модульности кода. Вы можете создавать универсальные компоненты, которые могут быть использованы в различных проектах, что упрощает тестирование и отладку. Это делает код более гибким и расширяемым, так как вы можете легко добавлять новые функции и компоненты, не изменяя существующий код.
Для сайтов почти всегда хватает обычного модульного программирования. Да и вообще к примеру если за основу брать php — то часто встречал утверждения, что в ней ООП плохо реализовано и мало кто этим пользуется.
ООП не раз подвергалось критике. Одно из самых ярких обвинений прозвучало от британского программиста — Джо Армстронга.
Проблема с объектно-ориентированными языками заключается в том, что у них есть вся эта неявная среда, которую они носят с собой. Вы хотели банан, но получили гориллу, держащую банан и все джунгли.
Это во многом справедливо. Помимо недостаточно качественной поддержки параллельных и распределенных систем, ООП отличается относительно низким качеством конечного продукта.
В процессе трансляции объектно-ориентированных программ в исполняемый код центрального процессора возникает ряд неоптимальностей по использованию памяти и вычислительного времени процессорных ядер.
ООП предоставляет вам множество способов замедлить работу ваших программ.
А небезызвестный Линус Торвальдс часто критиковал ООП и С++ в частности, упоминая в том числе отсутствие ограничений. Речь о том, что большое количество инструментов и методов позволяет добиваться функционально одинаковых реализаций множеством различных способов. Это можно было бы считать преимуществом, но появляется риск ошибок, обнаружить которые очень сложно. Наследование объектов может привести к тому, что баг «вылезет» в неожиданном месте, далеко от исходной неточности в описании «родителя».
В нулевых годах начали массово распространяться многоядерные и многопроцессорные системы. Возникла потребность в распределенных вычислениях, а чуть позже в вычислениях на графических процессорах. Оказалось, что ООП справляется с такими задачами значительно хуже, чем функциональные программы. Даже исходя из одного этого фактора, можно усомниться в бесконечном доминировании ООП.
Конечно, пропорции в разработке будут меняться. Это уже происходит. Кроме того, рано или поздно появятся принципиально другие, новые подходы — и они могут оказаться недостижимо более производительными, особенно на модернизированном железе.
Тем не менее, пока что ООП остается надёжным, удобным инструментом. Похоже, в ближайшие годы ничего не предвещает серьезных подвижек, так что можно смело использовать объектно-ориентированное программирование и в качестве личного карьерного плана, и для запуска проектов.
Я давно и успешно применяю ООП — в сущности с самого момента его возникновения. Собственно, даже начала программирования мне преподавали по обьектно-ориентированным языкам, типа 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 публикует огромные списки функционала, который не поддерживается в последующих версиях его среды относительно предыдущих — например вот такой список 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 лет и желающих побыстрее соскочить с этого дела. Но для тех, кто этим все занимается достаточно долго, профессионально и с удовльствием — смотреть на это безобразие отвратительно.