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

Добрый день.
Возникла такая проблема. Потихоньку изучаю ООП. С теоретической точки зрения вроде всё ясно, но из-за отсутствия практики, я не «въезжаю» в саму суть ООП. Какую практическую задачу можно реализовать, чтобы подробно вникнуть во все прелести ООП?
  • Вопрос задан
  • 16152 просмотра
Пригласить эксперта
Ответы на вопрос 10
Любую задачу (решаемую в принципе) можно реализовать как с ООП, так и без него (в процедурном стиле, например). «Прелести» ООП лучше всего чувствуются на больших проектах, где невозможно держать в голове все (глобальные) переменные и функции и способы их взаимодействия и приходишь к пониманию необходимости использовать более высокие уровни абстракции, чем отдельные значения и классические массивы из них. Начинаешь объединять семантически связанные данные в структуры (ассоциативные массивы в 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(). Если же без ассоциативных массивов вы уже разработки не представляете, то вы уже почти достигли ОО-просветления :)
Ответ написан
Eternalko
@Eternalko
> я не «въезжаю» в саму суть ООП

Стандартной задачей является класс пользователя.
class user.
Свойства
user_id
user_name
user_email
user_pass
Методы.
login
add_new_user
logout

Вот от этого и начнете «врубаться» что такое ООП и зачем оно нужно на практике.
Инкапсуляции и полиморфизмы оставьте на потом :)
Ответ написан
Assorium
@Assorium
Если совсем базовые знания, то могу поделиться собственным опытом. Мои первые два класса были для работы с БД и обработки изображений.

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

Класс изображений обеспечивал (он принимал как одно, так и массив изображений): ресайз изображений, перемещение, crop, отдачу статданных по цветности, цветам, заполненности, перевод изображения в ч/б, добавление watermark, добавление различных элементов и даже начал писать обработчик-аппроксиматор функций. В принципе по сложности и углубленности в понимании ООП он не отличается от первого, но в дальнейшем я не изменяя этого класса, написал класс-наследник, который обрабатывал все типы изображений. Сделал это только для того, чтобы попробовать наследование ручками, на самом деле помогло не рыться в старом коде, а просто зная подход, чуть чуть подкорректировать новый.
Ответ написан
TROODON
@TROODON
Напишите ещё одну ORM
Ответ написан
ilyaplot
@ilyaplot
PHP программист
Пока не попробовал Yii framework, не понял ООП и MVC до конца.
На хабре была статья про MVC ООП. Попробуйте повторить и расширить пример.
Ответ написан
@niko83
ООП это наследование, инкапсуляция, полиморфизм. Купите книгу Мэт Занстра кажется автор, там всё акуратно по полочкам растусовано и прочтите внимательно.
Параллельно поглядывайте исходный код современных фрэймворков. И попробуйте напсиать свой простой, не для того чтоб вознести его к вершинам, а сделать хотяб так чтоб всё работало — это развивает.
Ответ написан
alekciy
@alekciy
Вёбных дел мастер
Какую задачу? Хм… написать модуль к drupal, к примеру. 6-ой версии. А потом сесть и подумать, какие проблемы имеются и как бы их можно было решить используя ООП. Потому что, имхо, для понимания зачем вообще было придумано ООП и почему оно так стало популярно во множестве языков, нужно понимать, какие проблемы решает этот подход. А что бы видеть решаемые проблемы, их сначала нужно найти, пощупать руками на практике.
Ответ написан
shushu
@shushu
Простенькая задачка: Напишите шахматы :)
Без AI. Должно проверятся допустимый ли ход для данной фигуры. Должно быть как минимум одно наследование.
Ответ написан
@keyboard_maniac
Грэди Буч "Объектно-ориентированный анализ и проектирование
Ответ написан
@egormmm
Борітеся — поборете!
Напишите как утром просыпаетесь и чистите зубы. ООП - это моделирование мира, только не в реальном пространстве, а внутри компьютера.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы