А зачем счёту знать что-либо о платёжном шлюзе? В вашем случае именно так и получается. По-моему, тут зависимости ровно в другую сторону должны быть направлены. А еще лучше, если счёт не будет ничего знать о шлюзе, а шлюз о счёте.
Чесня есть? Есть. Башкирия есть? Есть. Дагестан? Есть. А где русская республика? Где живут не татары или башкиры или чукчи, а те самые пресловутые этнические русские. Где она?
Российская Федерация — правопреемница РСФСР. В аббревиатуре РСФСР есть слово «Федеративная», что как бы говорит, как вы правильно заметили сноской об определении слова «федерация», о том, что республика включала в себя другие, меньшие по размеру, республики. Соответственно, РФ — это и есть большая республика с федеративным государственным устройством, то есть она всё так же включает в себя другие республики. И продолжает оставаться республикой.
По сути, в 1991 году из-за распада СССР одно название пришлось заменить на другое, так как стали уже ни советские, ни социалистические. А могли бы назвать страну «Российская Федеративная Республика». Возможно, это немного точнее отражало бы устройство государства, не знаю. Просто «Российская Федерация» и «РФ» — банально короче, чем «Российская Федеративная Республика» и «РФР».
Республики нет, потому что есть федерация. Иное государственное устройство. До федерации был СССР, до этого империя. Что вы к республике-то прицепились?
Хорошо представим что в методе isDelivered потребовалось что-то кроме полей самой модели, что тогда делать? Инджектить как-то зависимость в модель? Передавать зависимость постоянно в метод isDelivered($someService).
Если состояние «доставлено» перестало быть обычным флагом, то, возможно, стоит задуматься о выделении этого состояния в отдельный класс. Вполне может получиться, что «доставка» — это отдельная сущность со своей логикой. Это сильно зависит от контекста.
И как автор к приеру выбирает из базы данных все заказы которые delivered? Пишет что-то вроде SELECT FROM WHERE status = «delivered», все равно логика уехала из модели. И скорее всего будет перемещена в репозиторий. Ну так зачем размазывать логику везде, уже пиши все в репозитории.
Есть мнение, что сущности и логика в них предназначены, главным образом, на запись. На чтение можно использовать обычные массивы, DTO и т.д. Я думаю, что в этом случае одно другому не мешает, т.е. логика никуда не уезжает.
А потом автор прикрутит какой-то сериализатор и он ему на 1000 моделях понадергает публичные методы delivered т.д. и хорошо если это просто сильно замедлит скрипт, хуже если эти публичные методы приведут к каким-то side effects нежелательным.
И вообще в современном мире когда все взаимодействие идет с бекендом обычно через АПИ, вообще вопрос инкапсуляции решается не сеттерами и геттерами, а группами сериализации, которые решают что видно извне и формируют интерфейс взаимодействия.
А вот это мне совсем не понятно. Зачем использовать сложные штуки, если можно использовать простые? Группы сериализации, конфиги для них и т.д., и т.п., вместо того, чтобы просто достать из БД необходимый набор данных в виде массива, например. Ну то есть я не понимаю, зачем для UI делать выборку сущностей.
И если уж автор решил заняться инкапсуляцией, тогда я ему надо посмотреть в сторону паттернов Command либо Workflow. Грубо говоря отдельный слой, для работы с моделями, а с самими моделями напрямую не работать вообще.
В конце концов кто-то всё равно должен работать с сущностями.
Symfony DI тут никак не поможет — зависимости придётся передавать явно. В частности, если у нас есть стек вызовов таких умных методов, и самому глубокому из этих методов понадобилась какая-то зависимость, её придётся пробрасывать через весь стек, не получится просто взять её из контейнера на нужном уровне.
Мне кажется, что появление "сквозной" зависимости говорит о том, что что-то пошло не так...
Документация даёт самые простые примеры, чтобы в API библиотеки или фреймворка можно было быстрее въехать. Потому обычно не навязываются подходы к его использованию. Так что не стоит принимать примеры из документации за единственно верный способ программирования с использованием предлагаемого API.
Есть один лайфхак, которым я воспользовался. Приехать в город назначения, допустим, в отпуск или на IT-конференцию, если в этом городе они бывают. У меня получилось совместить первое со вторым. В течение отпуска сходить на собеседование и договориться на удалённую работу с последующим переездом. Вполне возможно, что компания будет не против.
Переехал из Южно-Сахалинска в Новосибирск. Что понадобилось: 1) устроиться заранее в компанию на удалёнку, 2) собраться с силами и духом (лично для меня — самый сложный момент), 3) подкопить денег, чтобы точно хватило на первое время при поисках нормального жилья. Всё. Так что дерзайте :)
А зачем счёту знать что-либо о платёжном шлюзе? В вашем случае именно так и получается. По-моему, тут зависимости ровно в другую сторону должны быть направлены. А еще лучше, если счёт не будет ничего знать о шлюзе, а шлюз о счёте.
Про Дагестан особенно смешно в контексте того, что это самая многонациональная республика в составе России.
Вот почитайте: https://ru.wikipedia.org/wiki/Российская_Советская_Федеративная_Социалистическая_Республика
Российская Федерация — правопреемница РСФСР. В аббревиатуре РСФСР есть слово «Федеративная», что как бы говорит, как вы правильно заметили сноской об определении слова «федерация», о том, что республика включала в себя другие, меньшие по размеру, республики. Соответственно, РФ — это и есть большая республика с федеративным государственным устройством, то есть она всё так же включает в себя другие республики. И продолжает оставаться республикой.
По сути, в 1991 году из-за распада СССР одно название пришлось заменить на другое, так как стали уже ни советские, ни социалистические. А могли бы назвать страну «Российская Федеративная Республика». Возможно, это немного точнее отражало бы устройство государства, не знаю. Просто «Российская Федерация» и «РФ» — банально короче, чем «Российская Федеративная Республика» и «РФР».
Республики нет, потому что есть федерация. Иное государственное устройство. До федерации был СССР, до этого империя. Что вы к республике-то прицепились?
Никому ничего не хочется. В этом Крыму кого только не было за всё время его существования.
Спасибо большое за ссылку, зачитался прям! В школьные годы «Слово...» было как-то неинтересно, хотя некоторая тяга к языкам всегда была)
Некоторые считают, что на Википедию ссылаться — моветон, но тем не менее: https://ru.wikipedia.org/wiki/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F_%D1%83%D0%BA%D1%80%D0%B0%D0%B8%D0%BD%D1%81%D0%BA%D0%BE%D0%B3%D0%BE_%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0
Восточнославянские языки образовались примерно в одно время.
Так туда и не надо ничего внедрять, кроме того, из чего состоит непосредственно сущность.
Приведите примеры.
Пруфы?
Если состояние «доставлено» перестало быть обычным флагом, то, возможно, стоит задуматься о выделении этого состояния в отдельный класс. Вполне может получиться, что «доставка» — это отдельная сущность со своей логикой. Это сильно зависит от контекста.
Есть мнение, что сущности и логика в них предназначены, главным образом, на запись. На чтение можно использовать обычные массивы, DTO и т.д. Я думаю, что в этом случае одно другому не мешает, т.е. логика никуда не уезжает.
А вот это мне совсем не понятно. Зачем использовать сложные штуки, если можно использовать простые? Группы сериализации, конфиги для них и т.д., и т.п., вместо того, чтобы просто достать из БД необходимый набор данных в виде массива, например. Ну то есть я не понимаю, зачем для UI делать выборку сущностей.
В конце концов кто-то всё равно должен работать с сущностями.
Был небольшой опыт работы с Sylius.
Мне кажется, что появление "сквозной" зависимости говорит о том, что что-то пошло не так...
Как раз таки бизнес-логики не должно быть в контроллерах. Плавали, знаем...
Спасибо за статью! В конце статьи, в примере с геттерами, не хватает контрпримера с логикой внутри сущности. Было бы отлично туда его добавить :)
Документация даёт самые простые примеры, чтобы в API библиотеки или фреймворка можно было быстрее въехать. Потому обычно не навязываются подходы к его использованию. Так что не стоит принимать примеры из документации за единственно верный способ программирования с использованием предлагаемого API.
Это же из Blood? Мы в детстве этих чуваков фантомасами называли :D
Есть один лайфхак, которым я воспользовался. Приехать в город назначения, допустим, в отпуск или на IT-конференцию, если в этом городе они бывают. У меня получилось совместить первое со вторым. В течение отпуска сходить на собеседование и договориться на удалённую работу с последующим переездом. Вполне возможно, что компания будет не против.
Переехал из Южно-Сахалинска в Новосибирск. Что понадобилось: 1) устроиться заранее в компанию на удалёнку, 2) собраться с силами и духом (лично для меня — самый сложный момент), 3) подкопить денег, чтобы точно хватило на первое время при поисках нормального жилья. Всё. Так что дерзайте :)
Ну неправда же.