Ну, это звучит так же, как инкапсуляция (класс-оболочка) и абстракция (интерфейс).
Однако, если у вас есть интерфейс, вы можете , а затем использовать шаблон декоратора.
Строго говоря, при использовании декоратора каждый слой имеет такой же интерфейс; Декорация, по сути, представляет собой последовательную цепочку из различных конкретных классов, которые (при реализации интерфейса) либо передают метод к ссылке next в цепочке, либо делают что-то сделанное на заказ.
( update : я не говорю, что должен сделать это таким образом - это всего лишь пример того, как шаблон декоратора может работать в контексте оригинального e почта)
Например, у вас может быть интерфейс IEmail
, базовая реализация BasicEmail
(которая использует встроенный код .NET), LoggingEmail
, который принимает IEmail
и просто передает данные ( но регистрирует вещи по ходу дела) и ForwardingEmail
, который принимает IEmail
и изменяет To
и т. д. (возможно, для целей dev / test / live).
Тогда вы могли бы иметь:
`ForwardingEmail` => `LoggingEmail` => `BasicEmail` => (regular .NET classes)
(где первые три известны только как IEmail
)
Это позволяет расширить функциональность без изменения API. Очень часто встречается в заводских / IoC-установках, и особенно в AOP.