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

[Савелей]

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

Есть MainСlass у него есть расширения в виде модулей админки, фронта...

есть модули которые используют друг друга, к примеру модуль X-fields (который отвечает за создание, изменение полей в БД. других модулей)

как правильно создать управление этим модулем???

управлять "x-fields" из каждого модуля отдельно
или из "x-fields" каждым модулем.

 

[x-yuri]

ты бы подробнее рассказал, что включяает в себя "управление"

p.s.

Есть MainСlass у него есть расширения в виде модулей админки, фронта...

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

 

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

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

ты его пытаешься упрекнуть? что в этом плохого?

который отвечает за создание, изменение полей в БД.

зачем это нужно? для этого есть phpmyadmin.

 

[x-yuri]

ты его пытаешься упрекнуть? что в этом плохого?

наследование - это более сильная связь по сравнению с композицией. Наследование - protected-доступ, использование внешнего класса - public. Кроме того, при наследовании реализации можно считать, что потомок включает в себя код родителя, т.е. класс во-первых на самом деле больше, а во-вторых рискует выполнять много обязанностей. И все это называется низкое сцепление кода (Low Cohesion), высокая связанность кода (High Coupling). Считается, что наоборот - лучше (http://wiki.agiledev.ru/doku.php?id=ooad:manage_dependencies_in_php_code)

 

[StUV]

Считается, что наоборот - лучше

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

другое дело, что из вопроса тредстартера нифига непонятно - что у него есть и что он с этим хочет сделать =)

 

[x-yuri]

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

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

-~{}~ 30.01.09 10:27:

StUV а как определить, важно это для проекта или нет?

 

[StUV]

x-yuri
если функционал класса не выделается в class-toolkit - т.е. его набор операций ограничен операциями над объектами "собственного типа" - то имеет смысл эти операции оставить в иерархии наследования типа и не выносить в отдельную функциональнеую иерархию - имхо, так проще потом отслеживать область ответственности отдельных компонентов системы

у автора, насколько я понимаю, сложность в определении родства типов "вообще" - т.е. он наследует от общего Main все возможные модули в рамках одного дерева, хотя, очевидно, здесь должен быть лес с разделением на модули view/event/...

возможно обязать все классы реализовать базовый интерфейс
вот здесь уже имплементация возможна через агрегирование некоторой иерархии "тулкитов"

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

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

 

[Савелей]

Автор оригинала: triumvirat
ты его пытаешься упрекнуть? что в этом плохого?



зачем это нужно? для этого есть phpmyadmin.

для того что-бы не плодить модули с одним и темже функционалом к примеру: базовый модуль каталог прекрасно преобразуется как "новости" но у него свои таблицы БД, настройки, вьюха. пользователь в 2-3 клика из админки получает готовое решение. но физически это базовый модуль каталог.


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

Вы уж меня простите нуба

 

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

базовый модуль каталог прекрасно преобразуется как "новости" но у него свои таблицы БД, настройки, вьюха. пользователь в 2-3 клика из админки получает готовое решение.

брюки превращаются.. брюки превращаются...

 

[Савелей]

наглядный пример того к чему иду:

a-cms и openconstructor.org

 

[x-yuri]

Савелей так а управление что в себя включает? и кто кого использует? X-fields другие модули или наоборот?

 

[Савелей]

Так написал выше, модули управляют.

 

[x-yuri]

Савелей я вообще-то не один вопрос задал ;-) на данный момент не вижу необходимости им управлять как отдельным модулем. Мне вообще пока сомнительным кажется упоминание его пользователю. Но может я просто не знаю, что подразумевается под управлением?

 

[StUV]

наглядный пример того к чему иду:

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

возможно, пользовательский функционал там нормальный (не знаю, не видел), но код ужасный (за код второго вообще руки отрывать надо)

-~{}~ 30.01.09 18:43:

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

 

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

возможно, пользовательский функционал там нормальный

Для IE: http://www.openconstructor.org/openconstructor/login.php?next=%2Fopenconstructor%2F
demo
demo

имхо - куйня