PHP, ООП. Практическое изучение
=================================

 Добрый день.   

Возникла такая проблема. Потихоньку изучаю ООП. С теоретической точки зрения вроде всё ясно, но из-за отсутствия практики, я не «въезжаю» в саму суть ООП. Какую практическую задачу можно реализовать, чтобы подробно вникнуть во все прелести ООП? 

 Любую задачу (решаемую в принципе) можно реализовать как с ООП, так и без него (в процедурном стиле, например). «Прелести» ООП лучше всего чувствуются на больших проектах, где невозможно держать в голове все (глобальные) переменные и функции и способы их взаимодействия и приходишь к пониманию необходимости использовать более высокие уровни абстракции, чем отдельные значения и классические массивы из них. Начинаешь объединять семантически связанные данные в структуры (ассоциативные массивы в PHP), а функциям с ними работающим давать имена с префиксом (обычно) в виде названия (чисто семантическое) этих структур, чтобы хоть немного упорядочить глобальное пространство имён, получая функции вида user\_login(array $user, $login, $password), user_logout(array $user) и user\_is\_logged(array $user). До простейшего ООП осталось сделать один шаг — перенести и функции (указатели на них в С, callback/имена в PHP) в эти структуры, но синтаксис вида call_user_func($user['user_login'], $user, $login, $password) мягко говоря неудобен и избыточен и тут в PHP4 вводят вместо него синтаксис $user->login($login, $password)` и без него ты больше не можешь жить :)  

  

Если же до семантических концепций ООП не дойти на своей шкуре, то разницы между user\_login(array $user, $login, $password) и $user->login($login, $password) почти нет, но даже на таком простом примере видно, что запись банально короче и глобальное пространство имён меньше используется, что особенно заметно при использовании IDE с автодополнением.  

  

Но это философское отступление было о некоторых прелестях ООП. Прямой ответ на вопрос «какую задачу?» — любую интересную хотя бы чуть-чуть. Желательно с развитой предметной областью, в которой ощущается интуитивно наличие нескольких абстракций разного уровня. Если для процедурного приложения вы создаёте несколько таблиц в БД или используете ассоциативные массивы для группировки семантически близких значений — то это, скорее всего, такая задача. Для большего wow-эффекта или просветления можно попробовать написать две версии одного приложения типа блога, одну в процедурном стиле, другую в ООП. Причём в первой желательно не использовать «промежуточные» решения типа ассоциативных массивов даже для mysql\_fetch\_assoc/array(), только бескомпромиссное mysql\_fetch\_row(). Если же без ассоциативных массивов вы уже разработки не представляете, то вы уже почти достигли ОО-просветления :) 

 > я не «въезжаю» в саму суть ООП  

  

Стандартной задачей является класс пользователя.   

class user.  

Свойства  

user\_id  

user\_name  

user\_email  

user\_pass  

Методы.  

login  

add\_new\_user  

logout  

  

Вот от этого и начнете «врубаться» что такое ООП и зачем оно нужно на практике.  

Инкапсуляции и полиморфизмы оставьте на потом :) 

 Если совсем базовые знания, то могу поделиться собственным опытом. Мои первые два класса были для работы с БД и обработки изображений.  

  

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

  

Класс изображений обеспечивал (он принимал как одно, так и массив изображений): ресайз изображений, перемещение, crop, отдачу статданных по цветности, цветам, заполненности, перевод изображения в ч/б, добавление watermark, добавление различных элементов и даже начал писать обработчик-аппроксиматор функций. В принципе по сложности и углубленности в понимании ООП он не отличается от первого, но в дальнейшем я не изменяя этого класса, написал класс-наследник, который обрабатывал все типы изображений. Сделал это только для того, чтобы попробовать наследование ручками, на самом деле помогло не рыться в старом коде, а просто зная подход, чуть чуть подкорректировать новый. 

 Напишите ещё одну ORM 

 Пока не попробовал Yii framework, не понял ООП и MVC до конца.   

На хабре была статья про MVC ООП. Попробуйте повторить и расширить пример. 

 ООП это наследование, инкапсуляция, полиморфизм. Купите книгу Мэт Занстра кажется автор, там всё акуратно по полочкам растусовано и прочтите внимательно.  

Параллельно поглядывайте исходный код современных фрэймворков. И попробуйте напсиать свой простой, не для того чтоб вознести его к вершинам, а сделать хотяб так чтоб всё работало — это развивает. 

 Какую задачу? Хм… написать модуль к drupal, к примеру. 6-ой версии. А потом сесть и подумать, какие проблемы имеются и как бы их можно было решить используя ООП. Потому что, имхо, для понимания зачем вообще было придумано ООП и почему оно так стало популярно во множестве языков, нужно понимать, какие проблемы решает этот подход. А что бы видеть решаемые проблемы, их сначала нужно найти, пощупать руками на практике. 

 Простенькая задачка: Напишите шахматы :)   

Без AI. Должно проверятся допустимый ли ход для данной фигуры. Должно быть как минимум одно наследование. 

 Грэди Буч "Объектно-ориентированный анализ и проектирование 

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