И снова ООП - как хранить и задействовать настройки для каждого свойства?

[AnrDaemon]

Оставлять всякий спам, типа

От того, что ответ тебе не понравился, он не становится менее информативным.
Ну и вспоминаем поговорку про монастырь и устав.

P.S.
По сути тебе уже @Adelf ответил, а по смыслу -

Спойлер

На тот случай, если ты не заметил этого сразу - это клуб, куда приходят люди пообщаться по интересам, а не обязаловка с муштрой. И если ты не приглянешься людям, они тебе об этом скажут, а не будут со стиснутыми зубами выносить твои глупости.
В твоих интересах хотя бы прислушаться к ответам людей и попытаться понять, почему тебе советуют это, а не что-то другое. На сколько тут не любят меня, я ещё откровенно глупых советов тут не получал. А вот интересных и информативных, заставляющих по-новой взглянуть на свои мытарства или не наделать дурацких ошибок - массу.
Да, не все советы будут полезны в конкретно твоём случае, но разница между "уйдите, я сам всё лучше вас знаю" и "да, мой код говно, но я понимаю, почему я это… пишу сейчас, и в следующий раз я постараюсь не доводить до… такого" - это то, что отличает "новичка с амбициями" (читай: идиота) от специалиста.

 

[Timol]

а это не спам

Ах, ну извините, не заметил, что ты из "Команда форума" - как же такой "беспристрастный" модератор может назвать свое сообщение спамом?

Я смотрю когда же fixxer наберет критическую массу аргументов, чтобы убедить тебя

Убедить в чем?

И она тоже пойдет в табличку базы?

"обработка СМСки на корректность" - ввод кода, полученного из СМСки, сравнение его с верным и если все ок - "галочка" в БД напротив телефона - checked. Сам текст СМСки также может пойти в БД, но только в отдельный лог отправленных СМС, если таковой нужен.

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

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

P.S. Спасибо @WMix, @fixxxer и @Sufir за сообщения/советы/ссылки, жаль что эта ветка превратилась в очередную помойку, не относящуюся к теме.

 

[Adelf]

Эх, новички. Тебе уже советовали YAML. тот же JSON можно. Ссылки на доктрину и симфони кидали. Ты вроде лайкаешь, но чегот не видно что ты прочел и внял.

 

[AnrDaemon]

Эх, новички.

Это уже не новички… Это нубы :/

 

[fixxxer]

Да в принципе, нормально все, этот этап тоже надо пройти. Я когда-то давно тоже пытался написать подобное

 

[Adelf]

Да почти все пытались. Просто было бы приятно помочь сократить этот период некоторым товарищам.

 

[AmdY]

Да чё, нормальная идея, покрывает большинство кейсов для админок. Но я не понимаю, в чём проблема у парня завернуть свои массивы в объекты. Ведь е него это де факто и есть объект, к которому нужно только прикрутить геттеры-сеттеры, можно даже arrayobject имплементировать. Не понятно, на каком шаге у него проблемы с ООП.

 

[Вурдалак]

@AmdY а какое отношение геттеры и сеттеры имеют к ООП?

 

[Adelf]

@Вурдалак, не покушайся на святое. Это ж один из трех китов!

 

[AmdY]

@AmdY а какое отношение геттеры и сеттеры имеют к ООП?

Инкапсуляция.В данном случае сеттеры обеспечат корректность заполняемых данных, вроде min-max это числа, а type должен быть из определённого списка значений. Тем самым человек поймёт почему ооп с классами удобнее чем без ооп без них.

 

[WMix]

сам set ничего не делает, те ты сам себя заставляешь написать 2 действия ->set($var)->do(); а можно проще ->do($var) или еще проще ->do() но заинжектить заранее

 

[Вурдалак]

Инкапсуляция.В данном случае сеттеры обеспечат корректность заполняемых данных

Это ты нам рассказываешь про секс ради девственности. Сеттеры самым прямым образом нарушают инкапсуляцию.

Что касается «данного случая», то я очень мельком пробежался по треду и насколько понимаю, ты под «обеспечением корректности заполняемых данных» понимаешь получение данных от пользователя? Как ты собрался обеспечивать корректность в сеттерах: выкидывать исключение, если значение меньше min? Или менять его втихую на «корректное»? Данные в DTO, которые мы получаем от пользователя, мы вполне себе можем получать как есть, а уже с помощью всяких валидаторов убедиться, что этот запрос с DTO нам по каким-то причинам кажется неверным.

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

 

[AmdY]

Ну ежик. У него конфиг, а не данные от пользователя. И проверять нанные внутри это как раз ИНкопсуляция, а твой DTO это АУТкапсуляция, т.к. размазывает выносит логику во вне, требует сторонних инструментов чтобы проверить это самое корректное состояние. Я вот прямо сейчас совокупляюсь с DTO и сериализатором, вместо двух маленьких классов имею 9 на 563 строки.

 

[Вурдалак]

У него конфиг, а не данные от пользователя.

сеттеры обеспечат корректность заполняемых данных, вроде min-max это числа

А каком тогда числе речь и откуда это число приходит?

 

[fixxxer]

Не, у него типа-конфиг валидатора-датамаппера-всего сразу. Попытка декларативного программирования.

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

Вон IBM купил построенный на примерно такой же идее StrongLoop за охуллиард зелени, и это у них называется enterprise
Думаю, ТСу стоит выбросить пхп и писать на nodejs, может, по хипстерским меркам тоже ентерпрайз получится.

 

[AmdY]

Да, IBM любит такое, глядя на код автора я даже пустил скупую кровавую слезу, вспомнив страдания с sugarcrm

 

[fixxxer]

Причем оно же вообще нерабочее.
Знакомый js-ер как-то задал мне вопрос, насколько неправильно в структуре country-region-city хранить в табличке городов country_id, типа, без этого не получается выборку сделать. Я, конечно, сначала полчаса его убеждал, что он не разобрался в orm-е этого вашего лупа, что не может такого быть, не могли же полные идиоты это делать. Потом посмотрел на это поделие сам... оказалось, что могли.