Форум PHP программистов > Помогите разобраться с ООП

acerrusm

16.02.2015 - 04:54

Привет!

Собственно изучаю ООП. Прочитал книгу, посмотрел реализованные примеры с собачками и кошками — вроде понятно. Пришло время применить знания на практике, а именно создать небольшой блог с авторизацией. Но как то дальше UML-диаграммы я не продвинулся т.к. есть сомнения в правильности моего хода мыслей.

Описалово классов:

Posts: это класс записей блога. В нем будут осуществляться sql-запросы, вроде как вытащить все записи и т.д. Также Posts содержит как часть класс Comments.
DB: это класс в котором происходит подключение к БД.

Между Posts и DB существует ассоциативная связь, т.к. Posts ‘пользуется услугами’ класса DB.

User: Класс User является родительским т.к. в блоге могут быть 2 вида пользователей:
Гости (дочерний класс Guest). Гости могут только читать записи, регистрироваться, логиниться и восстанавливать пароль.
Зарегистрированные пользователи (дочерний класс RegisteredUser). Зарегистрированные пользователи же, могут создавать, удалять, менять записи, а также оставлять комментарии под каждой записью.

Сама UML-диаграмма:

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

volter9

16.02.2015 - 05:47

acerrusm
Я думаю что не надо создавать два класса для юзера (не считая родительский класс User), если у них нету своего дополнительного функционала. Можно создать только класс User и в нем хранить его состояние (разрешенные действия/роль, флаг авторизации, доп. инфа) и методы для работы с этим состоянием.

Насчет моделей, Вы писали на CI раньше? Просто такое ощущение что именно из него Вы взяли эту идею что модель это набор методов которые возвращают данные через БД. Этим (возвращением данных) обычно занимается "хранилище", а модель содержит те данные которые вернуло хранилище (ИМХО).

Я думаю именно из за таких примеров (собачки и котики наследуються от класса животных) происходит не полное понимание ООП (ну конечно же практики тоже не хватает).

P.S.: я не профи в ООП, и все что написал это ИМХО и Вам необязательно брать все в учет, может быть кто то чего то более полезного напишет

_____________
Мой блог

chee

16.02.2015 - 10:27

acerrusm, хочешь получить знания проектирования ООП систем, то используй готовую ORM, например Doctrine 2. После того как её осилишь можешь уже и свои велосипеды для работы с базой данных делать.

На счет классов, для незарегистрированых и зарегистрированных пользователей, то идея в духе ООП, но на практике бесполезная, зарегистрированный пользователь от незарегистрированного отличается только ролью.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

stump

16.02.2015 - 13:40

Я думаю что Guest это есть юзер до авторизации. Т.е. класс юзер === guest в модели проектирования. Потом классы Registrined, PasswordRestoration, Loggined это классы которые имеют связи с классом юзер. Db одинаково принадлежит классу юзер и классу пост. Класс комментарии можно унаследовать от юзер потому что юзер делает комментарии и юзера связать с пост потому что юзер пишет пост и коментирует пост тоже юзер.

Ну после перерисовки будет видно что еще не так в этой юмл.

_____________
Трус не играет в хокей

acerrusm

16.02.2015 - 17:31

Цитата (volter9 @ 16.02.2015 - 02:47)

acerrusm
Я думаю что не надо создавать два класса для юзера (не считая родительский класс User), если у них нету своего дополнительного функционала. Можно создать только класс User и в нем хранить его состояние (разрешенные действия/роль, флаг авторизации, доп. инфа) и методы для работы с этим состоянием.

Насчет моделей, Вы писали на CI раньше? Просто такое ощущение что именно из него Вы взяли эту идею что модель это набор методов которые возвращают данные через БД. Этим (возвращением данных) обычно занимается "хранилище", а модель содержит те данные которые вернуло хранилище (ИМХО).

Я думаю именно из за таких примеров (собачки и котики наследуються от класса животных) происходит не полное понимание ООП (ну конечно же практики тоже не хватает).

P.S.: я не профи в ООП, и все что написал это ИМХО и Вам необязательно брать все в учет, может быть кто то чего то более полезного напишет

volter9, дык у класса Guest и RegisteredUser вроде бы разный функционал. Guest например может только читать статьи, а RegisteredUser их изменять. Также Guest может логиниться, регистрироваться и сбрасывать пароль, чего не может делать RegisteredUser. А если все сделать в одном классе, это не будет небезопасно?

Что касается фреймворков, то я пока еще ни с одним не знаком. Думаю, сначала нужно разобраться с ООП, а потом уже и паттерны и фреймворки пойдут.

acerrusm

16.02.2015 - 17:39

Цитата (chee @ 16.02.2015 - 07:27)

acerrusm, хочешь получить знания проектирования ООП систем, то используй готовую ORM, например Doctrine 2. После того как её осилишь можешь уже и свои велосипеды для работы с базой данных делать.

На счет классов, для незарегистрированых и зарегистрированных пользователей, то идея в духе ООП, но на практике бесполезная, зарегистрированный пользователь от незарегистрированного отличается только ролью.

chee, спасибо за ORM – буду читать.

Значит на практике лучше создать только 1 класс для пользователей?

acerrusm

16.02.2015 - 17:47

Цитата (stump @ 16.02.2015 - 10:40)

Я думаю что Guest это есть юзер до авторизации. Т.е. класс юзер === guest в модели проектирования. Потом классы Registrined, PasswordRestoration, Loggined это классы которые имеют связи с классом юзер. Db одинаково принадлежит классу юзер и классу пост. Класс комментарии можно унаследовать от юзер потому что юзер делает комментарии и юзера связать с пост потому что юзер пишет пост и коментирует пост тоже юзер.

Ну после перерисовки будет видно что еще не так в этой юмл.

stump, если сделать Guest === User, и от него наследовать RegisteredUser, то получиться что RegisteredUser унаследует все методы и атрибуты от Guest, например регистрацию и авторизацию. А ведь у RegisteredUser по идее не должно быть доступа к этим методам. Или я торможу?

stump

16.02.2015 - 19:28

Цитата (acerrusm @ 16.02.2015 - 17:47)

Цитата (stump @ 16.02.2015 - 10:40)

Я думаю что Guest это есть юзер до авторизации. Т.е. класс юзер === guest в модели проектирования. Потом классы Registrined, PasswordRestoration, Loggined это классы которые имеют связи с классом юзер. Db одинаково принадлежит классу юзер и классу пост. Класс комментарии можно унаследовать от юзер потому что юзер делает комментарии и юзера связать с пост потому что юзер пишет пост и коментирует пост тоже юзер.

Ну после перерисовки будет видно что еще не так в этой юмл.

stump, если сделать Guest === User, и от него наследовать RegisteredUser, то получиться что RegisteredUser унаследует все методы и атрибуты от Guest, например регистрацию и авторизацию. А ведь у RegisteredUser по идее не должно быть доступа к этим методам. Или я торможу?

User который не воспользовался функциями Registration или Loggined Есть просто User, если воспользовался - Registred/Authorizate User. Программно это не есть разные классы, а есть один класс, а для визио можно воспользоваться флагом, как это предлагал volter9. Проблемма которая заключается в том, что Registred по мнению инкапсуляции воспользоваться функциями registred/login повторно не есть большая проблема. Во первых эти функции не будут доступны в следствии отсутствия таких линков в визио, во вторых если юзер выполнет logout то существует возможность воспользовться функциями registred/login.

Конечно же существует много вариантов реализации авторизации. Как один из вариантов отличных от предложенного мною может быть вариант с применением шаблона фабрика. Такой вариант будет примерно вписываться описываемой вами модели. Используя фабрику класс User будет абстракцией которые будут пораждать классы Guest User, Loggined User, Other User.

Не знаю какой вариант вам подойдет. Однозначно класс Db также должен иметь связь с классом User. Comments логично принадлежит User/LogginedUser имея ссылку к Post, потому что комментарий создает не пост, но пост его содержит.

_____________
Трус не играет в хокей

acerrusm

16.02.2015 - 20:42

Цитата (stump @ 16.02.2015 - 16:28)

Цитата (acerrusm @ 16.02.2015 - 17:47)

Цитата (stump @ 16.02.2015 - 10:40)

Я думаю что Guest это есть юзер до авторизации. Т.е. класс юзер === guest в модели проектирования. Потом классы Registrined, PasswordRestoration, Loggined это классы которые имеют связи с классом юзер. Db одинаково принадлежит классу юзер и классу пост. Класс комментарии можно унаследовать от юзер потому что юзер делает комментарии и юзера связать с пост потому что юзер пишет пост и коментирует пост тоже юзер.

Ну после перерисовки будет видно что еще не так в этой юмл.

stump, если сделать Guest === User, и от него наследовать RegisteredUser, то получиться что RegisteredUser унаследует все методы и атрибуты от Guest, например регистрацию и авторизацию. А ведь у RegisteredUser по идее не должно быть доступа к этим методам. Или я торможу?

User который не воспользовался функциями Registration или Loggined Есть просто User, если воспользовался - Registred/Authorizate User. Программно это не есть разные классы, а есть один класс, а для визио можно воспользоваться флагом, как это предлагал volter9. Проблемма которая заключается в том, что Registred по мнению инкапсуляции воспользоваться функциями registred/login повторно не есть большая проблема. Во первых эти функции не будут доступны в следствии отсутствия таких линков в визио, во вторых если юзер выполнет logout то существует возможность воспользовться функциями registred/login.

Конечно же существует много вариантов реализации авторизации. Как один из вариантов отличных от предложенного мною может быть вариант с применением шаблона фабрика. Такой вариант будет примерно вписываться описываемой вами модели. Используя фабрику класс User будет абстракцией которые будут пораждать классы Guest User, Loggined User, Other User.

Не знаю какой вариант вам подойдет. Однозначно класс Db также должен иметь связь с классом User. Comments логично принадлежит User/LogginedUser имея ссылку к Post, потому что комментарий создает не пост, но пост его содержит.

Похоже по тихоньку начинаю въезжать, спасибо!

stump

16.02.2015 - 21:22

Советую на досуге обратиться к материалы по разработке на основе предметной области и разработке посредством тестирования (DDD и TDD соответственно).

_____________
Трус не играет в хокей

NitroGenerate

27.02.2015 - 12:39

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

class userModel
{
    public $id_user;
    public $name;
    public $email;
    public $role;
    
    public function __construct($id_user = false)
    {
        // если есть id пользователя, то моделируем его.
        if ($id_user) {
            // database ...
            //// $this->id_user = $dbRes['id'];    
            //// $this->name = $dbRes['name'];
            //   //... 
        }
    }
    
    public function isGuest()
    {
        return empty($this->id_user);
    }
}