Меню
Что нового?

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

  • Автор темы Автор темы Timol
  • Дата начала Дата начала
Timol написал(а):
Оставлять всякий спам, типа
Нажмите для раскрытия...
От того, что ответ тебе не понравился, он не становится менее информативным.
Ну и вспоминаем поговорку про монастырь и устав.

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

Adelf написал(а):
Я смотрю когда же fixxer наберет критическую массу аргументов, чтобы убедить тебя :)
Нажмите для раскрытия...
Убедить в чем?

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

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

P.S. Спасибо @WMix, @fixxxer и @Sufir за сообщения/советы/ссылки, жаль что эта ветка превратилась в очередную помойку, не относящуюся к теме.
 
Последнее редактирование:
Эх, новички. Тебе уже советовали YAML. тот же JSON можно. Ссылки на доктрину и симфони кидали. Ты вроде лайкаешь, но чегот не видно что ты прочел и внял.
 
Да в принципе, нормально все, этот этап тоже надо пройти. Я когда-то давно тоже пытался написать подобное :)
 
Да почти все пытались. Просто было бы приятно помочь сократить этот период некоторым товарищам.
 
Да чё, нормальная идея, покрывает большинство кейсов для админок. Но я не понимаю, в чём проблема у парня завернуть свои массивы в объекты. Ведь е него это де факто и есть объект, к которому нужно только прикрутить геттеры-сеттеры, можно даже arrayobject имплементировать. Не понятно, на каком шаге у него проблемы с ООП.
 
Вурдалак написал(а):
@AmdY а какое отношение геттеры и сеттеры имеют к ООП?
Нажмите для раскрытия...
Инкапсуляция.В данном случае сеттеры обеспечат корректность заполняемых данных, вроде min-max это числа, а type должен быть из определённого списка значений. Тем самым человек поймёт почему ооп с классами удобнее чем без ооп без них.
 
сам set ничего не делает, те ты сам себя заставляешь написать 2 действия ->set($var)->do(); а можно проще ->do($var) или еще проще ->do() но заинжектить заранее
 
AmdY написал(а):
Инкапсуляция.В данном случае сеттеры обеспечат корректность заполняемых данных
Нажмите для раскрытия...
Это ты нам рассказываешь про секс ради девственности. Сеттеры самым прямым образом нарушают инкапсуляцию.

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

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

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

Вон IBM купил построенный на примерно такой же идее StrongLoop за охуллиард зелени, и это у них называется enterprise :)
Думаю, ТСу стоит выбросить пхп и писать на nodejs, может, по хипстерским меркам тоже ентерпрайз получится.
 
Да, IBM любит такое, глядя на код автора я даже пустил скупую кровавую слезу, вспомнив страдания с sugarcrm
 
Причем оно же вообще нерабочее.
Знакомый js-ер как-то задал мне вопрос, насколько неправильно в структуре country-region-city хранить в табличке городов country_id, типа, без этого не получается выборку сделать. Я, конечно, сначала полчаса его убеждал, что он не разобрался в orm-е этого вашего лупа, что не может такого быть, не могли же полные идиоты это делать. Потом посмотрел на это поделие сам... оказалось, что могли.
 
Войдите или зарегистрируйтесь для ответа.
Сверху