Количество методов в классе, количество строк.

[fixxxer]

Так я и не говорю, что это проблема, это как раз одно из направлений решения проблем.

А паттерны - это, вообще, хорошо, просто не надо копипастить 1 в 1 с джавы, где многие паттерны обусловлены свойствами языка (например, строгой типизацией). Скажем, ту же абстрактную фабрику со switch-ем тащить в php - это довольно глупо, ведь можно просто сделать new $class_name. Просто надо воспринимать ширше, как подход к решению архитектурной проблемы, а не как Единственно Правильный Кусок Кода.

Не очень хорошо помню, что там у Котерова, вроде он там в плане template engine какой-то сомнительный велосипед предлагает. Может и неплохой, просто слишком много внимания как для книги уделено собственному велосипеду, а не рассмотрению существующих решений.

 

[caballero]

Скажем, ту же абстрактную фабрику со switch-ем тащить в php - это довольно глупо, ведь можно просто сделать new $class_name

Глупо это делать даже в яве. Паттерны - это абстракции разложеные для понимания сути. Это не значит что на каждый кубик в UML нужно городить класс. А решается это не new $class_name (для этого фабрика не нужна) а статическим фабричным методом создающим и возвращаюшим екземпляр. Класический пример - получение инстанса в синглтоне.

Не очень хорошо помню, что там у Котерова, вроде он там в плане template engine какой-то сомнительный велосипед предлагает.

нет, это там на сайте у них какие то парсеры и прочая муть (лучше бы денвер 4 доделали наконец). Я имел ввиду главу (кажется 46) где объясняется что такое шаблоны, MVC и как должно быть по уму

 

[fixxxer]

Дык. Любая литература - это информация к размышлению, а не руководство к действию. С бездумной копипастой далеко не уедешь в любом случае. =) Головной мозг никто не отменял.

 

[AmdY]

А решается это не new $class_name (для этого фабрика не нужна) а статическим фабричным методом создающим и возвращаюшим екземпляр.

В том то и дело, что в php несколько иные паттерны, которые решаются фичами самого языка, new $className, $object->{$methodAsString}(), __get, __set, __call, call_user_function_array, лямбда функции, traits, автолодер и т.д.
И плевать что у нас MVC не правильный, это только плюс языку, он другой нежели smalltalk или java и это делает его сильным в решении задач под веб, да и от шаблонизатора он уже давно ушёл, версии этак в третьей.

 

[A1x]

Я тут сам в этом треде контроллерами называю то, что ими называют обычно (так называемые page controllers), сам же это название не люблю. Если внимательно посмотреть на MVC, то C применительно к вебу - это на самом деле то, что в веб-фреймворках называется front controller. Потому вполне можно "page controller" переименовать во view и не париться.

Неспроста напр. в кохане базовый контроллер называется Controller_Template, что говорит о том что граница между page controller и view весьма размыта,
с другой стороны page controller выполняет функции Builder который строит view , используя данные полученные от front controller

если убрать page controller то кто будет строить view и где будет выполняться само действие (action)?

 

[caballero]

И плевать что у нас MVC не правильный

с MVC проблем нет, проблеммы с паттерном MVC который нагородили индусы в ЗЩенде а остальные тупо скоприровали а теперь не знают что с ним делать.

да и от шаблонизатора он уже давно ушёл, версии этак в третье

Серьезно? То есть код

<? if($hello) {?>
<span>Hello dude!</span>
<? } ?>

уже не работает?
Все проблемы с PHP что его используют не по назначению. К убогому ООП добавили через задницу сделаные замыкания и трейты которые непонятно куда приткнуть

с другой стороны page controller выполняет функции Builder который строит view , используя данные полученные от front controller

а нет никакой другой стороны - page controller и есть view. и реализуется как я уже намекал активным шаблонизатором который называется PHP.
Все остальное - от лукавого.

 

[Redjik]

caballero
Мы поняли твою позицию, что правильно делать только как у Котерова и пхп говно и недоязык.
Может хватит нам уже в мозг срать?

 

[caballero]

Мы поняли твою позицию, что правильно делать только как у Котерова

Правильно делать так как правильно неважно у кого

и пхп говно и недоязык.

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

Может хватит нам уже в мозг срать?

может напишешь чего по теме хоть для разнообразия.

 

[AmdY]

caballero
MVC в php был задолго до появления Zend Framework, не путай.

Твой код доказывает что php не шаблонизатор. Это синтаксический сахар и внутрях эта конструкция аналогична

<? if($hello) {
echo "<span>Hello dude!</span>";
} ?>

К убогому ООП добавили через задницу сделаные замыкания и трейты которые непонятно куда приткнуть

трейты убирают копипаст, я уже нашёл куда их приткнуть и это очень помогло. замыкания есть и работают, опять же они очень здорово помогают расширять функционал, особенно после допиливания биндинга к классу. И ООП в php очень даже прилично сделан, я думал эти нападки остались лет этак пять как в прошлом.

Перейдя на php 5.4 c 5.2 я прочувствовал какой огромный шаг сделан, а ведь язык и так был самым-самым в вебе и становится только лучше, на нём писать и поддерживать проекты всё удобнее, а вы занимаетесь брюзжанием.

 

[Redjik]

caballero
1) Кто решает как делать правильно?
2) Какое назначение у PHP?
3) Я уже достаточно написал по теме, а то, что ты со своим ЧСВ срешь в каждый комментарий, настраивая всех против тебя, явно не указывает на то, что жизнь на этом форуме у тебя будет долгая и безоблачная.
Да, у тебя почти весь срач по теме, но от этого он не становится меньшим срачем.

 

[Духовность™]

пятый раз прошу - забаньте его

 

[AmdY]

Духовность™
зачем банить - мешок на голову в лес и растрелять, раз точка зрения не сходится с нашей. вот негодяй.

p.s. Я на работе так и делаю, пару выстрелов из нерфа и ничего не нужно доказывать

 

[Духовность™]

AmdY
у него нет точки зрения, он тролль. хотя в лес тоже хорошо.

 

[A1x]

caballero page controller еще инициализирует объект Response, которому передается view и какие-то заголовки
page controller играет роль связки между front controller, view, Response, можно конечно все это засунуть в один God - класс

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

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

 

[Ragazzo]

AmdY
Да ты прям как "Батька", тех в лес расстрелять, этих посадить не кормите тролля просто уже

 

[AmdY]

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

 

[caballero]

пятый раз прошу - забаньте его

тебе папа с мамой разрешают гулять так поздно и встрявать в разговор взрослых дядей?

Твой код доказывает что php не шаблонизатор

это твой код не шаблонизатор а то как я написал именно шаблонизатор. и в этом изначальных смысл PHP. Выводить Html принтами неплохо и перл справлялся и С в CGI страницах.

трейты убирают копипаст, я уже нашёл куда их приткнуть и это очень помогло

.
мне помогает не делать копипаст

замыкания есть и работают

хреново работают если я должен перечислять замыкаемые переменные. Смысл замыкания - доступ к контексту внешней функции. Если мне надо передавать контекст параметрами - такое замыкание нафиг не нужно и обычной функцией обойдусь.

И ООП в php очень даже прилично сделан,

ООП - это не синтаксис и не ключевое слово class. Отсутствие долгоживущих объектов сводит смысл ООП к структуированию кода и автолоадеру.

Перейдя на php 5.4 c 5.2 я прочувствовал какой огромный шаг сделан,

я перешел с PHP3 на котором начинал - я в курсе какой шаг сделан.

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

это касается всех современных языков.

 

[fixxxer]

С замыканиями вообще сложная история. По нормальному функции и методы надо делать lvalue, но это за собой повлечет коренную переделку языка. Потому костылик. Ты еще реализацию не смотрел, ну туда действительно лучше не смотреть (тонко намекну, что create_function это почти то же самое). Но хочу заметить что замыкания к ООП отношения не имеют.

Хочешь красивый современный язык с продуманной реализацией ООП/ФП-плюшек - бери Скалу, йопт. php это такая система костыликов, на которой, обмешав немного своими костыликами, можно на удивление быстро и удобно делать веб-проекты. За эстетикой не сюда точно.

 

[caballero]

page controller еще инициализирует объект Response, которому передается view и какие-то заголовки
page controller играет роль связки между front controller, view, Response, можно конечно все это засунуть в один God - класс

Ну это ваша конкретная реализация - я не в курсе что какие классы там делают.

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

В любом случае классический паттерн MVC не получается никак. Либо нужен главный рулевой фронт контроллер, либо HMVC либо еще как то.
Самая разумная схема как мне кажется - главный контролер (фронт-контроллер, роутер) который управляет приложением и отвечает за жизненный цикл страниц, представление - контроллер логики каждой страницы (PHP в его классическом виде) то есть представлениЯ
И слой (модель хотя название не лепится) несущественно как реализована потому как на PHP сайтах редко бывает сложная бизнес логика, а когда бывает берут сервер приложений на яве или типа того.

 

[AmdY]

это твой код не шаблонизатор а то как я написал именно шаблонизатор.

этот код аналогичен в опкодах, всего лишь ещё один вид вывода строки.

Отсутствие долгоживущих объектов сводит смысл ООП к структуированию кода и автолоадеру.

В демонах вполне себе долгоживущие объекты используются. И с точки зрения ООП особой разницы нет, разве что потоки и паттерны работы с ними, но это не проблема ООП.

Про замыкания, согласен, неудобно что нужно передавать контекст самостоятельно. Но это как раз отсутствие синтаксического сахара, но не отсутствие функциональности. А вот обычной функцией её не заменишь, т.к. контекст так не передашь.

мне помогает не делать копипаст

А чем его заменяешь - наследованием? Этот вариант мене контролируемый, так как трейты позволяют указывать что наследовать, менять видимость, меня имена и избегать коллизий.