Когда использовать многократные пакеты

Компоненты в основе модели объектно-ориентированного программирования. Вместо монолитной, переплетенной путаницы кода, хорошо разработанные приложения накоплены от компонентов, каждый из которых обрабатывает некоторый четко определенный модуль функциональности. Это структурирование происходит на многих уровнях от простых объектов данных до больших автономных компонентов, таких как интегрированные средства просмотра HTML. Даже большинство приложений, записанных на «необъектно-ориентированных» языках как C, показывает этот вид структуры.

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

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

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

Путем создания каждого компонента как его собственного загружаемого пакета Вы получаете несколько преимуществ:

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

• Вы можете смешивание и подгонка различные версии компонентов только путем перемещения пакетов файла.

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

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

Кроме того, приложения Какао не могут разгрузить пакеты. Если Вы хотите быть в состоянии загрузить и разгрузить большие отдельно созданные компоненты приложения, можно создать приложение как многие меньшие исполнимые компоненты, и главное приложение может разветвить дочерние процессы. Можно включить коммуникацию между процессами с распределенной архитектурой объектов Какао. Для получения дополнительной информации посмотрите Распределенные Объекты Программировать Темы.

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

Организация приложения мультипакета

Для эффективной организации приложения в многократные пакеты необходимо помнить несколько вещей:

• Трудно управлять сложными взаимозависимостями между загружаемыми пакетами, поэтому организуйте свое приложение в в основном автономные, независимые модули. Самый простой способ сделать это для каждого пакета, чтобы содержать ссылку на отдельный объект в другом пакете — в Какао, обычно основной класс — и использовать его для доступа к любой другой функциональности и данным.

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

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

Например, возвратитесь к приложению баннера/карты/новостной рассылки, описанному в том, Когда Использовать Многократные Пакеты. Согласно этим инструкциям, это целесообразно организовывать приложение в четыре загружаемых пакета: один для контроллера главного приложения, и один каждый для этих трех подприложений. Кроме того, возможно, приложение имеет много различных способов составить текст: в кругу, в форме зебры, и т.д. Обеспечение сменной архитектуры для текстовых методов рисования сделало бы задание разработчика приложений проще и позволило бы третьим лицам добавлять опции как рисование текста с трехмерными эффектами.