EntityManagerInterface... давно это для меня было :)

Наоборот хорошо Оо

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

а почему в шарпах да, конечно?

Почему это?

потмоу что не надо наследоваться. надо композировать :)

и что под "да конечно" подразумевается

потмоу что не надо наследоваться. надо композировать :)

агрегировать

ну да :)

потмоу что не надо наследоваться. надо композировать :)

Не надо наследовать реализации, типы ради бога наследуйте

а почему в шарпах да, конечно?

Потому что там так принято

проблема с extends как раз таки в смешивании понятия Наследования реализаций и типов

в контексте interface extends interface в наследовании ничего плохого нет

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

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

чем тебе дефолтная реализация не нравится?) ну да. кастыль)

в контексте interface extends interface в наследовании ничего плохого нет

Вот золотые слова!

чем тебе дефолтная реализация не нравится?) ну да. кастыль)

Тем что опять смешиваются понятия реализации и абстракции )

Тем что опять смешиваются понятия реализации и абстракции )

ну может быть...

если реализация неотделима от этой абстракции, то я не понимаю смысла. Те же 8 из 9 методов LoggerInterface - должны быть default методами.

если реализация неотделима от этой абстракции, то я не понимаю смысла. Те же 8 из 9 методов LoggerInterface - должны быть default методами.

да с чего вы это решили? :\

что именно?

что абстракция связана с этой реализацией?

у LoggerInterface был бы один метод log(). А остальные 8 - просто методы-хелперы.

у LoggerInterface был бы один метод log(). А остальные 8 - просто методы-хелперы.

что ты знаешь про message obsession?

сейчас загуглю :)

ага. ну так я и говорю. в абстрактном классе можно было бы сделать protected abstract function log(...) и публичные методы error() info() etc.

ага. ну так я и говорю. в абстрактном классе можно было бы сделать protected abstract function log(...) и публичные методы error() info() etc.

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

моя мысль простая - не нужно было туда пихать эти методы-хелперы

так пихай их в мтеоде лог?

они вообще не нужны

так пихай их в мтеоде лог?

ты ж его protected сделал

предлагаешь мне наследоваться?

а я не хочу наследоваться

реализовать :)

мне от логгера нужен только метод log

ты же хочешь свой логгер :)

и больше никаких методов не надо

фактически

ты же хочешь свой логгер :)

я хочу кастомные уровни, логгер свой я не хочу

мне от логгера нужен только метод log

ну я бы сказал, что нужно было разделить интерфейсы с методом log и хелперы эти

ну я бы сказал, что нужно было разделить интерфейсы с методом log и хелперы эти

именно так

короч psr это хорошо но веьсма спорные штуки

мне как пользователю очень ок вместо log(‘error’, $msg) писать error($msg)

это и связанность уменьшает, так то да... но блин

я хочу кастомные уровни, логгер свой я не хочу

psr это ж вроде ограничивает, тебе тогда нельзя от psr\logger зависеть

короч абстрактные классы это плохо

psr это ж вроде ограничивает, тебе тогда нельзя от psr\logger зависеть

ай нипонятно

да блин, логгер как логгер)

что до хэлперов и абстрактного класса - лучше трейт уже

как раз самое оно - тупой бойлерплейт

трейты по мне - хуже абстрактных классов :)

они противоестественные

тайпклассы

они противоестественные

чтобы это значило)

тайпклассы

не, это не те трейты)

не, это не те трейты)

Блмн(

Блмн(

те хорошие)

Я всегда думал что трейты это только тайпклассы

Я всегда думал что трейты это только тайпклассы

в языке для одаренных это механизм копи-паста

трейты по мне - хуже абстрактных классов :)

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

вот для таких вещей трейты неплохо так

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

да ну :)

костыль

protected тоже кастыль, и дефолтные методы интерфейсов

но зато как прижились

protected тоже кастыль, и дефолтные методы интерфейсов

я б сказал бы абстрактные классы костыль, а дефолтные методы норм)

я б сказал бы абстрактные классы костыль, а дефолтные методы норм)

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

в тайпклассах есть DefaultSignatures это тоже самое?

похоже, да

Глупый вопрос: почему так все ломают копья насчет определения ООП, если в вики есть четкое определение - Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. https://en.wikipedia.org/wiki/Object-oriented_programming Или оно слишком расплывчатое?

Дело в том, что ооп основано на концепции сообщений:)

А какие проблемы из этого вытекают?

Важно взаимодействие между объектами, а не сами объекты

Глупый вопрос: почему так все ломают копья насчет определения ООП, если в вики есть четкое определение - Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. https://en.wikipedia.org/wiki/Object-oriented_programming Или оно слишком расплывчатое?

Люди вроде бы читают это определение и другие что "ооп создан для моделирования реальных процесов, переноса обьектов предметной области в код как бы напрямую что намного увеличивает семантику кода" но, потом человек смотрит в реальный код, библиотеки, разные примеры а там: гетеры, сетеры, утил классы, названия обьектов вообще хз какие... и тут начинает действовать синдром утёнка, т.к. других примеров нет и человек думает что вот ЭТО то и есть ООП, нормальный код. Определения из вики и других умных книг благополучно забываются.

ну как всегда, проблема в людях). А с функциональщиной, наверное, поэтому и нет проблем, ибо не мейнстрим.

Всем привет

тут у кого-то пригорает от -er суффиксов в именовании классов?

Writer, Loader, Encoder, Serializer и тд?

А должно?

ну как всегда, проблема в людях). А с функциональщиной, наверное, поэтому и нет проблем, ибо не мейнстрим.

@mkusher есть проблемы?)

Writer, Loader, Encoder, Serializer и тд?

Вопрос в том существуют такие существительные на самом деле или это искусственные существительные с суффиксом er

это все существительные созданные из глаголов - to write, to load, to encode и тд

+ не забываем про "функциональное ядро и императивную оболочку"

не быстро не просто не понятно —- три кита функционального программирования

А больше проблем нет

это все существительные созданные из глаголов - to write, to load, to encode и тд

есть разница как по мне между Loader и UserManager или PasswordVerifier

DNS::Resolve, File::load, Password::verify

есть разница как по мне между Loader и UserManager или PasswordVerifier

Ну, если Loader это абстрактный класс или интерфейс - всё ок.

Ну, если Loader это абстрактный класс или интерфейс - всё ок.

мы сейчас названия типов обсуждаем) что это именно - не важно

У меня немного пригорает от интерфейсов типа Loader::load, Resolver::resolve и т.д.

В таких случаях вероятно потеряна концепция какая-то

У меня немного пригорает от интерфейсов типа Loader::load, Resolver::resolve и т.д.

"As investor I want to invest my investments to became an investor"

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

Ну да)

подскажите, как считаете нужно поступить с отглагольными существительными в подобном кейсе для неких "решателей" уравнений например: interface Solver{ Solve(); int GetProgress(); void Cancel(); } class BruteforceSolver implements Solver class GradientDescentSolver implements Solver

подскажите, как считаете нужно поступить с отглагольными существительными в подобном кейсе для неких "решателей" уравнений например: interface Solver{ Solve(); int GetProgress(); void Cancel(); } class BruteforceSolver implements Solver class GradientDescentSolver implements Solver

что ты брутфорсишь и от чего тебе нужно считать спуск градиента?

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

ну то есть почему бы не сделать Gradient у которого есть метод descent

то есть функция одна, но стратегии поиска корней разные