согласен. лень создавать десяток-другой однотипных методов и раскидывать логику валидации по ним. Одним из требований, предъявляемых к этому классу, возможность быстро отказаться от его использования не внося изменения в интерфейс класса. Тем самым можно использовать для быстрого прототипирования и введения новых сущностей, окончательная безнес-задача которых не определена. Например у меня есть класс Tourist, который содержит в себе порядка 20 скалярных параметров. 20 сетеров + 20 гетеров писать ой как лень ).
использую для уменьшения дублирования кода. Использую осторожно и не всегда. Если объект содержит большое количество скалярных параметров. Бывает вначале класс использует GenericObject, затем обрастает собственными гетерами/сетерами, а те значения, которые ранее были скалярными, становятся объектами соответствующих классов. Тем самым необходимость в наследовании от этого класса пропадает
в одной из первых версий так и было. на практике оказалось что удобнее так, как сейчас. Ну практика у всех разнаю, возможно в каком-то случае удобнее явно вызывать метод валидации. Ну а я предпочитаю инкапсулировать эту логику, полагаясь на презумпцию невиновности :). Ну а если некорректные данные прошли фронтенд-валидацию, то это явно исключительная ситуация.
Приношу свои извинения, действительно «неудачно выебнулся» :). Пытался вспомнить как называется, в итоге нашел framework.zend.com/manual/en/zend.currency.html упоминание fluide interface и успокоился.
Исправил.
как бы это смешно не выглядело, этот недостаток для меня весьма серьезен. И дело даже не столько в автокомплите. Все неявные динамические решения я стараюсь сводить к минимуму.
мне кажется проблема с конфликтом имен надумана. мне за все время использования этого решения (белее года) не встречалась. Доступ к параметрам с использованием паблик переменных (или их эмуляции) я не использую. Считайте это религиозным убеждением. ;)
Этот класс _не_работает_ с нескалярными параметрами. Это сделано специально. Ассоциативные массивы (тем более многомерные) в интерфейсе я не использую, а для объектов создаю гетеры и сетеры вручную. Параметры по ссылки (имхо) — зло, а объекты по ссылкам и так передаются.
я люблю решения как можно более очевидные. Хотя конечно это дело вкуса, но на мой взгляд конструкция вида $this->_setParams($value); выглядит очевиднее $this->_setParam($value); исходя из той логики которую она выполняет. $this->_initParam — private переменная. Я стараюсь не создавать сущности без необходимости. вероятность повторного использования гетеров и сетеров для этой переменной стремится к нулю.
В силу специфики предметной области в которой я работаю у меня часто появляется необходимость создавать классы с большим количеством скалярных параметров. Работа с ними однотипна (get, set, validate). Если параметров 5 — нужно соответственно 10 почти одинаковых метода. Это усложняет код класса, увеличивает его размер, да и вообще порождает большое дублирование кода. Вот именно в таких ситуациях я и использую данный класс. Использую его очень осторожно, т.к. не люблю такие динамические штуки. Этот класс некий компромисс между желанием избежать сложных динамических решений и нежеланием дублировать рутинные операции.
Класс сделан по принципу Pure Fabrication (чистая синтетика), т.е. не выполняет никакой бизнес-логики. Служит только как вспомогательный инструмент. Набор функциональности отработан на практике и сведен к минимуму для простоты понимания. Именно поэтому используется такой простой (топорный) способ валидации (который, кстати, покрывает 95% потребностей).
Почему абстрактный? А какой должен быть? Класс, экземпляры которого не нужны. При этом он активно использует элементы наследования. Как подобную функциональность можно реализовать другим способом я не знаю.
Постоянная обязательная валидация сделана намеренно. Гарантированно чистых значений не бывает, а если таковые и есть, то они спокойно пройдут валидацию. Это достойная, на мой взгляд, плата за уверенность, что работаешь именно с тем, с чем ожидаешь.
можно еще добавить Мартина Фаулера: рефакторинг и архитектуру корпоративных приложений. я бы даже сначала прочитал рефакторинг фаулера, потом лармана, а потом гамму, хелма и др.
принципы, шаблоны, патерны… Какая разница как называть, определения мало что меняют. Я читал гамму, хелма и сотоваришей, а до этого фаулеровские архитектурные патерны — важно не столько кто и как называет, а то, какой смысл вкладывается в то или иное понятие. Можно наизусть выучить все шаблоны ГоФ, но при этом абсолютно не уметь их применять на практике и по назначению. Книга Лармана, на мой взгляд, хороша тем, что показывает применимость шаблонов на конкретных, приближенных к реальности примерах. Показывает как можно грамотно комбинировать проектные решения чтобы они удовлетворяли основным принципам ооп/а и при этом вписывались в рамки известных шаблонов.
Короче как и в любом другом деле, к чтению книг по ооп нужно подходить с умом. Это не тот случай, где просто тупое копирование и бездумное следование всему, что написано приводит к положительным результатам.
:). А я как раз сейчас последнюю главу дочитываю — очень занимательная книга. После прочтения каждой новой главы появляется стойкое желание заняться рефакторингом старых проектов ).
Желание изначально «абстрагироваться» от общепринятой терминологии значительно усложняет процесс восприятия ваших мыслей и доводов. Только на одном обмене и формировании данных логика приложений не заканчивается. Есть очень много здравых идей, но, мне кажется, вы сами себя запутываете пытаясь изобретать новые названия и понятия.
короче если быть кратким — бросьте вы эти попытки изобрести велосипед, лучше еще раз (ну или впервые) прочтите Фаулера и Буча. Освежает мозги и дает пищу для размышлений.
Это что касается теории ).
Ну а по поводу практики есть пару (мелких) замечаний/придирок:
1. неявный вызов методов у классов усложняет контроль над приложением. call_user_func(array(string $classname, 'view')) в такой операции никак нельзя гарантировать что интерфейс класса $classname имеет метод view. в данном случае, на мой взгляд, проще передавать экземпляр класса Smarty_Handler, а не строку 'Smarty_Handler'
2. var $main; и $this->main = & $obj; — это не красиво). (no comments)
3. выражения типа $this->main->counter->getRange(); существенно подрывают принцыпи слабого связывания. класс, содержащий эту строку, должен знать не только интерфейс объекта main, но и интерфейс counter, на которого он даже в явном виде не ссылается. в дальнейшем подобные проектные решения существенно усложняют рефакторинг и тестирование. Не говоря уже о public properties, которые вобще не являются интерфейсом.
4. call_user_func(array(«Fruits_Objects_Handler», «prepare»), $fruits) полностью равносильно Fruits_Objects_Handler:: prepare($fruits); только читается гораздо хуже. собственно зачем тогда все это?
5 и последнее — примите назад «MVC», «паттерн», «ООП»; используйте типовые реализации Factory и (что немаловажно) не ебите мозг :).
Уверены?
Исправил.
Класс сделан по принципу Pure Fabrication (чистая синтетика), т.е. не выполняет никакой бизнес-логики. Служит только как вспомогательный инструмент. Набор функциональности отработан на практике и сведен к минимуму для простоты понимания. Именно поэтому используется такой простой (топорный) способ валидации (который, кстати, покрывает 95% потребностей).
Почему абстрактный? А какой должен быть? Класс, экземпляры которого не нужны. При этом он активно использует элементы наследования. Как подобную функциональность можно реализовать другим способом я не знаю.
Постоянная обязательная валидация сделана намеренно. Гарантированно чистых значений не бывает, а если таковые и есть, то они спокойно пройдут валидацию. Это достойная, на мой взгляд, плата за уверенность, что работаешь именно с тем, с чем ожидаешь.
Короче как и в любом другом деле, к чтению книг по ооп нужно подходить с умом. Это не тот случай, где просто тупое копирование и бездумное следование всему, что написано приводит к положительным результатам.
Видимо автор оттуда идеи черпал (некоторые фразы и речевые обороты очень знакомы).
Советую почитать.
короче если быть кратким — бросьте вы эти попытки изобрести велосипед, лучше еще раз (ну или впервые) прочтите Фаулера и Буча. Освежает мозги и дает пищу для размышлений.
Это что касается теории ).
Ну а по поводу практики есть пару (мелких) замечаний/придирок:
1. неявный вызов методов у классов усложняет контроль над приложением. call_user_func(array(string $classname, 'view')) в такой операции никак нельзя гарантировать что интерфейс класса $classname имеет метод view. в данном случае, на мой взгляд, проще передавать экземпляр класса Smarty_Handler, а не строку 'Smarty_Handler'
2. var $main; и $this->main = & $obj; — это не красиво). (no comments)
3. выражения типа $this->main->counter->getRange(); существенно подрывают принцыпи слабого связывания. класс, содержащий эту строку, должен знать не только интерфейс объекта main, но и интерфейс counter, на которого он даже в явном виде не ссылается. в дальнейшем подобные проектные решения существенно усложняют рефакторинг и тестирование. Не говоря уже о public properties, которые вобще не являются интерфейсом.
4. call_user_func(array(«Fruits_Objects_Handler», «prepare»), $fruits) полностью равносильно Fruits_Objects_Handler:: prepare($fruits); только читается гораздо хуже. собственно зачем тогда все это?
5 и последнее — примите назад «MVC», «паттерн», «ООП»; используйте типовые реализации Factory и (что немаловажно) не ебите мозг :).
ps: Крэг Ларман вам в помощь ).