а чем глупость с " Interface, Contract, Initialize" отличается от неглупости с "Controller" ?)

а расскажи как ты именуешь классы у себя на преокте? контроллеры те же. репозитории и т.д.

а чем глупость с " Interface, Contract, Initialize" отличается от неглупости с "Controller" ?)

вопрос семантики. Добавление Interface не влияет на семантику и наоборот ухудшает ее. А MerchantController например имеет вполне конкретную семантику

Все эти служебные Interface, Contract, Initializer - это да. глупость. А вот с Controller - почему нет? С эксепшенами... ну спорненько.

он там приводит кейсы где добавление суффиксов Error или Exception это норм, ибо без этого теряется смысл

он там приводит кейсы где добавление суффиксов Error или Exception это норм, ибо без этого теряется смысл

уговорил. гляну :)

Все эти служебные Interface, Contract, Initializer - это да. глупость. А вот с Controller - почему нет? С эксепшенами... ну спорненько.

https://youtu.be/ZsHMHukIlJY?t=29m19s Вот например, можно убрать слово Exception из наименования, допустим есть OverflowException которое становится Overflow, а добавление слова Exception это что то вроде вариации польской нотации, но с другой стороны когда мы бросаем и ловим исключение то это читается естественное допустим throw new IndexOutOfRangeException(); но это уже дело привычки что ли. Если применить подход который в докладе повсевместно через некоторое время все привыкнут к новому варианту.

но самое главное - да. семантика. по имени класса должно быть понятно что это

а расскажи как ты именуешь классы у себя на преокте? контроллеры те же. репозитории и т.д.

всё в едином стиле и со всеми постфиксами. Разделять смысла нет никакого. Либо так, либо никак. ибо это всё звенья 1й цепи, 1 и та же "глупость"

но самое главное - да. семантика. по имени класса должно быть понятно что это

"что это" - это весьма смутное определение)

всё в едином стиле и со всеми постфиксами. Разделять смысла нет никакого. Либо так, либо никак. ибо это всё звенья 1й цепи, 1 и та же "глупость"

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

так что в этом есть определенный смысл.

но ценности нет)

это работает +/- для всех. а ценность - понятие довольно растяжимое. Под такую гребёнку можно много вещей закинуть, мол, ценности нет.

так может их и надо закинуть?)

зачем делать что-то что не несет в себе никакого практического смысла?)

UserRepositoryContract

LoggerInterface

UserRepositoryContract

ужас какой

дада. я такое вычищал с проекта :)

ну LoggerInterface - например в случае с PHP и стандартами там как раз это считается "хорошей практикой". Увы...

о да. сам этот интерфейс тоже весьма веселый. ибо он должен содержать только один метод. а не 9 :)

UserRepositoryContract круто смотрится. Особенно если вспомнить чем является интерфейс

или быть абстрактным классом.

или быть абстрактным классом.

нет, вот это точно нет

нет, вот это точно нет

почему

почему

не люблю абстрактные классы)

они в 90% случаев не нужны

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

о.о

UserRepositoryContract круто смотрится. Особенно если вспомнить чем является интерфейс

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

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

поясни и приведи примеры

и уточни говорим мы о языках где поддерживается/не поддерживается множественное наследование и есть/не есть явный механизм определения интерфейсов

"что это" - это весьма смутное определение)

зависит от контекста решаемой задачи, хотя как я думаю если есть какая то одна сущность например дверь, с той картинки в одном контексте в ней буду методы закрыть, открыть и так далее, в другом коде может быть такая же сущность но уже с другими методами. Например есть два списка https://docs.oracle.com/javase/9/docs/api/java/awt/List.html и другой список, имена одинаковые https://docs.oracle.com/javase/9/docs/api/java/util/List.html

interface LoggerInterface { public function emergency($message, array $context = array()); public function alert($message, array $context = array()); public function critical($message, array $context = array()); public function error($message, array $context = array()); public function warning($message, array $context = array()); public function notice($message, array $context = array()); public function info($message, array $context = array()); public function debug($message, array $context = array()); public function log($level, $message, array $context = array()); }

первые 8 методов всегда имеют одну и ту же реализацию

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

себе страшные тайны открывай :) и, да, https://cs5.pikabu.ru/images/big_size_comm/2014-10_4/14137792134800.jpg

которую надо копироват ьвсем

как python обходится без такой языковой конструкции как interface?)

UserRepositoryContract круто смотрится. Особенно если вспомнить чем является интерфейс

имя вообще ни о чем не говорит

зависит от контекста решаемой задачи, хотя как я думаю если есть какая то одна сущность например дверь, с той картинки в одном контексте в ней буду методы закрыть, открыть и так далее, в другом коде может быть такая же сущность но уже с другими методами. Например есть два списка https://docs.oracle.com/javase/9/docs/api/java/awt/List.html и другой список, имена одинаковые https://docs.oracle.com/javase/9/docs/api/java/util/List.html

Да, поведение объекта зависит от контекста.

как python обходится без такой языковой конструкции как interface?)

там есть множественное наследование. Все делают полностью абстрактные классы

первые 8 методов всегда имеют одну и ту же реализацию

так просто раздели интерфейсы

как и в плюсах

так просто раздели интерфейсы

это стандарт PSR :))

с psr все норм

сделай простую реализацию, которая принимает какой-то interface Logger { log(level, message, context) } и реализует все эти 9 методов через вызовы к твоему простому красивому логгеру

с psr все норм

ты в этом уверен?

ты в этом уверен?

кроме имени меня все устраивает)

а что ты скажешь о psr-12?

почему я должен это делать? и должен делать КАЖДЫЙ кто реализует этот логгер.

почему я должен это делать? и должен делать КАЖДЫЙ кто реализует этот логгер.

потому что это похапэ

и ты должен страдать

почему я должен это делать? и должен делать КАЖДЫЙ кто реализует этот логгер.

потому что мало кто реализует логгер?)

и много кто его юзает

так то да. скопипастить 8 методов - ерунда. но это простой пример когда абстрактный класс был бы лучше.

потому что это похапэ

ты же тоже на php пишешь)

я вообще не вижу ни одного доводы в пользу интерфейса

так то да. скопипастить 8 методов - ерунда. но это простой пример когда абстрактный класс был бы лучше.

почему копипастить?

ты же тоже на php пишешь)

и я страдаю(

так там везде вызов 9го метода! с нужным парамтером

так то да. скопипастить 8 методов - ерунда. но это простой пример когда абстрактный класс был бы лучше.

чем лучше?

тут надо 2 интерфейса и трейт в случае php

и я страдаю(

и не было мысли свопаться куда-то еще?) сорри за оффтоп

так там везде вызов 9го метода! с нужным парамтером

с чего ты взял?

может на error я хочу смски посылать

потому что это так. и я даже специально глянул несколько реализаций. там так.

и не было мысли свопаться куда-то еще?) сорри за оффтоп

есть мысли такие

это решается дальше. уровнями логирования

чем лучше?

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

так там везде вызов 9го метода! с нужным парамтером

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

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

тем что ты объявляешь корень цепочки наследования. А интерфейс можно имплементить как захочешь

абстрактный класс должен появляться когда у тебя уже есть 2 класса и у них общие вещи

а не вначале

но это мое мнение

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

абстрактный класс должен появляться когда у тебя уже есть 2 класса и у них общие вещи

а почему не вынести это в объект?)

а почему не вынести это в объект?)

обычно так и происходит)))

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

интерфейс это как раз таки ограничение - ограничивает разработчика от наличия реализации в твоих абстрактных классах

то есть в идеале я хочу иметь "интерфейс без реализации" и "реализации". И если есть общие штуки - значит я где-то упустил какую-то абстракцию

Я тут оффтопну немного и возник такой вопрос: насколько сейчас часто используется паттерн нулевого объекта?

(настолько, насколько есть его нативная поддержка в конкретном языке)

Мои 15 копеек про *Interface, *Contract и прочие ISerializable: без контекста языка это не имеет смысла. В С++ - да, конечно. В Java - скорее нет чем да. C# - наоборот, скорее да чем нет. В PHP... ой да ладно как в команде принято так и будет.

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

Например взять с#. Просто есть в си ш кратенькая проверка на нулл ( типа custObj?.DoSmth()). Есть ли смысл в этом паттерне

какой смысл проверять на нулл.. контракты более жесткими должны быть. если тебе нужен NotNull обьект - проси такой.

я вообще не вижу ни одного доводы в пользу интерфейса

Насчет LoggerInterface я что-то не понимаю или "psr/log" дает вариант и с базовым абстрактным классом и с трейтом + общий интерфейс, если тебе ну прям очень нужно. Стандарты для того и нужны чтобы покрывать максимум кейсов. Картинка про 15 стандартов

почему абстрактный класс не подходит?

Насчет LoggerInterface я что-то не понимаю или "psr/log" дает вариант и с базовым абстрактным классом и с трейтом + общий интерфейс, если тебе ну прям очень нужно. Стандарты для того и нужны чтобы покрывать максимум кейсов. Картинка про 15 стандартов

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

Потому что в PHP нет множественного наследования, не? Я конечно слабо себе представляю настолько упертого человека который захочет отнаслеоваться от AbstractLogger и скажем ммм EntityManager, но интерфейс технически закрывает такой кейс.

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

+1

Я тут оффтопну немного и возник такой вопрос: насколько сейчас часто используется паттерн нулевого объекта?

я могу сказать так - недостаточно часто

Потому что в PHP нет множественного наследования, не? Я конечно слабо себе представляю настолько упертого человека который захочет отнаслеоваться от AbstractLogger и скажем ммм EntityManager, но интерфейс технически закрывает такой кейс.

вот именно это и плохо!

вот именно это и плохо!

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

добавить дефолтные реализации методов как в java и все любители множественного наследования должны закрыться

Нууууууу хз)

плохо, что интерфейс дает такую возможность :)

(дефолтные методы лучше чем возможность объявлять стэйт в базовом классе)

а не то, что множественного наследования нет :))

ну то есть ограничения у тебя остаются

Потому что в PHP нет множественного наследования, не? Я конечно слабо себе представляю настолько упертого человека который захочет отнаслеоваться от AbstractLogger и скажем ммм EntityManager, но интерфейс технически закрывает такой кейс.

EntityManagerInterface это все же рак