Это вторая из серии статей, в которой рассматривается система типов Inversion of Coupling Control для композиции. В этой статье обсуждается более общая система типов модулей, чем в процедуре первого класса, описанной в предыдущей статье.
Примечание: некоторые функциональные языки программирования также пытаются определить первоклассные модули. Модули первого класса, определенные в этой статье, создаются из инвертированных функций .
Первоклассная процедура
Напомним, что в последней статье тип процедуры первого класса определяется следующим образом. Обратите внимание, что мы исключаем тип зависимости, так как зависимости устанавливаются автоматически.
|
1
2
3
4
5
6
7
8
9
|
FirstClassProcedureType { Class<?> parameterType; ContinuationType[] continuations;}ContinuationType { String name; Class<?> argumentType;} |
Это определяет Первоклассную Процедуру, чтобы иметь один входной параметр и несколько продолжений для дальнейшей композиции логики и обработки исключений.
модуль
Наличие одного входа с несколькими выходами отлично подходит для методов, функций и т. Д., Заключенных в процедуры первого класса. Однако, когда системы растут, мы не хотим, чтобы сложность заставляла входы / выходы страдать с аналогичной повышенной сложностью. Мы хотим, чтобы входы / выходы предоставляли интерфейс для инкапсуляции сложности модуля. Обратите внимание, что без инкапсуляции мы не получим возможность модульной сложности приложения.
Чтобы включить интерфейс для модуля, давайте создадим следующие типы ввода / вывода:
|
1
2
3
4
5
6
7
8
9
|
InputType { String name; Class<?> parameterType;}OutputType { String name; Class<?> argumentType;} |
Чтобы понять, почему создаются эти типы, мы собираемся использовать визуальную конфигурацию Inversion of Coupling Control, чтобы лучше понять происходящее.
Следующая конфигурация модуля представляет один вход, обрабатываемый процедурой первого класса, которая отправляет свой результат на выход:
В приведенной выше конфигурации процедура первого класса инкапсулирована в модуле. Все, что раскрывается из модуля, это входы и выходы. В результате тип вышеупомянутого модуля будет следующим:
- Ввод с именем «Ввод» с параметром, переданным в процедуру первого класса
- Выход с именем «Выход» с аргументом, предоставленным результатом выполнения процедуры первого класса.
Это, однако, обеспечивает небольшое улучшение интерфейса процедуры первого класса.
Что становится полезным, так это инкапсуляция нескольких первоклассных процедур для выполнения функциональности модуля:
Хотя в модуль была включена новая процедура, интерфейс модуля не изменился. Другая конфигурация, использующая Модуль, не будет знать о внутреннем добавлении другой Первоклассной Процедуры.
Нам также не нужно ограничиваться отдельными входами и выходами. Мы могли бы иметь произвольно сложный модуль, который имеет несколько входов и выходов:
Полученный модуль инкапсулировал детали, чтобы иметь следующий интерфейс:
- Вход «Вход»
- Вход «Вход-2»
- Вывод «Вывод»
- Выход «Выход-2»
- Выход «Выход-3»
Тип модуля
Полученный тип для Модуля следующий:
|
1
2
3
4
|
SectionType { InputType[] inputs; OutputType[] outputs} |
Обратите внимание, что наименование OfficeFloor основано на его фундаменте бизнес-концепций и впоследствии называет Модуль «Разделом».
Модуль (секция) имеет несколько входов и несколько выходов. Эти входы / выходы могут быть подключены к соответствующим выходам / входам других модулей.
Кроме того, модули могут сами содержать другие модули. Поскольку входы / выходы подключены для композиции, модули имеют такое же соединение входа / выхода, как процедуры первого класса. Следующая конфигурация демонстрирует встраивание модуля в начале этой статьи в другой модуль:
Будь то Модуль, содержащий одну Процедуру Первого класса или две Процедуры Первого класса, инкапсулирован и не имеет значения в вышеуказанной конфигурации. Использование модуля только на входах / выходах, выставленных модулем. Остальная часть сложности модуля заключена в капсулу. Это позволяет модулировать сложность приложения.
Первоклассный модуль
Таким образом, в названии упоминаются «Модули первого класса», но мы обсуждали только визуальное соединение модулей.
Чтобы по сути быть «Первоклассным», модуль должен быть назначен переменной.
Хорошо, вышеупомянутая графическая конфигурация построена на разделах (модулях), которые конфигурируются вместе программно. Графическая конфигурация на самом деле является слоем над первоклассными модулями (разделами), чтобы облегчить понимание того, как приложение модульно.
Вы можете увидеть это в реализации OfficeFloor графической конфигурации, использованной выше в этой статье. Выше графическая конфигурация через активность. Деятельность — это конкретная специализация Раздела ( здесь источник ActivityLoaderImpl ). Упражнение переводит XML из графической конфигурации в создание разделов, первоклассных процедур, входов, выходов. Каждый из них в реализации Activity назначается переменным, хранится в структурах данных, передается в функции, возвращается из функций и т. Д. Это делает Раздел (Модуль) по существу «Первоклассным».
Этот интерфейс ввода / вывода, основанный на продолжениях, чрезвычайно гибок. Это настолько важно, что процедуры первого класса сами по себе являются просто специализированной реализацией раздела ( см. «MethodEmployer» ).
Резюме
Мы видели, как мы можем инкапсулировать процедуры первого класса в модулях первого класса и даже в модулях первого класса внутри себя.
Мы показали, как графическая конфигурация на самом деле использует природу «первого класса». Графическая конфигурация на самом деле является композицией более высокого уровня, которая обеспечивает оба:
- легче понять модульность приложения
- более быстрая настройка приложения (фактически просто нарисуйте линии для композиции)
Обратите внимание, что вполне возможно программно настроить наше приложение. Однако для этого требуется более глубокое понимание процедур и модулей первого класса. Гораздо больше, чем может понадобиться начинающим разработчикам.
Следовательно, графическая конфигурация модулей первого класса обеспечивает простоту построения модульных приложений. Это без необходимости иметь дело со сложностью базовых конструкций. Что-то, что я нахожу с другими композиционными стратегиями, все еще вызывает проблемы
В следующей статье мы рассмотрим, как первоклассные модули могут предоставлять состав различных существующих стратегий составления. Вы можете обнаружить, что существующие стратегии компоновки действительно учитывают программирование только в малых, а не в программировании в больших масштабах — где первоклассные модули становятся намного более эффективными в модульности и упрощении ваших приложений.
|
Смотрите оригинальную статью здесь: Первоклассная система типов модулей для композиции Мнения, высказанные участниками Java Code Geeks, являются их собственными. |