cranchzerro
Новичок
Устранений зависимостей от... имён ключей хеш-таблиц о объектах
приветствую!
собственно, имеется проект (первоначальные авторы, называют это CMF... но не суть важно), который мне предстоит поддерживать, и располагаемый некоторым количеством системных объектов, например таких новомодных, как: response, request, controller command и прочее MVC-сословие.
Авторы, видимо, вдохновившись исследованиями различных методологов OOP&D, не до конца проработали все эти понятия и приёмы, и в результате чего имеем - у каждого класса, который есть в ЦМФ, ОБЯЗАТЕЛЬНО присутствует свой интерфейс (в большенстве случаев, нигде не используемый), туча различных Factory, которые в действительности просто Registry include-ащие файл с классом, ну и прочее присутствующее в большенстве движков, моторчиков и турбомоторов вращающих функциональность сайта.
Впринципе, то что имеется работает, ну и Бог с ним... но, этот "движок" (размером в 57кб
теперь моё наследие, отказаться от которого, либо же предлажить альтернативу более граматных авторов (например, та же Simphony) я не могу, так как на этом работает некоторая часть сайтов, и так же, чисто по сугубо внутриштатным обстоятельствам.
Однако, с другой стороны, мне нужно (эта "нужда" - суть так сказать проверочной работы, выполненная мною как специалистом), что-нибудь (вот здесь вот можно сразу в пёрлы "что-нибудь, на своё усмотрение, оптимизировать" (С) Синьор-Программист конторки. Впринципе, оптимизировать что-нибудь, совершенно не проблема, так как двигло совершенно сырое, и не смотря на количество интерфейсов >= количеству классов (совершенно всех классов), зависимостей в этом проекте ну просто немерянно.
Собственно, самая большая, на мой взгляд "зависимость" наблюдается в передаче параметров между методами объектов и, самое мерзское - при хранении различной конфигурационной информации для каждого объекта, далее, в процессе обработки запроса, эти внутренние массивы забиваются на 5-7 уровней различной инфой, например, о компановке страницы, в результате вып. некоторой команды, и все методы объекта, что бы что-то получить или установить, делают следующее ужасное:
кроме того, множество объектов движка, хранятся в некоторых общих объектах, доступ к которым так же осуществляется по подобной ужасной схеме (то есть, через гряду ключ-значение ассоциативных массивов, ака Registry в понятиях этого ЦМФ).
Первым, что я решил "оптимизировать" - это избавиться от такого способа хранения объектов, внутри других объектов, и пожалуй единственный способ, который приходит мне на ум, это замена большенства ключей хешей этих массивов объектами (если не особо сильно менять всю внутреннюю архитектуру "проекта)
вобщем вопросы
1. насколько логично и правильно моё видение этой оптимизации? (если не менять всю структуру напроч)
2. посредством каких приёмов следует уменьшать подобные виды зависимостей (имена ключей в ассоциативных массивах, как имена вложенных "глобальных" объектов ака "звёздные объекты" - объектов, часто используемых прочими объектами)
p.s. про IoC на agiledev читал, Service locator не предлагать...
вобщем спасибо, жду комментов
приветствую!
собственно, имеется проект (первоначальные авторы, называют это CMF... но не суть важно), который мне предстоит поддерживать, и располагаемый некоторым количеством системных объектов, например таких новомодных, как: response, request, controller command и прочее MVC-сословие.
Авторы, видимо, вдохновившись исследованиями различных методологов OOP&D, не до конца проработали все эти понятия и приёмы, и в результате чего имеем - у каждого класса, который есть в ЦМФ, ОБЯЗАТЕЛЬНО присутствует свой интерфейс (в большенстве случаев, нигде не используемый), туча различных Factory, которые в действительности просто Registry include-ащие файл с классом, ну и прочее присутствующее в большенстве движков, моторчиков и турбомоторов вращающих функциональность сайта.
Впринципе, то что имеется работает, ну и Бог с ним... но, этот "движок" (размером в 57кб
теперь моё наследие, отказаться от которого, либо же предлажить альтернативу более граматных авторов (например, та же Simphony) я не могу, так как на этом работает некоторая часть сайтов, и так же, чисто по сугубо внутриштатным обстоятельствам.Однако, с другой стороны, мне нужно (эта "нужда" - суть так сказать проверочной работы, выполненная мною как специалистом), что-нибудь (вот здесь вот можно сразу в пёрлы
"что-нибудь, на своё усмотрение, оптимизировать" (С) Синьор-Программист конторки. Впринципе, оптимизировать что-нибудь, совершенно не проблема, так как двигло совершенно сырое, и не смотря на количество интерфейсов >= количеству классов (совершенно всех классов), зависимостей в этом проекте ну просто немерянно.Собственно, самая большая, на мой взгляд "зависимость" наблюдается в передаче параметров между методами объектов и, самое мерзское - при хранении различной конфигурационной информации для каждого объекта, далее, в процессе обработки запроса, эти внутренние массивы забиваются на 5-7 уровней различной инфой, например, о компановке страницы, в результате вып. некоторой команды, и все методы объекта, что бы что-то получить или установить, делают следующее ужасное:
PHP:
template_name = $this->layoutMap[$layoutKey][$commandName]['commandResults'][$commandResult]['views'][$commandName.'-'.$commandStatus];Первым, что я решил "оптимизировать" - это избавиться от такого способа хранения объектов, внутри других объектов, и пожалуй единственный способ, который приходит мне на ум, это замена большенства ключей хешей этих массивов объектами (если не особо сильно менять всю внутреннюю архитектуру "проекта)
вобщем вопросы
1. насколько логично и правильно моё видение этой оптимизации? (если не менять всю структуру напроч)
2. посредством каких приёмов следует уменьшать подобные виды зависимостей (имена ключей в ассоциативных массивах, как имена вложенных "глобальных" объектов ака "звёздные объекты" - объектов, часто используемых прочими объектами)
p.s. про IoC на agiledev читал, Service locator не предлагать...
вобщем спасибо, жду комментов
