Больше сущностей богу сущностей?

"правильный" ООП вообще подразумевает сущность на действие, много мелких объектов. Но "правильный" ООП не нужен в реальном мире, разве что Егору Бугаенко нужен, но это особый случай.

"правильный" ООП вообще подразумевает сущность на действие, много мелких объектов. Но "правильный" ООП не нужен в реальном мире, разве что Егору Бугаенко нужен, но это особый случай.

Как одепт правильного ооп скажи где должен быть метод писать, в объекте ручка или в объекте рука?

Ооппа, срачик

Бред. Пока только одна реализация изменения элементарные. При появлении второй сделать и заменить тайпхинт на интерфейс тоже элементарно.

у меня нет желания спорить поочевидным вещам, бред это то, о чем ты говоришь. Нет понятия "пока одна реализация". Это не одна реализация, а говнокод по определению.

Господа, ответьте же на мой вопрос, какое из зол выбрать? Нарушать DIP и порождать тысячи интерфейсов?

dypa ты где?

Господа, ответьте же на мой вопрос, какое из зол выбрать? Нарушать DIP и порождать тысячи интерфейсов?

То, которого требует бизнес

Как одепт правильного ооп скажи где должен быть метод писать, в объекте ручка или в объекте рука?

Я пишу на golang большую часть времени, а последнее время использую scala, java была не долго, но уже забываю о ООП и тем более адептом никогда небыл...

Но при этом топишь за интерфейсы везде.

Ок.

То, которого требует бизнес

Бизнесу всё равно как я это буду реализовывать, вопрос сугубо проффесиональный

Но при этом топишь за интерфейсы везде.

интерфейс -это контракт и с точки зрения проектирования и безнес задачи -это главное. Реализация никому не интересна, поскольку требования окружения могут менять и должны меняться. Нельзя проектировать завязываясь на реализации -это изначально только видимость решения

Но при этом топишь за интерфейсы везде.

Я во многом с ним согдасен, это стабильность и порядок, но как по мне цена высока

интерфейс -это контракт и с точки зрения проектирования и безнес задачи -это главное. Реализация никому не интересна, поскольку требования окружения могут менять и должны меняться. Нельзя проектировать завязываясь на реализации -это изначально только видимость решения

Т.е. всё таки плодить интерфейсы?

Т.е. всё таки плодить интерфейсы?

а какие есть аргументы против?

Если следовать этому правилу - придётся для каждого класса заводить интерфейс

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

а какие есть аргументы против?

Количество файлов и кода удваивается , мне как разрабу вдвое больше работы

в той же java всегда были для слоя моделей DAO слои, где интерфейс на каждый класс, и ничего -работает. Код передается по наследству и успешно живет в проде под огромными нагрузками

Количество файлов и кода удваивается , мне как разрабу вдвое больше работы

Генераторы напиши. Разраб!

Хххех

Количество файлов и кода удваивается , мне как разрабу вдвое больше работы

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

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

Как это не прескорбно, но я с вами согласен

но да это печально, мне самому больно смотреть на java проекты иногда, когда эти слои DAO просто обмазанны интерфейсами и классами с одним методом (UserDao / UserDaoImpl и т.д.). Но этот метод работает. Иначе как только проект выростает, документация теряется, а разраб увольняется -начинаются срочные задачи и даже те, кто хотели бы учесть все при внесении изменений -просто физически не могут это сделать

Солюшен - говнокод, как всегда

но да это печально, мне самому больно смотреть на java проекты иногда, когда эти слои DAO просто обмазанны интерфейсами и классами с одним методом (UserDao / UserDaoImpl и т.д.). Но этот метод работает. Иначе как только проект выростает, документация теряется, а разраб увольняется -начинаются срочные задачи и даже те, кто хотели бы учесть все при внесении изменений -просто физически не могут это сделать

Давайте в контсексте PHP Как вам такой пример из ядра? http://php.net/manual/ru/datetime.settimezone.php public DateTime::setTimezone ( DateTimeZone $timezone ) Здесь DateTimeZone - имя класса, а не интерфейса, почему так? Ведь это ядро языка Выходит ядро PHP нарушает SOLID ??

Солюшен - говнокод, как всегда

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

Выходит ядро PHP нарушает SOLID ?

Давайте в контсексте PHP Как вам такой пример из ядра? http://php.net/manual/ru/datetime.settimezone.php public DateTime::setTimezone ( DateTimeZone $timezone ) Здесь DateTimeZone - имя класса, а не интерфейса, почему так? Ведь это ядро языка Выходит ядро PHP нарушает SOLID ??

Потому что "крайности - это путь ситхов"

Но я тоже нифига не джедай

Артём, интересно услышать ваш ответ

Я точно знаю что не каждому классу необходим интерфейс. Но почему? Думаю Артем в курсе

Выходит ядро PHP нарушает SOLID ?

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

Выходит ядро PHP нарушает SOLID ?

Если ты подробно прочитаешь что написано в принципе D, то ты там не найдешь в упор правила что каждый класс обязан имлементировать интерфейс

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

пхп реализован на Си, там нет ООП и проектировали его слишком давно)

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

Почему же, а если я захочу пробросить туда не нативный DateTimeZone, а свой?

Почему же, а если я захочу пробросить туда не нативный DateTimeZone, а свой?

тогда проще просто заменить заголовочный файл в Си

пхп реализован на Си, там нет ООП и проектировали его слишком давно)

Т.е. если бы его проектировали сейчас, то там был бы указан интерфейс, а не класс?

смотря кто и как бы его писал, все дело в том, что инструменты на которых написан пхп не поддерживают ООП от природы

это же просто методика, если мы решаем задачи в стиле ООП то должны следовать принципам, поскольку они проверенны и доказанны

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

ООП -это проектирование продукта пользователем котрого будет програмист расширяющий функционал

Давайте в контсексте PHP Как вам такой пример из ядра? http://php.net/manual/ru/datetime.settimezone.php public DateTime::setTimezone ( DateTimeZone $timezone ) Здесь DateTimeZone - имя класса, а не интерфейса, почему так? Ведь это ядро языка Выходит ядро PHP нарушает SOLID ??

код работает с конкретной реализацией, в чем проблема?

Давайте в контсексте PHP Как вам такой пример из ядра? http://php.net/manual/ru/datetime.settimezone.php public DateTime::setTimezone ( DateTimeZone $timezone ) Здесь DateTimeZone - имя класса, а не интерфейса, почему так? Ведь это ядро языка Выходит ядро PHP нарушает SOLID ??

а еще нужно понимать, что php пишут очень разные люди

Если ты подробно прочитаешь что написано в принципе D, то ты там не найдешь в упор правила что каждый класс обязан имлементировать интерфейс

Конечно, правило звучит совсем иначе, но практическая раелизация вынуждает каждый мой класс имлементировать интерфейс

Конечно, правило звучит совсем иначе, но практическая раелизация вынуждает каждый мой класс имлементировать интерфейс

Нет не вынуждает, читай формулировку D пока не поймешь.

интерфейс != абстракция

да и вообще там же :: это же доступ к статикам и константам, а статиков в правильном ООП просто нет ))

интерфейс != абстракция

А что же это тогда?

а еще нужно понимать, что php пишут очень разные люди

Привет WP)))

да и вообще там же :: это же доступ к статикам и константам, а статиков в правильном ООП просто нет ))

Как и правильного ООП нет

Как и правильного ООП нет

с этим никогда не спорил и всегда говорил, что Егор просто белку поймал)

да и вообще там же :: это же доступ к статикам и константам, а статиков в правильном ООП просто нет ))

Я не юзаю, кстати

А что же это тогда?

Абстракция - это то что ты сам в архитектуре выделил как абстракцию. Это может быть интерфейс, а может быть набор интерфейсов/классов какой-то.

Привет WP)))

важнее ляпнуть любую глупость - лишь бы публично...

И принцип D нигде не требует чтобы у тебя каждый чих был абстракцией.

Ну класс - это абстракция по сути

Абстракция это абстрактное понятие

Это не настоящая вещь

А лишь проекция

Которое абстрагировано от класса, интерфейса, абстрактного класса.

важнее ляпнуть любую глупость - лишь бы публично...

Прости мои слабости

И принцип D нигде не требует чтобы у тебя каждый чих был абстракцией.

Вот, что мне говорит правило DIP

ПЛОХО class A {} class B { public function method(A $arg) { ... } } ХОРОШО AInterface {} class A implements AInterface {} class B { public function method(AInterface $arg) { ... } }

Вот, что мне говорит правило DIP

Нет, оно ничего подобного не говорит.

php: str_replace() python: str.replace()

Оно говорит ровно то что говорит - про абстракции, а не про код.

ПЛОХО class A {} class B { public function method(A $arg) { ... } } ХОРОШО AInterface {} class A implements AInterface {} class B { public function method(AInterface $arg) { ... } }

не обязательно, если у тебя есть поддержка множественного наследования или класс А -это трейт, то первый варик сойдет) объекты то максимально мелкие должны быть

ПЛОХО class A {} class B { public function method(A $arg) { ... } } ХОРОШО AInterface {} class A implements AInterface {} class B { public function method(AInterface $arg) { ... } }

И это вынуждает меня плодить абстракции будь-то интерфейсы или абстрактные классы

Если ты в архитектуре мыслишь о таблице class Table со строками class Row и объявил что у тебя тут нет никаких абстракций, то и принцип D тут не применим.

не обязательно, если у тебя есть поддержка множественного наследования или класс А -это трейт, то первый варик сойдет) объекты то максимально мелкие должны быть

В PHP нет множественного наследования

В PHP нет множественного наследования

Шта?

В PHP нет множественного наследования

да пхп и без этого досталось) но трейты есть

Шта?

Множественного наследования классов

да пхп и без этого досталось) но трейты есть

Трейты - лютый костыль

Ну как бэ в JS одни трейты

Речь о PHP

Множественного наследования классов

Есть цепочкой

Трейты - лютый костыль

трейты отлично работают, но я понятия не имею что там в пхп с ними

Есть цепочкой

Вы о пра-родителях?

Короче, репозиторий работает только с одной моделью, думаю поэтому там не интерфейс

Если ты в архитектуре мыслишь о таблице class Table со строками class Row и объявил что у тебя тут нет никаких абстракций, то и принцип D тут не применим.

Не свосем понял, поясните

Вы о пра-родителях?

он не шарит... нет множественного

Не свосем понял, поясните

Принцип D говорит об абстракциях и зависимостях, он не говорит о классах и интерфейсах )

Что дает тебе свободу интерпретации

Вот почитай что пишут умные диванные аналитики https://softwareengineering.stackexchange.com/questions/317371/should-every-class-i-write-adhere-to-an-interface

Есть цепочкой

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

Принцип D говорит об абстракциях и зависимостях, он не говорит о классах и интерфейсах )

Если полистать примеры, всё, что касается правила DIP сводится к интерфейсам

Не встречал, чтобы кто-то решал это в PHP чем-то ещё

Если полистать примеры, всё, что касается правила DIP сводится к интерфейсам

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

там все сводится к тому, что если нужно свапать реализацию, то используем интерфейс, но прикол в том, что если мы пилим не свой проект по выходным, а работаем по найму, то априори должны писать код, в котором в конце концов кто -то изменит реализацию. Такова она работа по найму

> в конце концов кто -то изменит реализацию Такого не бывает ни с того ни с сего. И до тех пор пока не понадобилось, плодить интерфейсы есть зло и нарушение принципов KISS/YAGNI

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

Для меня класс - это не абстракция, а конкретная реализиция, абстракция же - это интерфейс или на крайняк - абстракный класс.

Для меня класс - это не абстракция, а конкретная реализиция, абстракция же - это интерфейс или на крайняк - абстракный класс.

или я не прав?

Но есть класс Animal, и есть Dog и Cat, которые его расширяют. Метод принимает Animal. Подойдут ли Dog или Cat?