Главная » C# » Определение ядра в виде интерфейса, а не класса приложения управления освещением в Visual C# (Sharp)

0

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

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

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

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

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

Поэтому структуру необходимо сделать модульной, организованной подобно поканному на рис. 8.5.

Рис. 8.5. Организация модульного интерфейса и архитектура реализации

На рис. 8.5 отдельные прямоугольники представляют одну сборку .NET. Каждая сборка имеет специфичное назначение.

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

•    Сборка user — главное приложение, которое взаимодействует с интерфейсами объектов, реализоваными В сборке Kernel ИЛИ Implementations. Сборка User является ответственной за связывание вместе всех типов (например, присваивие экземпляров интерфейсов ИЗ сборки Implementations сборке Kernel).

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

•    Сборка implementations содержит реализации интерфейсов, которыми манипирует ядро. Допускается одна или несколько сборок implementations. Реалации знают ТОЛЬКО О сборке Definitions, НО не О сборке Kernel.

Источник: Гросс  К. С# 2008:  Пер. с англ. — СПб.:  БХВ-Петербург, 2009. — 576 е.:  ил. — (Самоучитель)

По теме:

  • Комментарии