Сменная архитектура

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

О сменной архитектуре

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

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

Конечные пользователи также получают преимущества от использования приложений со сменной архитектурой:

Плагин является пакетом, добавляющим функциональность к приложению, названному хост-приложением, через некоторую четко определенную архитектуру для расширяемости. Это позволяет сторонним разработчикам добавлять функциональность к приложению, не имея доступа к исходному коду. Это также позволяет пользователям добавлять новые опции к приложению только путем установки нового пакета в надлежащей папке. Модули экранной заставки, предпочтительные области, и палитры Interface Builder, графические фильтры Adobe Photoshop и музыка iTunes visualizers являются всеми примерами плагинов. Вы используете их каждый раз, когда Вы хотите добавить многократные экземпляры определенного типа модуля, обеспечивающего четко определенный модуль функциональности, такой как новый экспорт просачиваются графическая программа, новый стиль перехода в программе редактирования видео или другой тип функции.

Можно думать о хост-приложении как своего рода мозаика с бесконечным числом мест для помещения новых частей. Плагины являются дополнительными частями для присоединения к проблеме, и сменная архитектура определяет форму допустимых частей проблемы. Если плагин имеет неправильную форму, он не может присоединиться к остальной части проблемы. Рисунок 1 иллюстрирует эту метафору: части, что адаптация вносит их функциональность в приложение; не соответствующие части оставляют, свисая в стороне.

  Архитектура Плагина рисунка 1 как бесконечная мозаика

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

Сменная анатомия и расположения

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

Плагины обычно устанавливаются в одном из нескольких стандартных расположений. Можно загрузить их отовсюду, но уровни OS X API включают поддержку нахождения этих стандартных путей.

Стандартные пути следующим образом (где applicationSupportDirectory является каталогом, содержащим файлы поддержки Вашего приложения):

Сменный проект архитектуры

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

В объектно-ориентированных языках разработчики приложений определяют сменную архитектуру — форму позволенных частей проблемы — путем указания требований для пользовательского класса. Эти требования обычно принимают форму абстрактного базового класса или список методов (таких как протокол Objective C). Этот пользовательский класс, известный как основной класс, включен как часть сменного пакета, вместе с другим кодом поддержки и ресурсами. Когда пора загрузить плагин, проверки хост-приложения, чтобы видеть, соответствует ли это требованиям. Если часть соответствует, то приложение просит, чтобы класс — фабрика для экземпляров — генерировал экземпляр. Если плагин не соответствует архитектуре, ее код загружается, но недопустимая фабрика никогда не производит экземпляр.

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

Для более сложного поведения в приложениях Углерода можно использовать Базовую Основу CFPlugIn непрозрачный тип для определения «объектно-ориентированной» архитектуры, работающей и с C и с плагинами C++.

Реализация сменной архитектуры

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

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

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

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

Протоколы

Objective C имеет понятие абстрактного списка методов, отдельных от иерархии наследования классов. Это позволяет разработчику определить связанный набор функциональности, не определяя класс или реализацию для методов. Таким образом, любой класс может реализовать методы, независимо от его места в иерархии наследования. В Objective C эти списки вызывают протоколами. В C++ абстрактные классы, содержащие только чистые виртуальные функции, достигают по существу ту же цель как протоколы через различный механизм.

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

Когда по крайней мере одному из этих трех условий удовлетворяют, необходимо использовать протокол для сменной архитектуры:

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

  2. Сменные разработчики могут хотеть получить сменные основные классы из множества базовых классов.

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

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

Какао дифференцируется между формальными протоколами и неофициальными протоколами. Можно использовать любой тип протокола для определения сменной архитектуры в зависимости от потребностей. Когда класс принимает формальный протокол, он в сущности “подписывает соглашение”, что он реализует все методы в протоколе. Если класс примет протокол, но не реализует все его методы, то компилятор даст предупреждение, и ошибки периода выполнения произойдут, если вызовут нереализованный метод. Формальные протоколы определяются с помощью синтаксиса Objective C, используемого в Перечислении 1 с прототипами метода между @protocol и @end:

Перечисление 1  простой формальный протокол

@protocol MyStringProcessing
 
- (NSString *)processString:(NSString *)aString;
 
@end

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

Перечисление 2  простой неофициальный протокол

@interface NSObject(MyStringProcessing)
 
- (NSString *)processString:(NSString *)aString;
 
@end

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

Абстрактные базовые классы

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

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

Архитектура экранной заставки в OS X является хорошим примером использования абстрактного базового класса. Все экранные заставки делают по существу ту же вещь: они рисуют некоторую анимацию на экране. Большая часть кода должна была привлечь экран, уже обрабатывается классом NSView в Наборе Приложения, таким образом, экранным заставкам не придется повторно реализовать это поведение. Кроме того, все экранные заставки должны кодировать для обработки синхронизации анимации, постепенно появляясь и, и другое поведение. Соответственно, все экранные заставки OS X наследовались от класса ScreenSaverView, добавляющего специфичную для экранной заставки функциональность к классу NSView.

Точка входа и функции обратного вызова

Если Вы пишете приложение Углерода в C, самый простой способ определить сменную архитектуру состоит в том, чтобы определить ряд функций, которые должны реализовать плагины. Это сродни протоколу Objective C, но нет никаких включенных классов, и список функций не определяется явно ни в каком заголовочном файле, но только в документации для сменной архитектуры. Для всех кроме самых простых сменных ситуаций необходимо рассмотреть использование Базовой Основы CFPlugIn непрозрачный тип.

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

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

Хост-приложениям нужен способ фактически найти функцию точки входа или функции к плагину. Это сделано путем определения стандартного имени для функций точки входа и поиска указателя функции для функции с надлежащей подписью во время выполнения. Можно использовать Базовую Основу CFBundle непрозрачный тип для перевода между именами функций и указателями функции.

Для получения информации об использовании CFBundle, чтобы загрузить плагины и искать функции, посмотрите, что Базовая Основа Программирует Руководство по программированию Пакета Темы.

Базовая основа CFPlugIn

Если Вы - разработчик хост-приложения Углерода, необходимо рассмотреть использование Базовой Основы CFPlugIn непрозрачный тип для всех кроме самых простых сменных ситуаций. CFPlugIn освобождает Вас от необходимости разработать, реализовать, и протестировать новую сменную модель самих, потому что CFPlugIn обрабатывает всю основную сменную функциональность для Вас.

CFPlugIn базовой Основы совместим с основами архитектуры Объектной модели компонентов (COM) Microsoft. В этой модели хост-приложение определяет один или несколько типов, что каждый состоит из одного или более интерфейсов. Плагин реализует все функции во всех интерфейсах для каждого типа сменные поддержки, а также “функция фабрики” для генерации экземпляров типа. CFPlugIn имеет преимущество перед Какао использования Универсально Уникальных идентификаторов (UUIDs) для однозначного определения типов, интерфейсов и фабрик, который устраняет конфликты имен и конфликты версий.

Соображения безопасности

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

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

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