я понял под инкапсуляцией вы понимаете "мало методов"

нет

у объекта может быть 20 сеттеров

а внутри может быть 200 разных свойств

а под нарушением инкапсуляции "много методов"

инкапсуляцию нельзя нарушить, у тебя либо ее нет вообще (ассемблер) либо она есть

ну так а чем тогда сеттеры нарушили инкапсуляцию

в былые времена инкапсуляцию дополнял такой принцип как information hiding - что мол надо не просто стэйт сделать приватным - но вообще попрятать всю информацию о том как происходит работа с этим стэйтом. А знаешь почему?

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

инкапсуляцию нельзя нарушить, у тебя либо ее нет вообще (ассемблер) либо она есть

завести хитрый регистр?)

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

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

это можно всегда сделать

просто из "set".ucfirst($method) ?

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

что тебе дает инкапсуляция? попробуй придумать 3 плюса

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

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

суть инкапсуляции не в том что бы нехороший вася пупкин не получил доступ к стэйту

суть инкапсуляции в том что бы небыло необходимости в доступе к стэйту

потому что поведение по работе с этим стэйтом лежит прям в той же капсуле

формируя хороший такой модуль

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

что бы методы ничего не возвращали

было бы круто, абсолютный минимум связанности

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

вообще повторюсь - инкапсуляция это простая штука которая про возможность провести границу между "внутри" и "снаружи". Даже в википедии определение примерно такое же

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

помимо этого есть всякие tell-dont-ask, information hiding и прочие штуки которые уступили место в популярности старой доброй "код должен иметь низкую связанность". С этим утверждением ты согласен?

бля у меня просто отрубился инет на пару минут а тут уже такое

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

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

вот я ща слушаю сет девушки одной, видос на ютубе, у нее там панелька с крутилками

куча крутилок

https://www.youtube.com/watch?v=uBm-zXrfdnU&pbjreload=10

ну так чисто для развлекона

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

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

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

а ты говоришь " а почему нет просто 3 крутилок - охуенно, громко, четко" ? )))

ну то есть у тебя есть операция, где связанность ниже, там где вызов 1-ого метода или там где выхов 20-ти?

а в классе своем хоть тысячу методов делай (но там уже поговорим про SRP которое сложно определять и никак не выражается в количестве методов, это скорее как симптом возможный)

а ты говоришь " а почему нет просто 3 крутилок - охуенно, громко, четко" ? )))

давай на каждую крутилку по девушке поставим?)

мне видится так - писать надо так как удобнее. удобно иметь 20 сеттеров - ок делай 20 сеттеров, удобно иметь 1 ::fromBlabla($blabla) - ок

или дадим 5 девушкам 2 крутилки)))

каждой из пяти по две крутилки

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

а вдруг операция не атомарная?

мне видится так - писать надо так как удобнее. удобно иметь 20 сеттеров - ок делай 20 сеттеров, удобно иметь 1 ::fromBlabla($blabla) - ок

и да и нет. Согласен что писать надо так как удобнее, но не надо подменять понятия. Не надо смешивать "мне удобнее потому что по другому я хз как" и "мне удобнее потому что в этой задаче так лучше и сейчас пока не предвидится что будет неудобно потом"

ну вот я например обновляю сущность и фотки не догрузились, мне вот прям выдать косяк на весь экран что "сорян там твои 20 полей слетели, потому что ты кривую фотку закинул" или лучше обновить все кроме фоток?

а вдруг операция не атомарная?

это другой разговор но у тебя много таких?)

выше )

ну вот я например обновляю сущность и фотки не догрузились, мне вот прям выдать косяк на весь экран что "сорян там твои 20 полей слетели, потому что ты кривую фотку закинул" или лучше обновить все кроме фоток?

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

а если дело не доходит до создания элемента? фотки на хостинге лежат или удаляются как то?

а то я тож сегодня так подумал но меня этот момент с мусором на диске смущает

а если дело не доходит до создания элемента? фотки на хостинге лежат или удаляются как то?

честно? лежат и все.

но нет никаких проблем сделать что-то типа очереди на чистку

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

и после создания поста юзающего эти фотки для этих фоток удалять задачу

+ можно лить напрямую на s3 через подписанные ссылки)

ну вот я например обновляю сущность и фотки не догрузились, мне вот прям выдать косяк на весь экран что "сорян там твои 20 полей слетели, потому что ты кривую фотку закинул" или лучше обновить все кроме фоток?

но все же - какое отношение это имеет к инкапсуляции?)

ну и еще важный момент

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

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

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

addPhoto()?)

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

addPhoto()?)

setPicture()!

потомушта картинка основная одна. addPhoto Это если в галерею, ну да может быть и так. однако может быть и сразу setGallery(array $gallery)

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

потомушта картинка основная одна. addPhoto Это если в галерею, ну да может быть и так. однако может быть и сразу setGallery(array $gallery)

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

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

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

а релейшен мы часто делаем просто так по факту

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

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

ERROR: S client not available

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

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

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

я говорил не Вам =)

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

ну вот это я бы не записывал в плюсы))))

хотя и то тоже....

почему?

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

это еще более чувствительная к факапам декомпозиции штука чем то о чем я вещаю

это как вынужденная мера а не клевая штука

но принципы те же да

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

ну в хайлоаде че только не делают)

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

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

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

на счет фоток и комментирования... я однажды писал документооборот... В начале были такие документы как "Договор" и "Контрагент".... Под каждым документом можно писать комментарии и делать вложения файлов. у каждого документа своя бизнес логика и жизненный цикл

и вот, по классике, в начале я линковал сущности "Договор" - с "Комментарием", с "Вложением"...

а потом таких документов стало очень много, Доп соглашение, Заявка на оплату и т.д.

а в сущности Вложение стали появляться такие поля как contract, agreement, payment и т,д,... Если файл связан с платежом, то остальные поля - null

в конце отказался от такого подхода...

и как сделал в итоге то?

комментарии - не знают про документы, а документы не знают про файлы и комменты

только в ui получаю связанные сущности

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

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

сорян я уже деградирую но все же

в конце отказался от такого подхода...

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

например так: (не скажу что это идеальное решение, но от многих проблем избавился) contract: id: 1 name: "Договор" comment_thread: type: "contract" id: 1 comment: id: 1 thread_id: 1 body: "Коммент"

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

айдишку какую в фотке ты хранишь (или отдельная табличка для связей) просто релейшенов нет как таковых на уровне ORM.

а для UI - композиция данных

абсолютно независимые модули

есть две таблицы: comment_thread и comment... они могут интегрироваться в любой документ, и ничего не будут знать про сам документ

а в документе нет никаких связей с комментом

для каждого документа создается thread