парни можете объяснить вот это утверждение

"Обилие же композиции говорит о нарушении Принципа Инверсии Зависимостей, сформулированном Бобом Мартином, которую сейчас можно выразить в терминах агрегации и композиции: предпочитайте агрегацию вместо композиции, поскольку первая стимулирует использование абстракций, а не конкретных классов."

ну в целом да

разницу между агрегацией и композицией знаешь?)

да знаю

плюс агрегации что объект приходит извне

и соответственно может быть подменен если у тебя там solid

и принцип лисков

соблюдается

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

и соответственно инверсии зависимостей

хм ну да выходит так

ну ты про фабрику правильно написал

вон в ларавел вместо фабрик фасады

а внутри фасадов di

просто лазить по приложению и править фабрики это то еще занятие

и на лету их сложно менять

ну да вот я поэтому и удалил сообщений)

"Обилие же композиции говорит о нарушении Принципа Инверсии Зависимостей, сформулированном Бобом Мартином, которую сейчас можно выразить в терминах агрегации и композиции: предпочитайте агрегацию вместо композиции, поскольку первая стимулирует использование абстракций, а не конкретных классов."

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

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

у нас тоже

конфигурация DI распухает, ее становится сложно поддерживать

совсем упарываться DI тоже не стоит

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

такие правила)

ну вот да

это уже наркомания какая-то

а вообще что вы понимаете под словом сервис? имею ввид не приложение а именно сервис как класс

state less

imutable

то есть по сути то что можно заменить статическим классом?)

ну надо пихать зависимости туда будет

например А использует сервис С

С зависит от Б

если ты заменишь С на статический класс

то А будет зависеть от Б

если тебя такое устрайвает то заменяй)

С зависит от Б

вот важный момент, помоему сейчас слово сервис эквивалентно слову зависимость

ну весь код это один комок зависимостей

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

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

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

есть чистая функция

есть на основе неё частично карированные функции

но это фп

и тут я не силен

как и в ооп

я силен в КОП (Костыльно ориентированном программирование)

частично каррированная - это как?) половина переменной передана? )

полтора землекопа?

add(a, b) { return a + b; } addFive(a) {return add(5, a);}

грубо говоря вот это карирование, но в фп есть свои штуки

это каррирование

синтаксис и тд

частичное

что значит частичное?

в книге вычитал

частичное применение вроде

может ты путаешь с partial application?

вот да

я в голове понимаю как это а все эти термины не запоминаю)

ERROR: S client not available

Есть интерфейс SshClient с одним методом выполнения удалённой команды execute($cmd) и дефолтная реализация DefaultSshClient с опциями подулючения в конструкторе. Для логгирования выполняемых команд сделал декоратор LoggingSshClient. Есть проблемы с DNS resolution при запросах, добавил ещё один декоратор DnsFailureSafeSshClient. Теперь понадобилось конфигурировать для всех SshClient путь к бинарнику ssh в одном месте, сделал DefaultSshClientFactory с путём в конструкторе. Вот теперь для остальных SshClient мне тоже фабрики делать?

много классов получается, может как-то попроще можно?

Есть интерфейс SshClient с одним методом выполнения удалённой команды execute($cmd) и дефолтная реализация DefaultSshClient с опциями подулючения в конструкторе. Для логгирования выполняемых команд сделал декоратор LoggingSshClient. Есть проблемы с DNS resolution при запросах, добавил ещё один декоратор DnsFailureSafeSshClient. Теперь понадобилось конфигурировать для всех SshClient путь к бинарнику ssh в одном месте, сделал DefaultSshClientFactory с путём в конструкторе. Вот теперь для остальных SshClient мне тоже фабрики делать?

Если ты можешь переиспользовать клиент то лучше его инжектить с помощью какого нибудь контейнера, хз есть ли такое в php

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

сейчас $factory->createClient($options)->execute($command);

в разных местах мне нужно логгировать запросы

или проблема с днсами тоже не везде

то есть $factory в разных местах разная

а вот конфигурирование где какая фабрика идёт через DIC

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

не знаю, правильно ли так, но сделал декорацию фабрик

https://gist.github.com/Romashka/a758a85462e29d0a0d372f43ceef9df2

Есть интерфейс SshClient с одним методом выполнения удалённой команды execute($cmd) и дефолтная реализация DefaultSshClient с опциями подулючения в конструкторе. Для логгирования выполняемых команд сделал декоратор LoggingSshClient. Есть проблемы с DNS resolution при запросах, добавил ещё один декоратор DnsFailureSafeSshClient. Теперь понадобилось конфигурировать для всех SshClient путь к бинарнику ssh в одном месте, сделал DefaultSshClientFactory с путём в конструкторе. Вот теперь для остальных SshClient мне тоже фабрики делать?

Я бы выделил подмодули типа Executor или DnsResolver, передавал бы их в клиент как зависимости. И был бы у меня LoggingExecutorWrapper implements Executor и какой-нить FallbackChainDnsResolver implements DnsResolver.

Я бы выделил подмодули типа Executor или DnsResolver, передавал бы их в клиент как зависимости. И был бы у меня LoggingExecutorWrapper implements Executor и какой-нить FallbackChainDnsResolver implements DnsResolver.

А как же принцип не создавать классы с именами оканчивающимися на or и er?

А как же принцип не создавать классы с именами оканчивающимися на or и er?

Источник?

https://www.amazon.com/Elegant-Objects-1-Yegor-Bugayenko/dp/1519166915

А как же принцип не создавать классы с именами оканчивающимися на or и er?

Ну предложи свой вариант

Logging implements ExecutorInterface ну и FallbackChain implements DnsResolverInterface

нет окончаний на or и er

эксперт по костылям

http://cs4.pikabu.ru/post_img/2016/08/01/7/147004996416599702.jpg

https://www.amazon.com/Elegant-Objects-1-Yegor-Bugayenko/dp/1519166915

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

Logging implements ExecutorInterface ну и FallbackChain implements DnsResolverInterface

Ну не буквально, здесь всё равно есть окончания кроме FallbackChain

есть еще хороший принцип включать голову, когда следуешь принципам

а еще лучше не выключать голову))

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

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

вот этим чувакам расскажи, они походу не в курсе https://github.com/unclebob/fitnesse/tree/master/src/fit

вот этим чувакам расскажи, они походу не в курсе https://github.com/unclebob/fitnesse/tree/master/src/fit

or er это признак того что обьект не сущность, а часть поведения которая должна быть в каком то другом обьекте. Конечно есть и исключения.

DnsResolverInterface к примеру это часть поведения которая должна быть в классе Dns