Как лучше реализовать код?

Question

[Дмитрий Б]

Доброго времени суток. Я учусь грамотно использовать ООП для гибкости кода, возможности расширения в будущем. Подскажите пожалуйста:
Мой скрипт на основе шаблонов периодически создаёт задачи с помощью метода Tasks::createTask(). У каждой задачи задачи есть подзадачи. Они могут создаваться как сразу при создании основной задачи, так и постепенно добавляться через некоторое время. В каком месте кода их лучше создавать?

1 Вариант:
Создавать подзадачи в методе создания основных задач

class Subtasks
{
    public function createSubtasks()
    {
        // ...
    }
}

class Tasks
{
    public function createTask($params = array())
    {
        // Код создания основной задачи...
        $newTaskId = '...';
        
        
        // Создание подзадачи
        if ($params['create_subtasks'])
        {
            $Subtasks = new Subtasks;
            $Subtasks->createSubtasks($newTaskId);
        }
        
    }
}

2 Вариант
Создавать подзадачи в контроллере
Например так:

$Tasks = new Tasks;
$Subtasks = new Subtasks;
$Tasks->createTask();
$Subtasks->createSubtasks($Tasks->getNewTaskId());

Второй вариант с одной стороны мне кажется более гибким и меньше связывает Tasks и Subtasks, с другой стороны это не очень удобно и если что-то поменяется, то придётся везде переписывать вызов метода создания подзадач.
Как бы сделали вы? Спасибо

Answer 1

[Дмитрий Энтелис]

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

Comments

[Дмитрий Б]

То есть второй вариант, спасибо!

[Дмитрий Б]

Или вы имели ввиду вот эту часть кода
$Tasks->createTask();
$Subtasks->createSubtasks($Tasks->getNewTaskId());
переместить в отдельный класс и вызывать?

[Дмитрий Энтелис]

@PiloTeZ да, переместить в отдельный класс

[Дмитрий Б]

@DmitriyEntelis спасибо

[Сергей Протько]

@DmitriyEntelis зачем плодить лишние сущности? А если потом нужно будет добавить логику переноса подтасков как отдельные таски (мало ли)? Придется писать логику которая будет переделывать тип записи?

Answer 2

[Сергей Протько]

$taskManager = new TaskManager(); // вынести инстанцирование во вне а еще лучше использовать DI
// таск есть таск, имеет он при себе родителя или нет
// по сути у нас обычное дерево
$parentTask = new Task();
$subTask = new Task($parentTask);
$subSubTask = new Task($subTask);
// вся логика по сохранию тасков инкапсулируется в менеджер тасков
$taskManager->addTask($parentTask);
$taskManager->addTask($subTask);
$taskManager->addTask($subSubTask);

Если используете Doctrine в качестве ORM, то в менеджере вы должны делать только persist записи. flush в идеале должен быть только один (коммит транзакции), и желательно его делать в каком-нибудь так же даже не в контроллере, а сделать глобальный обработчик, мол если у нас не возникло ошибок во время обработки http запроса - делаем flush. Таким образом мы никогда не забудим закоммитить изменения в базу.

Comments

[Дмитрий Б]

Спасибо большое ) Отличное решение, плюс помогло поправить другую проблему! Использую Yii, там своя ORM.

[Дмитрий Б]

Что такое DI?

[Сергей Протько]

@PiloTeZ Ух... Yii это не тот фреймворк на котором надо тренироваться писать гибкий и расширяемый код. В контексте Yii я бы порекомендовал вам посмотреть в сторону DTO (Data Transfer Objects), хотя это в большинстве случаев избыточно, зато позволяет полностью отвязать ваши сущности от ActiveRecord, что может пригодиться при возникновении необходимости использовать другие хранилища.

DI - Dependency Injection. В Yii2 вроде что-то смутно напоминающее DI контейнер уже ввели. Вообще почитайте в сети информацию по принципу инверсии зависимостей.

[Дмитрий Б]

@Fesor подскажите пожалуйста фреймворк, на котором лучше было бы писать сайт. Сайт - агрегатор. Будет крупный скрипт парсинга данных. Мне казалось Yii хороший выбор.

[Сергей Протько]

Скрипт парсинга не зависит от фреймворка, во всяком случае не должен. В контексте задачи yii норм

[Дмитрий Б]

@Fesor я имел ввиду, что бы проще было проект масштабировать, писать качественно. Спасибо за помощь )

[Сергей Протько]

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