методы добавления к существующему классу - наследование/инъекции

Question

У меня есть десяток сервисных классов, которые были построены для WCF, например:

public class BookingService : IBookingService 
{ 
     public void BookTheThing(int ThingID) { .. } 
} 

Мы стремимся повторно использовать эти классы как прямые библиотеки (не WCF) и создать которая позволит нам сохранить и разоблачить те существующие методы и добавить новые. Вот 2 варианта я придумываю на основе моего ограниченного опыта:

* Вариант № 1 - Вводите оригинальный класс и создать идентичные методы разоблачить его функциональность:

public class BookingServiceNew : IBookingServiceNew 
{ 
    public BookingServiceNew(IBookingService service) { _baseService = service; } 
    public void BookTheThing(int ThingId) { _baseService.BookTheThing(ThingId); } 

    public bool OurNewMethod1(int ThingId) { return true; } 
    public int OurNewMethod2(int ThingId) { return 1; } 

} 

* Вариант № 2 - Наследовать оригинальный класс обслуживания, который будет автоматически выставлять свои методы в рамках класса, а затем добавить наш собственный материал

public class BookingServiceNew : BookingService, IBookingServiceNew 
{ 
    public bool OurNewMethod1(int ThingId) { return true; } 
    public int OurNewMethod2(int ThingId) { return 1; } 
} 

Вариант # 1 кажется, что это будет иметь некоторый код и дублирование, чтобы создавать заглушки для каждого метода в имплантации и интерфейсе. Вариант № 2 кажется, что у него могут быть некоторые проблемы с инъекцией зависимостей на клиенте, где работа с IBookingServiceNew обеспечит доступ только к OurNewMethod1 & OurNewMethod2. Опять же, эти варианты, с которыми я пришел, основаны на моем очень ограниченном опыте, и я буду благодарен вашим мыслям и предложениям за лучший подход/практику/образец.

Благодаря

Answer 1

насчет extension methods?

public static class BookingServiceExtensions 
{ 
    public static bool OurNewMethod1(this IBookingService service, int ThingId) 
    { 
     ... 
    } 
} 

Answer 2

Я бы рекомендовал перейти с вариантом 1 (составом) над наследованием. Да, для этого требуется дополнительный код шаблона, чтобы разоблачить каждый метод внутренней службы. Однако этот код не имеет логики, поэтому мы на самом деле не «повторяем» что-либо. Кроме того, используя композицию, вы получаете тонну гибкости по линии; если вы решите, что не хотите раскрывать один и тот же интерфейс в IBookingServiceNew, как в IBookingService, вы можете просто удалить/изменить эти методы без изменения первоначальной реализации BookingService. Вы также можете легко поменять местами новую реализацию IBookingService (например, макет в модульном тесте).

Напротив, использование наследования классов во избежание использования шаблона позволяет сэкономить некоторый код в краткосрочной перспективе, при больших затратах на гибкость и обслуживание. Во-первых, вы отказываетесь от возможности продлить другой базовый класс в будущем. Теперь ваш класс BookingService должен быть предназначен для наследования; вы должны быть осторожны, какие внутренние методы и состояние подвергаются подклассу, и вам нужно беспокоиться о введении конфликтов с методами в производном классе. В общем, API, открытый классом, который вы ожидаете расширить, намного сложнее и сложнее для потребителя, чем тот, который открывается интерфейсом. Как правило, я стараюсь избегать использования наследования классов, если я фактически не буду использовать полиморфизм (а не только методы из базового класса). В этом случае вы уже используете интерфейсы, поэтому вам не нужно полиморфизм класса.

Наконец, обратите внимание на то, что ваше беспокойство о IBookingServiceNew, не подвергая методам IBookingService, легко устраняется либо (1), либо помещением этих методов на IBookingServiceNew, либо (2) с IBookingServiceNew расширять IBookingService.