Какой стиль ООП выбрать?

Question

[homedistiller]

Приветствую всех.
Сразу оговорюсь, не уверен, что то о чем я спрашиваю называется именно стилем.
Ниже представлено 3 примера на PHP, меня интересует какая из реализаций класса для каких целей или в каком контексте предпочтительней, и является ли что-то из нижеперечисленного плохим/хорошим тоном?

$id = 1;

// пример 1
$class = new SomeClass();
$result = $class->setItem($id)->doSomething();

// пример 2
$class = new SomeClass();
$result = $class->doSomething($id);

// пример 3
$class = new SomeClass($id);
$result = $class->doSomething();

Comments

[Сергей delphinpro]

$class = new SomeClass();

уже неправильно
нужно так
$object = new SomeClass();
Вы получаете объект, а не класс.

А всё остальное зависит от типа объекта.
Все три варианта могут и правильными, и нехорошими.

[homedistiller]

Можно примеров, пожалуйста, это для меня самое интересное...

[homedistiller]

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

Комментарии к примерам:
Все три примера делают одно и тоже, различия только в количестве методов и их сигнатурах.
doSomething - просто что-то делает с $id, но во всех примерах - одно и тоже.

1. Сеттер устанавливает внутренний указатель в $id и возвращает свой объект ($this), дальше метод что-то делает с внутренним указателем ($id)

2. Метод что-то делает с переданным аргументом $id

3. Конструктор устанавливает внутренний указатель в $id, дальше как в примере 1.

[synapse_people]

homedistiller,
3 пример описанный вами - пример immutable объекта, то есть 1 объект на 1 айди
2 пример-пример как бы сервисный, mutable
1 пример -тоже как бы сервисный, mutable
Выбор зависит от задачи, но второй пример лучший из представленных

Answer 1

[synapse_people]

пример 2 и только
Обьясню
Например, SomeClass - сервис логгирования.
Тогда сделаем ему интерфейс, создадим 2 подтипа - логер на файлах и в БД.
Итого 1 интерфейс, 2 класса реализации.
Параметры метода описаны в интерфейсе..
Вот и имеем, что метод будет вызван с конкретным аргументом...
В других случаях не понятно поведение подклассов, которые будут это реализовать.. А именно в плане того, что должен делать setItem в 1 случае, и ессно интерфейсы не могут описывать конструкторы как в примере 3...
В итое имеем, что можно легко заменить объект другим объектом ТОЛЬКО в примере 2.
Насчет геттеров - имхо, лучше создавать приватные свойства и геттер+сеттер
Т.к. на больших проектах чаще всего получается лапша, да и в плане многопоточности, и опять же-интерфейсов -просто свойства не есть хорошо...

Answer 2

[Егор]

1. Похож на "рецепт приготовления пирога". Чтобы испечь пирог - сделай а,б,в, .... и положи в печь.
Минусы: вам нужно знать рецепт, какие ингредиенты могут быть, в какой последовательности их класть, и т.д. Это потребует изучение мануалов.

2. Можно использовать, если параметр метода - это некоторое "уточнение" для метода, а не его зависимость.

3. Я использую этот. Небольшие классы, легко тестировать и расширять. В конструкторе необходимо указать тип для параметра. Тогда приготовление пирога сводится к предоставлению определенных зависимостей, и самого процесса "выпечки" (вызова метода).

Comments

[homedistiller]

Правильно ли я понял:

1. Текучий интерфейс, улучшает только читаемость кода, но добавляет проблем с тестированием. Лучше не использовать без особой нужды.

2. Просто набор методов. Что-то передал в качестве аргумента - что-то получил на выходе. Наиболее универсальный способ.

3. Неизменяемый объект. Передаешь что-то при создании и дальше работаешь только с тем, что передал при создании.

А если задать вопрос с другой стороны (функционал). Какие классы конструировать для таких задач:

1. Загрузка данных авторизованного пользователя в посреднике, чтобы в основном коде иметь возможность получить какие-то свойства пользователя.
2. Загрузка данных просто какого-то пользователя для отображения их на странице.
3. Работа с профилем, может быть как собственный так и чужой: создание, обновление, удаление, получение, валидация и т.д.

и пусть все это будет в рамках одного проекта.

[Егор]

1. Я не вижу никакого улучшения читабельности. Теоретически можно выполнять много set-ов в "текучем" интерфейсе. И в конце дойти (неужели) к целевому методу, который выдаст результат.

2. Способ универсальный, но будет много дублирования кода. Что есть зло.

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

Обычно делаю так:
return (new Someclass(new Dependency))->doSomething().

А по поводу того какие классы создавать - то создавать на каждую идентифицируемую тобой сущность.

[homedistiller]

Не понял про второй пункт. Откуда дублирование, можно пояснить?

[Егор]

// пример 2
$class = new SomeClass();
$result = $class->doSomething($id);

Если $id - это зависимость для выполнения обязанностей класса, то для каждого doSomething2($id), doSomething3($id), ... нужно будет передавать в качестве параметра метода. Вместо того, чтобы передать в конструктор класса, и внутри использовать.

$object = new SomeClass($id);
$object->doSomething($id);

Answer 3

[Vitaly]

Вообще забудьте о дополнительном слове get -- это излишество.

1) Всё ок, метод setItem чисто теоретически может возвращать и только что добавленный айтем, тут все зависит от того, как класс используется. Я не знаю можно ли так пхп, но метод может в принципе возвращать и this или ссылку сам на себя. Что может быть использовано для реализации патерна билдер, например.

2) Плохо. Класс должен возврашать хранимый айтем, знать об его внутреннем представлении о каких-то его методах или полях ему совсем не нужно. Вернули айтем, потом у него и спрашивайте данные.

3) Третий пример я не понял. Да, в целом у класса есть какие-то данные, то да, он может их вернуть. Это не проблема.

PS То, о чём вы спрашиваете, называется OOD. К языку программирования это имеет немного отношения.
PPS В следующий раз, задавайте вопросы по какой-нибудь более конкретной модели. Пара-тройка простеньких классов, описывающих, ну там, книжную полку, напрмиер, на которую можно поставить книгу и забрать. Ваш пример слишком абстрактный.

Answer 4

[nozzy]

Пример 1 - такой подход позволяет сократить количество строк кода.

Comments

[BoShurik]

И получить кучу проблем сверху: https://ocramius.github.io/blog/fluent-interfaces-...