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