привет, народ

подскажите, почему хреново наследуется статика?

што

точнее так, действительно ли нету решения другого, кроме как создавать для дочернего класса свои свойства?

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

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

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

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

?

..просто детей много, и архитектурно как-то ней айс

Не, придется объявлять

Статическое свойство родителя принадлежит всем потомкам одинаково, поэтому они не смогут получить свой инстанс свойства на класс.

понял. и до вопроса ещё понял. хорошо переформулировали) а как победить?

статика уже архитектурно не айс ;)

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

но, в итоге я пишу код в десятки раз быстрее за счёт такой вот нотации

т.е. не просто в разы, а реально в разы быстрее. в отличие от бесконечных "obj->subroutine()->field"

ну и т.п.

пример готового класса про клиента магаза

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

может дадите прогноз на будущее этого проекта? )

Ну тут впринципе на скриншотах все сущности и так по своей природе синглтоны - Request, Response, Journal, Logger. Поэтому и кажется что с ними удобно работать в статике.

А давно вообще программируешь?

а для объектов у меня в доменных структурах всё спрятано

А насчет клиента - я не понял что это за класс и за что он отвечает.

без фабрик работаю. объекты домена - куски поведенческой модели.. как-то так

Если работа с одним клиентом все время жизни скрипта, то это тоже логично что со статикой проще.

у клиента функции обычного CRUD

+ одна отдельная для "установить скидку клиенту"

со статикой всегда все проще... писать

На самом деле интересная задача - на примерах показать, где именно рулят объекты и не рулит статика :)

вот. Павел верно заметил

но вообще-то хороший программист - не тот, который умеет писать код быстро

если с одним

а если не с одним - я беру экземпляр AR просто или его ID

соврал.

всегда передаю ID

а с ним уже работает другой доменный объект который отвечает за тип объекта чей ID ему передан

т.е. хочу я клиента другого отредактировать и пишу просто Client::updateFieldById($newFieldList[], $clientId)

и всё )

Дмитрий, мне надо напилить 20 магазов, не до размусоливания)

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

ну т.е. это имхо, но, думаю, многие согласятся

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

который по сути просто набор констант

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

вот он сам

пиши на функциях, в общем тоже быстро ;)

Ну как бы тут _сразу понятно_ - потому что полторы строчки написано. А когда в проект потянешь пару десятков вендорных библиотек и своих исходников тысяч 400 строк наклепаешь, вот тогд и взвоешь от статики.

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

Да, по сути это обычный процедурный стиль.

В свежем пхп даже функции можно рассовать по неймспейсам вместо классов.

главное, потом после полученения денег сменить телефон ;)

ну да, одно за другим, но это в контроллерах

структура домена уже немного иерархична

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

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

код сам из головы идёт как стих, как разговариваешь с интерпретатором через framework

мдя, новые три буквы ушли в массы...

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

вот он сам

блин, глаза вянут

ERROR: S client not available

вот что с ним можно делать

почему вянут?

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

оформление кода адское, стиль кода адский.... и скриншоты для демонстрации кода - красивый такой черный бант сверху

this->domainObject определено в декларативном коде контрллера ArticleController

почему адское то? Вы пишите по делу, пож-та

я макс читабельно для себя разработал способ. если он не PSR-x это ещё не значит что это плохо, а скорее то, что Вы не умеете объективно оценивать =\

я не в обиде. но мне не требуется субъективизм. он никому вообще не требуется

объективен только парсер ПХП

Вот мне интересно, как реализован $domainObject::getList() что он возвращает. Я так и не увидел.

вот getList для объектов домена которые работают с реальной инфой (StoredObject)

я же не буду говорить, что код не тестируемый в принципе... окажется, что тут не до тестов, лес валить нужно ;)

ну я на тесты подзабил, да

а что?

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

только потому что статика что ли всё плохо по Вашему?

О, ну $query->getAll() это уже объект а не статика )

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

ну так getAll это то, что попадёт уже во View

паш, я думаю это уже не его код, где ->getAll :)

Плох не сам по себе факт статики, а те страдания которые она приносит про поддержке и доработке приложения.

код мой от начала до конца, кроме самого Yii2, конечно

AR использую готовый

Вот ты паш глубокую мысль щас сказал ;)

хорошо. какие страдания?

вот я через полгода нах забуду контекст вообще

взгляну и за сек пойму что куда

так я и говорю, getAll не твой.... все, что не статика - не твое ;)