Имхо - PSR лучшее что произошло с РНР за последние годы, и продолжать ебашить свои велосипеды и свои 15тые по счету ахуенные стандарты это бред - вместо того чтобы потратить время на улучшение текущих.

Ну класс это не только поведение. А интерфейс это только поведение

Имхо - PSR лучшее что произошло с РНР за последние годы, и продолжать ебашить свои велосипеды и свои 15тые по счету ахуенные стандарты это бред - вместо того чтобы потратить время на улучшение текущих.

ты походу меня вообще не услышал, ну да не суть

я это называю "надстройкой над стандартом"

Надстройка, это добавление, уточнение. А если ты берешь одно правило из 7 то считай, что ты ничего не берешь.

Ну класс это не только поведение. А интерфейс это только поведение

с точки зрения типов разницы никакой. Если я вижу Catalog мне плевать интерфейс это или класс

Надстройка, это добавление, уточнение. А если ты берешь одно правило из 7 то считай, что ты ничего не берешь.

но я убираю одно правило из 7-ми

короч Боря, приходи за пивом потрещим

имхо ты слишком категоричен

как-нибудь

Как у вас поведение отвечает на вопрос кто? То есть, интерфейс определяет что делать. И у вас это существительное?

приведи примеры поведений

помимо Serializable и т.д.

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

Да любой интерфейс это поведение.

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

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

Да любой интерфейс это поведение.

любое публичное API любого объекта описывает поведение. Интерфейс описывает публичное API.

поведение = протокол, ты можешь поменять поведение не меняя интерфейс

Интерфейсы ради интерфейсов уж точно не нужны

у меня есть например такие интерфейсы: - FeeCalculator - производит расчет фии, клиентскому коду плевать, это "должна быть такая штука которая расчитываем мне fee" - Transaction - некая штука которая описывает некие транзакции и умеет их бродкастить

то есть "поведение" это не прилагательное, это роль, кто делает это поведение

ох чую

https://gist.github.com/

написал свой первый контроллер)

написал свой первый контроллер)

почему ты думаешь что это контроллер?

Читал книгу Кевина Янка. Там говорилось что это называется контроллер)

написал свой первый контроллер)

а где там контроллер?

Читал книгу Кевина Янка. Там говорилось что это называется контроллер)

почему контроллеры называются контроллерами?)

FeeCalculator - вы не путаете абстрактные классы и интерфейсы?

и как понять контроллер перед тобой или нет?

FeeCalculator - вы не путаете абстрактные классы и интерфейсы?

нет, не путаю. А вот вы судя по всему чуть-чуть путаете

Они принимают и обрпбатывают запросы?)

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

с точки зрения именования разницы нет никакой

Они принимают и обрпбатывают запросы?)

ну они скорее обработку делигируют кому-то другому и занимаются чисто control flow

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

))

Читал книгу Кевина Янка. Там говорилось что это называется контроллер)

обычно в книгах есть примеры. ваше похоже на пример?

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

плохая книжка

:C

Просто хотел узнать насколько это говнокод)

То есть по вашему нет ни какой разницы меэжу классами, асбстрактными классами и интерфейсами? Мы с вами говорим о проектировании. Все эти сущности дают возможность проектировать. Интерфейс определяет какие методы должен определить класс. Возьмите любой пример кода связанный с интерфейсом и будет понятно что интерфейс дает какое то поведение. Именно поэтому их чаще всего называют с суфиксом able. И именно поэтому можно реализовывать несколько интерфейсов. Для того чтобы сказать, что класс имеет вот такое поведение, и вот такое поведение. Сколько методов в вашем интерфейсе FeeCalculator?

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

ну вот теперь вынеси весь SQL хотя бы в отдельные функции

То есть по вашему нет ни какой разницы меэжу классами, асбстрактными классами и интерфейсами? Мы с вами говорим о проектировании. Все эти сущности дают возможность проектировать. Интерфейс определяет какие методы должен определить класс. Возьмите любой пример кода связанный с интерфейсом и будет понятно что интерфейс дает какое то поведение. Именно поэтому их чаще всего называют с суфиксом able. И именно поэтому можно реализовывать несколько интерфейсов. Для того чтобы сказать, что класс имеет вот такое поведение, и вот такое поведение. Сколько методов в вашем интерфейсе FeeCalculator?

1 метод

придумайте мне название для "поведения" вычисления fee

FeeCalculable?

это ж чушь, мне нужна конкретная "вещь" которая делает для меня что-то

PasswordEncoder, ProductRepository, OrdersGateway, EventDispatcher, Notifier

интерфейсы оканчивающиеся на able это скорее редкость

Если вы говорите о том как назвать интерфейс, то это уже как угодно. Все зависит от того для чего он нужен.

Если вы говорите о том как назвать интерфейс, то это уже как угодно. Все зависит от того для чего он нужен.

у меня есть код формирующий транзакции. Для того что бы знать сколько и кому мне нужна штука которая посчитает сколько и кому

есть 2-3 стратегии распределения этих fee (зависит от конфигурации системы)

ну я не говорю что это строгое правило. Просто Интерфейс всегда отвечает на вопрос "Какой ". У вас по названию может быть хоть просто одна буква. Но все ровно интерфейс отвечает на вопрос "Какой" а не что.

ну я не говорю что это строгое правило. Просто Интерфейс всегда отвечает на вопрос "Какой ". У вас по названию может быть хоть просто одна буква. Но все ровно интерфейс отвечает на вопрос "Какой" а не что.

приведите пример который доказывает вашу точку зрения

Я понял, у нас с вами спор только из за того "как назвать интерфейс".

Я понял, у нас с вами спор только из за того "как назвать интерфейс".

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

вот как вы выделяете интерфейс?

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

Какие нужны примеры, если интерфейс это определение поведения? Поведение - это какой? или это что?

Да еще раз, я могу его хоть одной буквой назвать.

просто i

Какие нужны примеры, если интерфейс это определение поведения? Поведение - это какой? или это что?

поведение - это уж точно не "какой". Это "что делает"

это роль

роль это существительно, это "кто/что"

Ну пусть будет "что делает". Но точно не что или кто.

Ну пусть будет "что делает". Но точно не что или кто.

почему?

Потому что это поведение

у вас есть очень простая штука для того что бы декларировать поведение - роли

ты же не можешь создать поведение?

вот если бы мог то это было бы что или кто

в смысле "создать"? я могу создать роль

"строитель" - строит, что именно - определит конкретная реализация и отразит это в имени.

"врач" - его поведение - лечить/диагностировать

"репозиторий" - его поведение - хранение вещей

"калькулятор" - что-то считает

"энкодер" - что-то энкодит

"шифратор" - что-то шифрует

попробуй просто вот эти поведения (шифрование хотя бы) задать вопросом "какой"

https://www.amazon.com/Object-Design-Roles-Responsibilities-Collaborations/dp/0201379430

вот хорошая кгина на эту тему

Как в анекдоте

Чем мерить амперы? Амперметром

А напряжение?

Напряжометром

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

например, и будет у тебя и амперметр и вольметр

(если для задачи ок что пофиг что нам дали))

И все это поведение. Вы не можете создать интерфейс врач, вам нужно будет создавать класс врач. Я же не утверждаю что всегда интерфейс надо называть по одному правилу, я вам сказал вы как угодно можете называеть его. Но как вы его не назовете это всегда поведение. Мы с вами спорим о разных вещах, вы спорите про то как называть интерфейсы, я спорю про то за что отвечают интерфейсы. Пусть будет не "какой" пусть будет "что делающий".

И все это поведение. Вы не можете создать интерфейс врач, вам нужно будет создавать класс врач. Я же не утверждаю что всегда интерфейс надо называть по одному правилу, я вам сказал вы как угодно можете называеть его. Но как вы его не назовете это всегда поведение. Мы с вами спорим о разных вещах, вы спорите про то как называть интерфейсы, я спорю про то за что отвечают интерфейсы. Пусть будет не "какой" пусть будет "что делающий".

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

если у тебя класс называется так же как и интерфейс то значит тебе не нужен интерфейс

ну вот теперь вынеси весь SQL хотя бы в отдельные функции

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

интерфейс - обобщенное описание роли имеющей какую-то ответственность. Абстрактный класс - тоже самое.

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

вызвать а не вставить, это называется разделением ответственности.

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

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

экономия 5-ти минут на именовании, на разделении и т.д. может потом привести к часу "разбираться как же это работает"

Понял. Спасибо)

Alexander > я спорю про то за что отвечают интерфейсы. интерфейсы отвечают за описание зоны ответственности, и поскольку все сущности должны именоваться существительными (это ж сущности а не характеристики) то мы можем сказать что имя интерфейса отрадает роль, а к роли уже привязано какое-то поведение

такая трактовка тебя устроит?