В общем приблизительно такая задача:

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

Естественно хочу попробовать объектно-ориентированный подход к разработке. 

Страница будет такая:

( Сверестаное html-представления есть, блоки разбиты на таблицы не фреймы)
ЧПУ будет вида  ?page=1 ...

контент-менеджер, для зарегистрированных пользователей будет приблизительно таким:


Админ панель(а там будет управления Меню-Навигация, Управления Пользователями и Статьями), например уголок для статьи будет таким:

(ну конечно же в реальности там будет чуть больше полей, и расширенно!)

Только вот в голове куча мыслей ... (Никак собрать не получается)

Как это организовать(на ООП,) от чего мне оттолкнуться? 
(В частности интересует модель MVC, возможно зенд фраймворк)

Подскажите хотя бы сам принцип как это все должно работать на ООП ?
(как спроектировать правильно систему в целом, разбить на классы, отделить логику от view и т.к)
По поводу проектирования БД - это подсказывать не нужно! (это я сделаю сам  )

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

Но для этого простого колеса, хотелось бы использовать уже некоторые готовые решения(подшипники,гайки и т.к.), посоветуйте какие ? (только не полностью готовая cms подобного вида, а для этого колеса подрядные элементы).

Если у вас есть свободное время поделиться опытом, натолкнуть на мыслю, пнуть носом. Буду весьма признателен!   

Попробую помочь.
Первый этап паттерн MVC
1. М-Model(Модель)
По сути все классы которые будут описывать таблицы в БД.
Есть у нас  допустим таблица user с полями id, name, password
Ей создаем соответствующей класс User

2. V-View(Представление)
Это классы которые отвечают за формирования ответов(представления) браузеру.
Допустим у нас есть некая абстрактная страница на которой мы хотим видеть отображение списка имен зарегистрированных пользователей. Создаем класс UserListView.

На выходе получим список пользователей. В представление мы можем подгрузить также шаблон с HTML-кодом и формировать его по нему. Это позволит нам легко менять представление и исправить только шаблон вывода без изменения кода самой системы. Тоесть если мы захотим вывести не просто список пользователей а список из ссылок на странички о пользователях то мы делаем шаблон из следующей строчки.

3. C-Controller(Контроллер)
Класс который по сути будет говорить как и что делать в зависимости от пришедших в него параметров.

это все очень упрощенно но надеюсь про паттерн MVC представление появилось.

Это сообщение отредактировал(а) krundetz - 1.6.2008, 21:01

krundetz, что ж спасибо за начало...
Я себе так это приблизительно и представлял, 
т.е. первым делом сделать классы например
User
Admin возможно будет наследником User
Article
Menu и т.к.

(код не обязательно приводить, мне достаточно ориентировочного псевдокода, т.е. в какую сторону двигаться)
Меня сейчас больше интересует View. (хотя и Model в частности тоже).

Стоит ли делать отдельный объект(класс) для работы СУБД MySQL ?  (в частности подключения(постоянный конект) и использовать во всех запросах его ресурс, что туда еще можно закрепить?) 
    

Первым делом вам нужно выделит все возможные сущности из диаграммы прецендентов для этого собственно она и рисуется. Admin точно будет наследником User по диаграмме сделанной вами четко видно что функционал совпадает а OOP как раз и направлен на то чтобы использовать раз написаный код несколько раз.

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

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

Клас для работы с БД делать обязательно стоит, но в качестве Обертке(паттерн) к mysqli или PDO так как это позволит вам воспользоваться паттерном Синглетон. Что позволит делать обращение к БД из любой точки программы и любого класса непосредственно не передовая им класс отвечающий за работу с БД.

Попробую выделить сущности:

•  Пользователь (User)
•  Администратор (Admin)
•  Система (Aplication)
•  Вход В Систему (Access)
•  Статьи (Articles)
•  Меню (Menu)

(Если что поправьте меня, это мои первые шаги)
Эти сущности я так понимаю и будут каркасом для объектов ? (т.е. отдельные классы)

хм. как приблизительно реализация класса  Aplication ? (пока не представляю)


паттерн Обертке ? (не читал, если можно объяснить, или ссылку на информативное описание)

А вот по поводу PDO (если правильно понял) , как считаете целесообразно использовать базовый класс PEAR DB ? (или самому что то такое написать) (хотя не вижу смысла, СУБД будет только MySQL)

по поводу паттерна Singleton читаю  Джордж Шлосснейгл "Профессиональное программирование на PHP" страница 67, очень кратко описано ,но саму суть уловить сложновато :(

(я пока в паттернах не ориентируюсь, но постараюсь исправиться)

Добавлено через 5 минут и 15 секунд

Действительно, меленькое представления про MVC появилось 

Сначала по паттернам.
Обертка. Более правильное название Adapter. Одно из назначений предоставление унифицированного способа доступа к куску программы не зависящему от вас, простой пример есть некий модуль и вы используете его функционал в нескольких местах програмы допустим этот модуль както изменился и нам приходится изменять програvму ища в ней места его использования(например хостер взял и обновил каrой либо модуль PHP, а там функционал работает по другому). Выход написать класс обертку который будет инкапсулировать в себе работу со сторонним решением.
Singleton или Одиночка. Используется там где требуется как раз создание одного единственного класса в системе. Для этого делаем клас у которого приватный конструктор и есть статический методом возвращающий экземпляр этого класса при этом о
Для этого создаем класс который возвращает статическим методом экземпляр самого себя. Перед тем как возвращать экземпляр класса будем проверять есть ли в системе уже такой класс или нет для этого введем статическое свойство которое будет указывать либо на null либо на созданный экземпляр класса. Для того чтобы в программе невозможно было создать экземпляр класса сделаем конструктор закрытым. В итоге получим вот такой код.

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

И работать с экземпляром класса дальше.

Добавлено через 13 минут и 31 секунду
Теперь по Aplication. Здесь у вас должно создаться всё то что необходимо для работы системы как то какой сейчас пользователь пользуется системой, инициализироваться все необходимые настройки, определиться какой вариант работы выбрать в зависимости от него определить и запустить необходимый контроллер и т.д. В большинстве случаев у него только один случай либо только конструктор либо статический метод run.

Сущности выделены правильно за одним исключением будет не вход в систему а модуль авторизации, который будет проверять авторизован ли пользователь и в случае если не авторизован выдавать в браузер в качестве представления форму авторизации. В процессе реализации необходимо совершенствовать диаграмму прецедентов так как могут выплыть то что сразу было не увидено соответственно также могут появиться новые сущности.

На следующем этапе надо нарисовать диаграмму существующих в системе классов и их взаимозависимостей и диаграмму последовательностей.

Литературу на память не помню но подберу списочек и здесь отпишу.



Это сообщение отредактировал(а) krundetz - 1.6.2008, 23:19

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


По поводу почитать...
Есть две "классические" книги:
1. Т.н. "банда четырех" ISBN: 978-5-469-01136-1. Очень сухая книга, воспринимается очень тяжело.
2. Фаулер. ISBN: 978-5-8459-0579-6. Написана живым языком, читается намного легче да и охватывает больше.
3. Wiki )
Более ничего порекоендовать не могу, т.к. это все что читал по теме.

А вообще, перед тем как делать такое колесо, я бы порекомендовал посмотреть готовое. Возьмите хорошо структурированый фреймверк (Zend, symfony, etc) и попробуйте что-то сделать. Для symfony, например, есть такой обучаюший курс Askeet, который очень хорошо помогает понять не только как это работает, но, зачастую, и почему именно так.

solenko, Спасибо! Буду "курить"   (п.с. wiki курю ежедневно)
krundetz, честно говоря сложно пока в шаблонах разобраться (хотя нашёл в книгах паттерны Adapter, Singleton,Factory,Template и др. но понять их смысл не за одни день...наверное это пройдёт со временем/опытом). 


Существенных изменений не будет в диаграмме прецедентов...

Сейчас попробую организовать Диаграммы Классов И возможно если осознаю суть и получитсья Диаграммы Состояний 

Это сообщение отредактировал(а) bobik02 - 2.6.2008, 23:56

bobik02 паттерны вещь такая их надо потрогать и пощупать на собственном опыте и желательно на реальных проектах. У нас в универе курс из 4 семестров по ним был и то понимание многого уже пришло на реальных проектах. Вы пока не пытайтесь применить все паттерны которые есть это в вашей системе не нужно используйте простейшие а уже создав чтото попробуйте сделать её рефакторинг узнаете очень много нового про ООА. Пример как это делаю я приведу обязательно ориентировочно завтра с утра.

krundetz,  Все советы учту!
До завтра

Это сообщение отредактировал(а) bobik02 - 2.6.2008, 23:56

Доброе утро.
Есть некий модуль допустим это простенькая галерея умеющая выводить список файлов которые в ней есть, отображать один файл, загружать файл и удалять файл.
Какие классы у нас есть:
1. GalleryContrloler
Контролирует логику работы модуля. Включает следующие методы:
1.1. __construct() производит вызов нужного метода контролера,
1.2. showImageList() показывает список имеющихся файлов,
1.3. showImage() показывает файл,
1.4. addImage() загружает картинку и показывает форму загрузки,
1.5. deleteImage() удаляет картинку.
2. Gallery
Класс с двумя статическими методами:
2.1. getImageList() возвращает список из картинок,
2.2. getImage() возвращает картинку.
3. Image
Класс модель для картинки. Имеет следующие методы:
3.1. __construct() здесь все понятно,
3.2. getUrl() тоже думаю понятно,
3.3. save() сохраняет картинку,
3.4. delete() удаляет картинку.
Эти классы непосредственно относятся к модулю и лежат в папке модуля.
Для нормальной работы нам нужно также ещё класс Aplication со статическим методом run() и класс который будет разбирать пришедшие параметры обычно его называют Router он будет иметь конструктор в который будут переданы пришедшие параметры обычно url и метод getParam() возвращающий ассоциативный массив из параметров nameModule, action, idImage и т.д.
Далее я приведу только код контролера и класса Aplication.


Забыл сказать что нужны классы представления в частности ImageListView в который мы предаем список картинок и путь к шаблону отображения. Можно обойтись одним классом представления но это сложнее и я так не делаю. Вот собственно опрошенный пример того как у меня работает модуль. Не забывайте про проверке большинство которых я опустил. Также сдесь убрана работа с пользователями и реализация прав доступа.

Это сообщение отредактировал(а) krundetz - 3.6.2008, 11:13

krundetz,  Окончательно меня запутали.   Но Спасибо   
(зато за эти два дня много паттернов узнал, некоторые даже осознал, литературу "поднял")
Пришёл к выводу: Программист сам доходит до основных моментов использования ООП , паттернов и т.к. 

Можно считать вопрос исчерпанным. (так как понял - катастрофически нехватка знаний в ОО подходе, буду "курить" умные книжки)

Посмотрим что с этого получиться   
 

bobik02 бог в помощь.