здесь есть те кто хорошо шарит в phpunit ?

для написания теста (не совсем юнит) https://toster.ru/q/305584

вот такой примено вопрос

Зачем вообще тестировать интерфейс?

'O2 реализует I2 и O3 реализует I1 и I2 (знаю что плохо и что у объекта должна быть единая ответственность).'

Это как раз нормально

Имплиментация нескольких интерфейсов не обязательно значит нарушение srp

для написания теста (не совсем юнит) https://toster.ru/q/305584

то, что в тестах у тебя возникло дублирование произошло не просто так

а потому что в коде у тебя тоже дублирование

Более того, несколько маленьких интерфейсов как правило лучше чем один большой

а потому что в коде у тебя тоже дублирование

и тут хуяк и наследование в дамках

и тебе надо понять, это реально дублирование, которое надо вынести

я понимаю что несколько интерфейсов лучше

и там пример высосан из пальца

и тебе надо понять, это реально дублирование, которое надо вынести

или это разные проверки и поэтому тебе надо два раза их тестировать

Ты тестируешь логику, а не интерфейсы

я так понимаю что аргументированно поговорить надо более реальный пример?)

и тут хуяк и наследование в дамках

ага, существует ровно один метод избавления от дублирования

я так понимаю что аргументированно поговорить надо более реальный пример?)

Видимо да

ок как нибудь потом набросаю)

вообще я посмотрел есть PHPUnit_Framework_Test (не TestCase)

который можно создавать и передавать туда тестируемый объект и все в ранне потом

но это слишком изврат)

Более того, несколько маленьких интерфейсов как правило лучше чем один большой

+1

+1

-1

Зачем вообще тестировать интерфейс?

сборка класса до обхекта уже тест

Более того, несколько маленьких интерфейсов как правило лучше чем один большой

но разумно иметь структуру

откуда пользователи идут

С севера же

Ты тестируешь логику, а не интерфейсы

ты должен тестировать "контракты". То есть логика, которая формирует интерфейс

и тут хуяк и наследование в дамках

наследование ненужно

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

и без наследования намного проще и чище

наследование ненужно

;)

Без наследования? А почему бы тогда сразу не без классов?

Без наследования? А почему бы тогда сразу не без классов?

ну потому что в PHP это единственный способ описания объектов. А так да, для чистого ООП классы не нужны

достаточно прототипного наследования как в JS

Массивы фигачь

ну потому что в PHP это единственный способ описания объектов. А так да, для чистого ООП классы не нужны

вообще достаточно фабрик и клонирования

но в пхп методы особо не подменишь

Массивы фигачь

just give it a 5 minutes. Попробуй мыслить категорией "наследование не нужно". Представь себе ситуацию где ты бы применил наследование и подумай "а можно ли без него"

ну так

шутки ради

* с помощью композиции например

не только композиции

просто представь что у тебя нет extends, есть только implements для организации иерархии типов

Наследую модели постов и комментариев от эктиврекорда

а.... ну ты проиграл)

и прекрасно себя чувствую

а ты от DDD такой нервный

наверное...

5 лет с доктриной дают о себе знать

привык я что инструменты не заставляют от себя наследоваться

красивенький кстати в opuelence orm

да, мило

да и в целом для "поделки" ооочень качественно

просто представь что у тебя нет extends, есть только implements для организации иерархии типов

Я б повесился

единственное что бесит - венгерская нотация для интерфейсов

Я б повесился

а теперь представь что у тебя нет базы данных, active record, фреймворков и т.д.

мы же сейчас про "правильное ООП" а не про "реалии"

привык я что инструменты не заставляют от себя наследоваться

пф, с aggregate root при event sourcing надо думать как ивенты прятать)

а теперь представь что у тебя нет базы данных, active record, фреймворков и т.д.

Класс

Ничего нет

И код не надо писать

ну тебе ж надо вначале задачу бизнеса решить

Идеально

Я б повесился

ну и опять же, если мы говорим о ActiveRecord - то это, как ты говоришь - классы, тупые структуры, это не ООП"

а не фреймворк выбрать)

так что давай представим себе просто такой код

или всем, кто идет, ты кричишь с порога: "делаю только на laravel/RoR, все остальное нахер, потому что вот так вот"

final class User { /** * @var UserDataModel - Eloqent model */ private $attributes; public function __construct(string $email, sting $password) { $this->attributes->email = $email; $this->attributes->password = $password; } }

вот я тебе сделал "модель" юзера без наследования от элоквента. В ней будет только бизнес логика, а элоквент отвечает только за модель данных

все счастливы

SOLID соблюдается почти

ага, ты только забыл сказать, как она туда сетится))

ага, ты только забыл сказать, как она туда сетится))

ну забыл написать new UserDataModel()

$this->attributes = new UserRowDataGateway();

при фетче - через рефлексию разумеется

че нить такое

ну тип того да