Comments 3
$this->main = &$obj;
Вам не нужно ждать шестой версии, объекты присваиваются и передаются как параметры по ссылкам уже с пятой версии. Если я, конечно, правильно понимаю и это присваение не имеет какого-то более сакраментального смысла.
Вам не нужно ждать шестой версии, объекты присваиваются и передаются как параметры по ссылкам уже с пятой версии. Если я, конечно, правильно понимаю и это присваение не имеет какого-то более сакраментального смысла.
Желание изначально «абстрагироваться» от общепринятой терминологии значительно усложняет процесс восприятия ваших мыслей и доводов. Только на одном обмене и формировании данных логика приложений не заканчивается. Есть очень много здравых идей, но, мне кажется, вы сами себя запутываете пытаясь изобретать новые названия и понятия.
короче если быть кратким — бросьте вы эти попытки изобрести велосипед, лучше еще раз (ну или впервые) прочтите Фаулера и Буча. Освежает мозги и дает пищу для размышлений.
Это что касается теории ).
Ну а по поводу практики есть пару (мелких) замечаний/придирок:
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: Крэг Ларман вам в помощь ).
короче если быть кратким — бросьте вы эти попытки изобрести велосипед, лучше еще раз (ну или впервые) прочтите Фаулера и Буча. Освежает мозги и дает пищу для размышлений.
Это что касается теории ).
Ну а по поводу практики есть пару (мелких) замечаний/придирок:
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: Крэг Ларман вам в помощь ).
Sign up to leave a comment.
Теория Веб-приложений: 2 старых заметки