Изучаю PHP написал свой блог на обычном PHP сейчас его хочу переписать на ООП исключительно с целью изучения этого самого ООП (в дальнейшем планирую пойти на фреймворки а там знание ООП я так понимаю необходимо). Да я знаю что такие маленькие блоги на ООП не пишут.

В общем смысл ООП понятен - есть классы, внутри них объекты, ещё есть методы которые определяют что может делать класс. Наследование что бы код не плодить, сокрытие реализации тоже вроде понятно...

Как дохожу до дела нифига не понятно что писать.

Функционал блога: разделы (темы), каждая запись может принадлежать только одной теме. На странице темы выводится анонс записи, а если это поле не заполнено - первые 200 символов.
Комментариев нет, тегов нет, регистрации нет, единственный юзер-админ заносится через БД.
В админке функции: добавление темы, записи, их редактирование, удаление.

Не знаю даже с чего начать.
Какие должны быть классы? Класс "записи" и класс "темы" а методы этих классов это как раз добавление, редактирование, удаление? Класс CRUD для работы с БД надо свой писать?

На процедурном php я помню что начал с добавления записи в БД, потом страница авторизации, потом защитил страницу добавления статьи проверкой сессии, потом сделал вывод статей списком, вывод разделов, затем вывод статей по разделам и в конце пагинатор прикрутил.

Даже hello world пишут на ооп.   

Сначала нужно понять - зачем оно нужно. Правильно организованная система позволяет выдергивать из себя части и вставлять в себя новые без модификации остального кода.
Части блога 

•  работа с базой данных. Нужно подумать, в каком месте поменяется код, если сделать базу блога на файлах, например. 
•  система авторизации. Что нужно поменять, если внезапно появятся пользователи с разным набором прав?

Первый, imho, кандидат на переписывание - система авторизации с правами и группами.

Вообще-то, если есть какие то представления об ООП - понять зачем оно действительно нужно можно на примере серьезных фреймворков. Yii, например. В качестве более практичного, imho, примера - можно смотреть на joomla и разобраться как действуют плагины в ней.
С одной стороны - на собственных шишках учиться проще, быстрее доходит, а с другой - так можно смастерить собственный мирок и жить в нем, не понимая что происходит снаружи. Лучше сначала познакомиться с хорошими приемами программирования, чтобы собственный "мир" не слишком радикально отличался от внешнего   

zero50x, не совсем верно высказывание

класс - это конструкция вида

тогда как объект - это инстанс этого класса:


Вообще ООП можно легко перевести на реальную жизнь. Например класс - это вообще "человек" в целом, а Иван - это объект класса человек.

Если говорить про наследование - то все люди в среднем умеют говорить. Это может быть абстрактный метод интерфейса. Но у каждого конкретного класса своя реализация: например у подкласса "Русские" язык русский, а у подкласса Французы - французский 

Если задача именно изучение, я например немного не согласен с ksnk в том, что нужно лезть в возможно еще сложные для понимания фреймворки. Кому-то проще начинать с малого, главное делать это по хорошим урокам или советам, и тогда "собственный мирок" не будет отличаться от того, что происходит снаружи 

Класс темы наверное не нужен будет. Это все же сущность чисто группирующая. А вот класс поста (записи) будет нужен. Так же можно сделать класс пользователя, если думать на будущее.

Не совсем ясна фраза:

CRUD это концепция, но никак не класс. Можно написать свой класс-обертку для работы с хранилищем, а в нем реализовать концепцию CRUD, создав четыре соотв. метода.

Спасибо всё понял из фреймворков покопал CodeIgniter в целом понравился, но работать в слепую с фреймворком не зная ООП мне кажется некорректно, надо всё же разобраться что бы иметь представление что происходит-то тут вообще ))

zero50x, самое главное не верить "умным дядькам", а делать самому.. А к тому что не обязательно следовать логике исключительно MVC или чему-то подобному. Пиши то что сам считаешь нужным и удобным..   

А вообще, чтобы начать я начинаю с тетрадки и ручки.. Для начала нужно понять что будет и "сколько и какие классы это будут делать".

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


если практично подходить к вопросу.. то я начинаю с файла index.php Может это и банально, но он у меня формирует мысли проекта 

Вот из чего он состоит

1. Так как у меня будет только один вход в систему и через этот файл, то необходимо опредеить "родительский флаг". Можно так

При этом все остальные файлы проекта будут начинаться с

Это для того, чтобы исключить прямой загрузки файлов проекта

2. Иногда важно иногда нет, но всё же

3. Есть смысл определить константу абсолютного пути сайта. Она нам очень как пригодится и не один раз

4. Так как у нас будут и другие глобальные и важные переменные, то мы их конечно же поместили в отдельный файл и соответсвенно подключем их

Основных констант много, например, пути до основных папок, форматы данных и т.п. и т.д.

Ну и если есть (а это практически всегда бывает), то подключаем файл настроек

Некоторые вещи иногда лучше хранить в PHP-файлах и в переменных.. например, настройки для подключения к БД

5. Лично я начал использовать обработку исключений и поэтому далее идёт блок обработки исключений.

Хотя обработка исключений вообще спорна.. Она хороша для отладки, а дальше она не нужна.. С другой стороны если есть ошибка, то и так всё будет видно.. ну да ладно..

6. Далее я бы подключил "обёртку для работы с базой данных. Могу посоветовать свою "обёртку" (не в качестве рекламы, а дружбы ради). Основана на MySQLi, использует подготовленные выражения, кеширование запросов.

(как видно, я уже беру пути из [4]

7. Современные проекты не обходятся без автозагрузчиков классов, а значит подключаем то, что будет их обрабатывать


8. Всегда есть какие-то общие функции (методы) которые нам всегда и везде требуются (например, получение значения из глобальной переменной) и поэтому мы подключаем эти дополнительные возможности

9. Ну и далее делаем уже управление всем проектом. Так как у нас только один вход, то URL будет примерно такого вида

Конечно, я делаю адреса с ЧПУ, но на данном этапе это пока рано обсуждать  
И соответсвенно нам нужно получить страницу куда идти. Делаем что-то типа такого

ну и далее само управление


А вот теперь можно и считать что нам нужно.
1. Класс для работы с базой данных
2. Класс автозагрузчика классов
3. Класс для общих и частовостребованных функций
4. Класс управления страницами
Соответственно к нему в данном примере:
5. Класс для управления новостями
6. Класс для управления статьями
7. Класс для управления Главной страницей
8. Соответсвенно не помешало бы иметь класс для управления шаблонами. Если проект маленький то можно и один иметь. Если большой или большой функционал, то для каздой "странице" свой (в принципе что-то подобное MVC)
9. Конечно нам понадобятся библиотеки. И опять же, если маленький проект, то можно всё закинуть в function.php.
Но лучше всё же  сделать всё отдельно
- Класс для работы с датами
- Класс для работы с UL
- Класс для работы с языковыми файлами
- Класс для работы с кешем
- Класс для работы с картинками
- Класс для работы с текстом
и т.д. и т.п.
10. Можно ещё расширить класс для обработки исключений..

Вот где-то так для начала    надеюсь чуть помог

Это сообщение отредактировал(а) Gold Dragon - 21.6.2014, 19:59

А что плохого в "прямой загрузке файлов проекта", если в таком файле есть только описание функций и классов?

Добавлено через 7 минут и 37 секунд
При использовании регистрируемого автолодера, строка с его собственный подключением обязаны быть ЕДИНСТВЕННЫМ на весь проект использованием include'а. Иначе это неправильное использование автолодера   

Если я правильно понял, то ты говоришь об этом?

Абсолютно ничего плохого!    но абсолютно не удобно..  вот только будет много избыточного кода, нет единой инициализации проекта (сессии, база данных, ядро, логирование....), будет отсутствовать контроль за подключаемыми модулями. Опять же если использовать ЧПУ, то единый вход более динамичен и настраиваемый... Да и я себе трудно представляю как можно это реализовать на достаточно большом проекте, например том же фреймворке   

Это удобно применять на чём-то маленьком.. том же блоге или форуме
Так у меня это именно так и есть   

Добавлено через 2 минуты и 41 секунду
кстати, это проблема может быть если используется не единая точка входа   

Нет, не об этом. Для одной точки входа, index.php выведет что-то осмысленное, а остальные файлы содержать только описания классов.
Если вызвать такой файл - пользователь все равно ничего не увидит, и кроме факта наличия такого файла в системе, никакой дополнительной информации не получит. Так что  "защита" не нужна. А вот с конкретно такой защитой, потенциальный злоумышленник получит еще и абсолютный путь до файла. Обычно, он содержит имя учетной записи хостинга, что, конечно, не особенно секретно