Архитектура приложения Flex, как создать библиотеку компонентов, которую можно переопределить

Question

У меня довольно большое гибкое приложение, которое мы только что создали для клиента. Теперь босс говорит мне, что больше клиентов заинтересованы в приложении. Однако для их реализации потребуется несколько небольших изменений (не всегда!).

Мы используем Cairngorm, и из того, что я могу сказать, единственные вещи, которые будут отличаться между клиентами, - это представления. В настоящее время представления находятся в главном приложении flex, а все остальное - в библиотеках.

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

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

В Asp.net вы можете использовать элемент управления «заполнитель», а затем определить во время выполнения, какой элемент управления загрузить. Но я не уверен, как это сделать во Flex.

Как построить эту вещь?

Answer 1

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

Статья и пример кода в Википедии объясняют это лучше, чем я когда-либо мог: Шаблон фабричного метода (см. Заголовок «Инкапсуляция»).

Два возможных недостатка при таком подходе:

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

Answer 2

Независимо от того, что вы собираетесь изменить ссылку на определенный класс где-то. Вы можете создавать подклассы (используя extends) компонентов и затем изменять их поведение, но вы должны изменить свои ссылки, чтобы общаться с подклассом вместо родительского класса.

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