Он конечно реализует

??

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

Он конечно реализует

а ContainerInterface хорошее название для интерфейса?

а ContainerInterface хорошее название для интерфейса?

Да. Почему нет?

аче не просто Container?

я завел любимую шарманку :))

аче не просто Container?

А реализация Container

а почему? она одна чтоли такая?

реализация

а ContainerInterface хорошее название для интерфейса?

Не не не ContinerContract же)

Не не не ContinerContract же)

ну это ужсовсем идеал

Как по мне более очевидно когда зависишь от SomeInterface

А не от Some

Как по мне более очевидно когда зависишь от SomeInterface

почему?

почему?

Субъективно

А почему нет?

Не не не ContinerContract же)

хоть убейте, не понимаю, чем контейнерКонтракт лучше контейнерИнтерфейс

тебе не кажется такойкод __construct(Logger $logger, Container $container) гораздо более натуральным?

А если у тебя ерп система, интерфейс для контрактов буде контракконтрак?

хоть убейте, не понимаю, чем контейнерКонтракт лучше контейнерИнтерфейс

сарказм был) про излишество приставок таких

тебе не кажется такойкод __construct(Logger $logger, Container $container) гораздо более натуральным?

Возможно я привык.

А по поводу LogManager - всегда думал что правильно юзать аджекты вроде Loggable, не?

ну если закрыть глаза на пср

Ужас

Возможно я привык.

Кароч Леха молодец. мне нравится как он мыслит :)

А тебе не казалось что композиция лучше наследования?

Кароч Леха молодец. мне нравится как он мыслит :)

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

Код быстрее читать что ли

Особенно когда у тебя по 5 пулл реквестов на ревью

Сразу видно что челик подсунул реализацию

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

суффикс Interface дает плодить чушь типа class Logger implements LoggerInterface. т.е. как бы дефотная реализация этого интерфейса. а у интерфейса не должно быть дефолтной реализации

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

суффикс Interface дает плодить чушь типа class Logger implements LoggerInterface. т.е. как бы дефотная реализация этого интерфейса. а у интерфейса не должно быть дефолтной реализации

Так такого и не делаем.

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

А если пишем?

если пишем, то это довольно быстро выяснится...

А по поводу LogManager - всегда думал что правильно юзать аджекты вроде Loggable, не?

LogManager потому-что некотрые типы логером не все умеют и иногда появлятся LogWritter и LogReader а LogManger используит их

LogManager потому-что некотрые типы логером не все умеют и иногда появлятся LogWritter и LogReader а LogManger используит их

LogReader...хмммм

LogReader...хмммм

Интерфейс ReaderInterface :)

А тебе не казалось что композиция лучше наследования?

все зависит от конкретной ситуации

не фанат тупой мантры предпочтения первого второму

все зависит от конкретной ситуации

С тобой не о чем говорить. Все стало на свои места.

Тебе никакой аргумент не аргумент. Потому что компетенция очень низкая.

Реализация не должна практически никогда интересовать

Реализация не должна практически никогда интересовать

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

и моментально все решили что абстракция это интерфейс...

Реализация не должна практически никогда интересовать

значит ли это, что для каждый-каждый класс должен реализовавывать какой-либо интерфейс?

Нет конечно

значит ли это, что для каждый-каждый класс должен реализовавывать какой-либо интерфейс?

Нет

ну сущности понятно что нет

всякие VO тоже.. DTO..

но все stateless видимо должны...

иначе как их просить...

ынтерфейс нужон

но все stateless видимо должны...

А почему нет?

и моментально все решили что абстракция это интерфейс...

И когда увидят Руби к примеру, то скажут там D не возможно, потому что нет интерфейсов

а абстрактные классы есть?

а абстрактные классы есть?

их тоже не любят.

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

а не интерфейсом

ибо когда логгер это абстрактный класс - это есть принуждение к композиции

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

а не наоборот ли?

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

Ты про трейты?

нет

от абстрактного класса наследование ведь?

от абстрактного класса наследование ведь?

ну мы наследуем не реализацию какуюто.. а просто фактически исполняем контракт

тоже самое что и интерфейс

ERROR: S client not available

наследование плохо тогда когда мы наследуем чтото.. чохотим юзать

С тобой не о чем говорить. Все стало на свои места.

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

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

а каких случаях наследование лчше композиции?

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

А когда ты используешь наследование?

ну мы наследуем не реализацию какуюто.. а просто фактически исполняем контракт

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

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

тогда это плохое наследование :)

однако зачем делать наследование, если можно использовать иплементацию? в чем профит от абстрактного класса я чет вообще не понял?

однако зачем делать наследование, если можно использовать иплементацию? в чем профит от абстрактного класса я чет вообще не понял?

Я так понимаю он о том что зачастую одна реализация

однако зачем делать наследование, если можно использовать иплементацию? в чем профит от абстрактного класса я чет вообще не понял?

class CoolLOgger extends AnotherLOgger implements LoggerInterface

а, с точки зрения нейминга, ну тут да, возможно

не уловил суть )

c абстрактным классом Logger такой плохой фокус не провернешь

class CoolLOgger extends AnotherLOgger implements LoggerInterface

ну явно не coolloger :)

он бы принудил к композиции

А когда ты используешь наследование?

когда есть явная связь с предком и наследник явно повторяет все методы базового класса. Машина, электромобиль

с чего бы? можно ведь просто наследоваться от AnotherLOgger, который уже унаследован от абстрактного логгера

+ явные примеры из всяких видов, подвидов. Насекомое, муха. ну если упрощенно

А зачем мухе отдельный тип? Это ведь по сути насекомое со своими свойствами

явные примеры подмножест геометрических фигур? прямоугольник, квадрат? :trollface:

И можно построить композицию

И можно построить композицию

нука нука, как?)

А если произойдет мутация мухи в муху БОльшим размером и 3 глазами?

Снова наследовать муху?

подожди, не уходи пожалуйста от ответа

композируй, если не трудно, этот пример

насекомое - муха

Набор свойств - отдельные реализации для каждого.

Набор свойств - отдельные реализации для каждого.

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

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

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

а как же полиморфизм?

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

Что конкретно?

а как же полиморфизм?

Погоди. Ещё не добрались.