Как правильно реализовать инверсию зависимостей в PHP?

Question

[Тарас Сереванн]

Допустим, есть проект -- обертка над API соц. сети. В нем есть класс Wall (для работы со стеной пользователя) и класс Post (содержит данные поста, их геттеры/сеттеры и другие методы).

Класс Wall:

class Wall
{
    public function addPost($text) 
    {
        ... // какие-то действия
        return new Post($id, $text);
    }

    public function getLastPost()
    {
        ... // какие-то действия в результате которых мы можем:
        return new Post($last['id'], $last['text']);
    }

    // предположим, метод, который делает репост или другие действия, не суть
    public function repost(Post $post) 
    {
        ... $post->getId() ...
        ... $post->toString() ...
        .... // ещё какие-то действия с объектом 
    }

Класс Post:

class Post
{
    ... // переменные/поля
    ... // геттеры/сеттеры
    ... // toString и другие связанные методы
}

При этом видно, что класс Wall очень тесно связан с классом Post (особенно там, где создаются новые экземпляры в классе Wall) и это не соответствует SOLID и в частности принципу инверсии зависимостей.

Как ослабить связь между классами и сделать их более переносимыми и SOLIDными? И нужно ли это делать в такой ситуации? У меня в принципе есть идеи, но, уверен, есть какой-то изящный паттерн, который решит все мои проблемы и о котором я пока не знаю.

Answer 1

[Кирилл Несмеянов]

Указывать не объект, а его интерфейс. В данном случае там три метода - getId, toString и __construct. Этого будет достаточно для начала.

P.S.
По-хорошему ещё надо избавляться от id, т.к. это поле относится к реализации, а не к логике. Все полученные посты из какого-либо стораджа будут его иметь, а новосозданным постам знать о его существовании не обязательно. Т.е. примерно так должно получиться:

interface Post
{
    public function __construct(string $content, User $user);
    public function getContent() : string;
    public function getUser() : User;
    public function changeAuthor(User $user);
}

class WallPost implements Post
{
    ... implement methods
}

В таком случае у любых постов будет лишь автор и содержание, а остальное уже тонкости реализации, т.к. id нужен лишь для БД, что бы связать юзера с постом.

Но это всё уже немного другая история (см. предметно-ориентированное программирование).

P.P.S. На счёт сеттеров я бы поспорил. Предлагаю посмотреть вот эту https://habrahabr.ru/post/279919/#comment_8816651 ветку комментариев, где Сергей мне доступно объяснил по поводу их нужности и я вынужден с этим согласиться, ибо иммутабельность данных - это хорошо.

Comments

[Тарас Сереванн]

Но ведь в коде всё равно нужно будет писать new WallPost(..) ?

[Кирилл Несмеянов]

Тарас Сереванн: не обязательно: php.net/manual/ru/reflectionclass.newinstancewitho...

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

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

[Кирилл Несмеянов]

Тарас Сереванн: но на всякий случай повторюсь - наша беседа в комментариях не сильно относится к поставленному вопросу. Это лишь совет как ещё можно упростить\улучшить взаимодействие объектов, сделав их чище и меньше завязанными на реализацию самой БД.

P.S.
new WallPost конечно нужно будет писать, но только тогда, когда нам нужно будет создать новый объект, а не получить уже существующий в БД.

Answer 2

[Юрий]

помоему вы не туда ушли.
идеал - не то что два класса никак не связаны. классы всегда будут связаны.
то что вы сущности post создаете в сервисе это норма. все равно при расширении вы будете просто добавлять туда новые свойства и геттеры/сеттеры. вы же не будете расширять post наследованием?

либо создайте отдельный сервис фабрику для постов и создавайте в ней. PostFactory::createPost()
а в Wall классе считайте что работаете с обьектом наследующим PostInterface.
только в таком случае вы по нормальному используете только те геттеры/сеттеры которые указаны в PostInterface.

в общем вопрос только зачем вам хочется абстрагироваться от Post ?

Comments

[Тарас Сереванн]

Я просто хочу научиться делать правильно.

Описанный в топике проект, конечно же, вымышленный.