Как не надо понимать объектную ориентацию (Рейтинг: +6)

Здравствуйте.
Перечитывал несколько раз статьи этого блога и решил пока не заниматься переосмыслемиен парадигмы, а затронуть вопрос неверного толкования при первом знакомстве с ООП.
Другими словами чем не является объектная ориентация и как не стоит ее применять.
1. Конечно же сначало нужно выбросить из головы такое понятие как класс и посмотреть вокруг. Понимание принципов ОО начинается с осмысления того, что такое окружающие нас объекты и что они могут. Начинать изучение ООП с термина "Класс" это главная ошибка, сродни изучению программирования с определения функций (функции лишь способ группировки алгоритмов, а не алгоритм). И так что же такое объект? Возьмем что то простое, шар. Шар это объект с точки зрения ОО и логики. Какими словами можно описать шар? Ну скажем его плотностью, цветом, диаметром, материалом (прежде чем читать дальше, попробуйте продолжить список и назвать еще пару-тройку подобных характеристик шар). Хорошо. Шар имеет некоторые характеристики, с этим вроде понятно. Но вспомним сколько шаров есть с совершенно различными характеристиками. Игровые шары (футбольные и баскетбольные мячи, шарики для пинг-понга и т.д.), мячи технические (на пример в подшибниках), оружейные (ядра и пули). У них довольно много общего (попробуйте назвать одинаковые характеристики для разных шаров, на пример диаметр). Вот здесь на арену выходит "Класс". Класс - это совокупность общих характеристик разных объектов. На пример класс - футбольных мячей. Объекты этого класса будут конкретными футбольными мячами, какие-то более новые, какие-то более рваные, но характеристики их не будут отличаться, что впрочем нельзя сказать если сравнить их с объектами класса - ядро. Другими словами классы определяют и содержат общее для объектов. Создавая объект на основе класса, мы будем точно знать что этот объект содержит те же характеристики, что и его класс.
2. Теперь забудьте про функции в классах. Классы и объекты это не способ удобного хранения переменных и (что более актуально у новичков) функций. Класс это то общее что есть у его объектов, а характеристики класса и методы (функции) это то, что есть у всех объектов этого класса. В чем прелесть этого подхода. Вспомним получение от пользователя данных о его электронной почте. Нужно проверить все ли там правильно заполнено, а при необходимости резать адрес почты на части чтоб получить скажем его домен или логин. А теперь представьте что есть класс "АдресЭлектроннойПочты" который включает методы - получить весь адрес, получить логин из адреса, получить домен из адреса. И мы знаем что все объекты этого класса будут иметь эти методы и при их вызове мы всегда получим строку корректными данными не беспокоясь о подмене или безопасности. Более того, мы можем даже не знать как именно класс и его объекты хранят и возвращают эти данные, нам это больше не важно, единственно что нам важно, это то, что у них эти методы есть и они дают нам ожидаемые данные. Другими словами методы класса это те его функции, которые позволяют нам с его объектами взаимодействовать, изменять их, получать данные (которые может предоставить объект), заставлять делать что то, а не любые, возможно даже не связанные с объектом функции.
3. Медленно вытекающее из 2. Классы должны выполнять что то небольшое но хорошо. Это значит что включать в класс "адресЭлектроннойПочты" такие методы как "отправить письмо" или "найти в адресе подстроку" не правильно. Вдумайтесь в название класса - адрес электронной почты - это вам не - почтовый клиент - и тем более не - центр обработки строковых данных - это куски адресов почты которые имеют определенную структуру и не более того. Следовательно методы класса должны не выходить за рамки этой структуры.

И так продолжу писать о том, чем не является объектно-ориентированный подход и как не следует его понимать.
4. ООП не способ уменьшить или ускорить код, тем более это не способ улучшить процедурный подход, это совершенно новый взгляд на программирование и разработку. Если в основе ранних языков программирования лежит алгоритм и способ его группировки - функция, то в ООП во главе стола объект, принцип "черного ящика", повторение кода и модульность. Что это означает? Принцип "черного ящика" гласит [Сталинским поучительным тоном] - мы знаем что в черный ящик что то входит и выходит результат, а что происходит в нем мы не знаем - чистейшая инкапсуляция (сокрытие) действий и данных. С повторением кода конечно отлично справлялись функции, но классы позволяют использовать такой важный принцип как наследование кода и его расширение в субклассах (целью статьи не является описание принципов ООП, а посеяние зерна правильного направления, потому узнайте о наследовании и полиморфизме уже сами). Модульность ОО подхода обеспечивается за счет того, что объекты и классы знают только об интерфейсах (наборе доступных методов) других объектов и классов, что позволяет заменить объект другим, с таким же интерфейсом, при этом программа будет работать без перебоев. Более того, возможна динамическая смена поведения программы без изменения кода (без ООП этого добиться довольно сложно, можете попробывать сами изменить поведение функции в процессе работы программы). Если интересно больше узнать об этом, почитайте про шаблоны проектирования "Стратегия" и "Состояние".
5. ООП не усложняет код, он его расширяет новыми возможностями. Часто при использовании ОО подхода код становится в разы больше, но любому опытному ОО разработчику будет легко в нем разобраться потому, что он более абстрактен и приближен к человеческой логике и структуре мышления, нежели математический подход процедурного стиля. Постоянно растущее число небольших классов, выполняющих элементарные операции это удобно, так как работать с простым проще, чем со сложным (вспомним учительское - от простого к сложному).
6. ООП это НЕ СЛОЖНО. Просто нужно временно перестать сопротивляться новому в защиту процедурного подхода (мы же не бабки на лавочке) и попытаться понять принципы работы ООП. Они довольно интересны, но в то же время необычны и часто непонятны. Попробуйте начать сначала и придерживайтесь пути ОО хотя бы в течении пары недель, и вы удивитесь как раньше жили без ОО подхода к программированию.
P.S.: пожалуйста, не используйте классы и объекты как копилку функций и переменных, для этих целей существуют именованые области видимости. Строго ограничивайте возможности класса. Класс это не бог, и делать он умеет совсем не много.

Продолжая серию затрону еще несколько важных ошибок начинающих умов.
7. ООП это модно и в этом вся сложность. Незнакомые с ООП люди в свое время создали такой гул вокруг этой парадигмы, что чуть ли не любой продукт со словом - объектная ориентация - становился уважаемой и важной "программой". Вы и сами наверно видели не раз такие записи - ЗЦ написан с ООП, форум на ООП, гостевая на классах - долгое время находясь в поисках помошника я пересматривал все эти "супер вап программы" и не нашел ни одного правильно реализованного ОО решения! Современные вап мастера очень мало знают об ОО подходе к написанию программ. Для них это скорее модное слово из которого они знают совсем не много. Не нужно подходить к ООП как к новой, модной игрушке, потому что парадигма таковой не является. ОО подход это логичная, довольно интересная и функциональная смесь, облегчающая сопровождение, расширение, модульность и разработку программ.
8. ООП это не только понимание классов, объектов, свойств и методов. Как часто я встречался с собеседниками, которые закрывали тему, как только она заходила о таких простых вещах как "паттерны" проектирования и ООП. Знали бы вы как меня радует то описание MVC, что я читаю в различных темах. Мало кто из авторов этих тем знает что модель-вид-контролиет это паттерн паттернов, потому что состоит из очень не малого числа более простых шаблонов. Большинство сегодня знают только общие определения ОО подхода, такие как класс, объект, метод и т.д. даже не пытаясь углубиться в понимание таких фундаментальных и не менее важных вещей как интерфейс, абстрактный класс, дружественная функция и композиция, а ведь именно эти механизмы позволяют делать ОО код более гибким и модульным.
9. Не верьте сплетням об ООП. Самыми лучшими источниками информации были и остаются признанные книги (стоит ли перечислять какие именно? О них узнает без проблем любой кто захочет), а изучение семантики и принципов, заложенных в таких языках как C++ помогают еще больше понять эту концепцию. Статьи о ООП, которыми пестрит интернет, это редкие помошники, которые чаще направляют на неверный путь. Более того язык PHP не самое хорошее начало для изучения ООП, конечно для понимания всех его граней необходимо изучить его реализацию в разных языках (достаточно сравнить javascript и PHP, которые поддерживают в разной степени ОО и увидеть насколько различается их реализация), но на сегодняшний день PHP довольно слабо развит в этом направлении (хотя последние изменения в нем меня очень обрадовали).