Расширение класса внешними методами и переменными

[Yoskaldyr]

Есть объект с данными, который необходимо чтобы был мутируемым, только через собственные методы.
И у этого объекта данных дофига. Зачем мне на каждое свойство писать отдельный геттер, когда можно просто обратиться к этому свойству?

Не всегда нужна именно именно иммутабельность. Иммутабельность на действительно здоровых объектах с здоровенным набором данных вылазит боком когда много клонирования этих объектов по типу ->with(...)

Исходя из твоей логики в пхп надо вообще публичные свойства с данными запретить ибо хреновая архитектура - данные же торчат наружу. А также во всех остальных ООП языках тоже запретить прицепом.

 

[fixxxer]

Есть объект с данными, который необходимо чтобы был мутируемым, только через собственные методы.
И у этого объекта данных дофига. Зачем мне на каждое свойство писать отдельный геттер, когда можно просто обратиться к этому свойству?

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

Не всегда нужна именно именно иммутабельность.

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

Если тебя это успокоит, я много лет такое говно сам писал.

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

Ну, язык-то, конечно, должен позволять писать любое говно, тем более что 99% всего, что пишется - полное говно Против get{} set{} а-ля C# ничего не имею, но сам бы вряд ли использовал.

 

[WMix]

Как их делать, понятно - сделать public final.

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

Fatal error: Cannot declare property A::$b final, the final modifier is allowed only for methods and classes

 

[Yoskaldyr]

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

Даже для данных?????
Ведь в пхп нет структур и все приходится делать через классы чтобы была хоть какая-то фиксированная структура.

Тогда вопрос как реализовать структуру, которая другими частями приложения используется в 90% случаев используется только для чтения этих данных, также есть методы для вычисляемых свойств, а также несколько методов для комплексного изменения этих данных.
Иммутабельным делать нельзя (слишком большой размер, и стандартный подход мутации через клонирование с with приводит к OOM)

Как это сделать?

 

[fixxxer]

На такой абстрактный вопрос я могу только абстрактно ответить "не делать так": выглядит как какой-то god object.
Без конкретики непонятно, как такое получилось.

 

[AmdY]

@AmdY Когда пишешь свое, то что декоратор, что все извращения из данной темы не нужны
А вот когда коробочное "чудо" типа XenForo и Magento, то такие декораторы будут очень кстати и более правильно чем костыль с наследованием.

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

 

[Yoskaldyr]

god object.

это data object. И все 100500 полей это свойства объекта физического мира (метрики статистики юзера). Если брать персистенс слой, то в таблице больше 10К колонок (абсолютно равнозначные decimal значения) по которым может считаться очень хитровые...ая групповая стата. С точки зрения логики взаимодействия полей, одни поля влияют на другие, так что вся логика изменения, сравнения между объектами зависит только от этих самих данных.
И если опять поднимется тема эктив рекордов, и т.п. То количество колонок в базе это просто пример как это все хранится, и к самому объекту это не имеет отношения, он вообще ничего не знает о персистенс слое.

 

[Yoskaldyr]

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

 

[Adelf]

это data object. И все 100500 полей это свойства объекта физического мира (метрики статистики юзера). Если брать персистенс слой, то в таблице больше 10К колонок (абсолютно равнозначные decimal значения) по которым может считаться очень хитровые...ая групповая стата. С точки зрения логики взаимодействия полей, одни поля влияют на другие, так что вся логика изменения, сравнения между объектами зависит только от этих самих данных.
И если опять поднимется тема эктив рекордов, и т.п. То количество колонок в базе это просто пример как это все хранится, и к самому объекту это не имеет отношения, он вообще ничего не знает о персистенс слое.

объект с 100500 полями это говнокод, а не ООП. Надо на классы бить. Есть даже упражнение: описать модель используя только максимум 3 поля на класс и максимум 3 параметра в каждом методе. А уже объекты можно и lazy-load. это ORM умеют и без всяких нововведений. Проксями разными.

 

[Yoskaldyr]

@Adelf это стата, вот вообще тупо стата. значения полностью равнозначные и что делать с этой статой решает статистик.

Т.е. это массив с данными и с вычислением этих данных (вычисляемые значения). и несколько мутаторов.

Это как раз предметная область. А не код

 

[Adelf]

@Adelf это стата, вот вообще тупо стата. значения полностью равнозначные и что делать с этой статой решает статистик.

Т.е. это массив с данными и с поведением этих данных (вычисляемые значения). и несколько мутаторов. все

тогда причем тут объекты? чистая инфраструктура. SQL!

 

[Yoskaldyr]

а логику в mysql не запихнуть!

 

[Вурдалак]

@Adelf это стата, вот вообще тупо стата. <..> и несколько мутаторов.

А зачем тебе мутаторы в таком объекте? Ответ от статы иммутабелен. Меняешь ответ — это другой ответ.

 

[Вурдалак]

Кстати, уже сейчас в принципе можно юзать psalm immutable + public свойства. 80% кода в виде геттеров идет на помойку. А потом можно дождаться readonly/final.

 

[Yoskaldyr]

Кстати, уже сейчас в принципе можно юзать psalm immutable + public свойства

так давно можно использовать паблик + пхпдок - тот же эффект в сторме

 

[Вурдалак]

так давно можно использовать паблик + пхпдок - тот же эффект в сторме

Не, нужно чтобы при запушить было нельзя, обязательно кто-то из коллег нарушит правило.

 

[Yoskaldyr]

А зачем тебе мутаторы в таком объекте? Ответ от статы иммутабелен. Меняешь ответ — это другой ответ.

потому что стата накопленная, и она обновляется периодически и в процессе расчета происходит несколько мутаций и сохранение зависит от результатов этих мутаций, в 90% случаев вообще не сохраняется

 

[Yoskaldyr]

Не, нужно чтобы при запушить было нельзя, обязательно кто-то из коллег нарушит правило.

точно видел еще какое-то расширение для этого (не псалм), как раз для паблик + ридонли пхпдок аннотации

 

[Вурдалак]

потому что стата накопленная, и она обновляется периодически и в процессе расчета происходит несколько мутаций и сохранение зависит от результатов этих мутаций, в 90% случаев вообще не сохраняется

Всегда есть последний return, где ты можешь написать new MyStatData(...) от всех накоплений.

 

[Вурдалак]

точно видел еще какое-то расширение для этого (не псалм), как раз для паблик + ридонли пхпдок аннотации

И как оно помешает запушить? А если расширение не установят?