Zend Framework наследование

[Димон]

Zend Framework наследование

Те кто работает с Zend Framework знают, что он состоит из множества классов. Большинство из них существуют обособленно.
В реальной среде иногда возникает необходимость изменить поведение некоторых классов под конкретный проект. Полагаю, что наиболее разумное решение - это создать новый класс, наследуемый от класса Zend_... и переопределить или добавить необходимые аттрибуты и методы. Это позволит не "хачить" сам фреймворк и в дальнейшем легко его обновлять, не переделывая все заново, да и плюс добавляет прозрачный уровень абстракции.
Но Zend часто использует статические методы для инстанцирования классов и соответственно вызывает классы Zend_... в обход наследуемого класса. Происходит это не везде, но довольно часто. Искать эти вызовы и править не выход.
Есть ли у кого-нить какие-нить соображения по этому поводу? Т.е. как унаследоваться от Zend'овских классов, так чтобы в первую очередь вызывались именно дочерние классы.

 

[AmdY]

рано взялся за zend framework, разберись сразу с самим ООП, почитай доку по zf, разберись с автолодером

 

[Димон]

Это что, прикол? Меня не надо учить, что мне делать. Я задал вполне нормальный вопрос. Те кто не знает на него ответа пусть себя учат, а не других.
П.С. С ZF я уже давно работаю и прекрасно в нем ориентируюсь. А этот вопрос встал ребром ввиду нетривиального проекта, который решили делать полностью на ЗФ. А автолоадере есть строка, в которой можно указать пути и названия класса, но, как я уже писал, есть статические методы, которые явно вызывают именно Зенд классы.
П.С. Никогда не понимал людей, которые из ООП делают культ. Это всего лишь подход, методика, которая дает преимущество по сравнению с обобщенным и процедурным программированием, но только там где она реально подходит. Недальновиден тот, кто фанатично работает под одним углом. Если бы в литературе по прогр. не лили воду, а писали по существу, с реальными, рабочими примерами, и учили, что писать правильно - это не только красиво, но и выгодно, то не было бы тогда столько говнокода, типа DLE или Bitrix. Приходится по работе возиться с одной такой хренью. Убил того кто это написал.
Пардон за оффтопик.. накопилось просто.

 

[korchasa]

Re: Zend Framework наследование

Автор оригинала: Димон
...
Но Zend часто использует статические методы для инстанцирования классов и соответственно вызывает классы Zend_... в обход наследуемого класса. ...

Написать свои версии этих методов. И если вы пишете клиентов этих методов, то использовать свой класс, а если клиенты где-то внутри zf, то подменять классы, с помощью autoloader.

 

[AmdY]

Димон
просто в Zend Frameworke всё ясно написано как делать
lib
--Zend
----Class.php (Zend_Class)
--Dima
----Class.php (Dima_Class)

Dima_Class extends Zend_Class {}

там вся структура расчитана на это и нигде не нужно хачить

-~{}~ 25.02.09 22:12:

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

Задолбали люди "знающие" ООП и размышляющиеся о его минусах, хотя даже плюсами научиться польоваться не могут.

 

[Димон]

Amdy, мы именно так и делаем, расширяем как описано в мануале. И говнонадстройки никто писать не собирался. И как ты можешь рассуждать об архитектуре, даже не видя ее?

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

По поводу ООП. Я писал о том, что говнокод это плохо, а не ООП плохо. Ум, опыт и хороший вкус ничто не заменит, даже ООП.

В общем можно "бодаться" до посинения. Если ты сто раз напишешь, что ты классный кодер, я тебе не поверю, то же самое и с твоей стороны.

 

[Royal Flash]

Пишите свои классы, не используя чужие - все проблеммы отпадут. А то Вам и обновления подавай, и чтобы они еще с вашими скриптами дружили - так не бывает, если Вы, конечно, не в команде разработчиков Zend

 

[HraKK]

Вы все несете чуть, тут Димон прав.

 

[AmdY]

Димон
если у тебя есть желание залезть в ту часть кода в которую тебе не дали возможность лазать, знат ты хочешь херню. Везде, где надо и можно подменить зендовский класс используется:
а) наследование
б) передача объекта наследующего зендовский же интерфейс
в) передача названия клаасса как параметра, причём он сново же должен наследовать интерфей.

 

[korchasa]

Автор оригинала: AmdY
Димонесли у тебя есть желание залезть в ту часть кода в которую тебе не дали возможность лазать, знат ты хочешь херню...

Из чего следует такой вывод?

 

[AmdY]

korchasa принцип чёрного ящика.

 

[korchasa]

Автор оригинала: AmdY
korchasa принцип чёрного ящика.

Хорошо, поясню на примере. Не знаю, как сейчас, но раньше в zf нельзя было получить из базы кастомную коллекцию, только их версию rowSet. Твоими словами, если я хочу кастомную коллекцию, то я хочу херню?

 

[Zh0rzh]

korchasa, кастомную колекцию можно указывать можно было уже начиная с 1.0 версии (с раньшими не работал). См. здесь http://zendframework.com/manual/ru/zend.db.table.html#zend.db.table.extending


AmdY, вы не вникли в суть проблемы топик стартера.
ZF статически вызывает методы своих (Zend_*) классов. Простым наследованием логику приложения не переопределишь, поскольку Zend все равно будет вызывать свои классы.

 

[korchasa]

Автор оригинала: Zh0rzh
korchasa, кастомную колекцию можно указывать можно было уже начиная с 1.0 версии (с раньшими не работал). См. здесь http://zendframework.com/manual/ru/zend.db.table.html#zend.db.table.extending

А мне приходилось именно с ранними. Суть не в этом, а в том, что все потребности по гибкости удовлетворить нельзя, и всегда найдется круг задач, для которых либо придется писать много, либо "хачить". Но называть все такие задачи херней, это явно не правильно.

 

[AmdY]

korchasa
на самом деле всё делается легко, копируешь Zend_Db_* в свою директорию
Dima
--Db.php
--Db
и получаешь класс Dima_Db_* и потрошишь его как хочешь, у тебя получается форк, который затем можно либо мержить с обновлениями, либо, что скорее всего, он получится несовместимым с Zend_Db_*
При этом нельзя самообманываться, что ты пользуешься Zend_Db, так как его результат и поведение не соответствует результатам и поведению, документированными в доке зенда.

 

[Димон]

Ладна, тему нормального наследования пока оставим в покое. Решили немного "похачить", пометив эти место как "TODO". Мож осенит кого-нибудь.
Седня занимался другой фичей - скрещивал движок DLE и зенд фреймворк. Причем зенд юзает кодировку utf8, а дле cp1251. В целом это не проблема, тока в одном проекте под ide (zend studio) хреново их "склеивать". Но это уже другая история. напишу об этом в другой теме, как только будут полностью рабочие результаты. Можь кому-нить пригодится.

 

[HraKK]

Димон
Напиши обязательно, спасибо. Мне правда не надо, но думаю другим поможет.

 

[AmdY]

Димон
так не хачил бы, а вынес бы в атрибут, сделал для него сетер-гетер и предложил бы зендовцем, труд бы напрасно не пропадал.

 

[jonjonson]

скрещивал движок DLE и зенд фреймворк

Сама фраза по себе идиотская. Фреймвок можно использовать при написании скриптов, встраиваемых в CMS. Можно переписать часть кода CMS используя фреймвок.

Скрещивать же можно что-то подобное. CMS и CMS. Фреймвок и фреймвок.

Переписывать же код DLE используя ZF... Это в юмор.

 

[Димон]

Автор оригинала: jonjonson
Сама фраза по себе идиотская. Фреймвок можно использовать при написании скриптов, встраиваемых в CMS. Можно переписать часть кода CMS используя фреймвок.
Скрещивать же можно что-то подобное. CMS и CMS. Фреймвок и фреймвок.
Переписывать же код DLE используя ZF... Это в юмор.

Эти каноничекие высказывания прибереги для более подходящего случая. В идеальном мире кодинга, так бы все и было.

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

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