Question

我有十几个为WCF构建的服务类，例如：

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

我们的目标是将这些类重用为直接库（而不是WCF）并创建一个单独的服务库，以便我们保留和公开这些现有方法并添加新方法。根据我有限的经验，我有两种可能性：

*选项＃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＆amp;的访问。 OurNewMethod2。同样，我带来的这些选项都是基于我非常有限的经验，我将非常感谢您对更好的方法/实践/模式的想法和建议。

由于

Answer 1

我建议使用选项1（组合）而不是继承。是的，这需要额外的样板代码来公开内部服务的每个方法。但是，这段代码没有逻辑，所以我们并没有真正“重复”任何东西。此外，通过使用合成，您可以获得更大的灵活性;如果您决定不希望在IBookingService中公开与IBookingService中相同的接口，则只需删除/更改这些方法，而无需修改原始的BookingService实现。您还可以轻松交换IBookingService的新实现（例如，单元测试中的模拟）。

相比之下，使用类继承来避免样板文件在短期内节省了一些代码，但是灵活性和维护成本很高。首先，您放弃了将来扩展不同基类的能力。现在，您的BookingService类必须设计为继承;你必须要小心哪些内部方法和状态暴露给子类，你需要担心在派生类中引入与方法的冲突。通常，由您希望扩展的类公开的API比接口公开的API更复杂，更难以理解。作为一般规则，我尽量避免使用类继承，除非我实际上使用多态（而不是只包括基类中的方法）。在这种情况下，您已经在使用接口，因此您不需要类多态性。

最后，请注意，您对IBookingServiceNew未暴露IBookingService上的方法的担忧很容易通过（1）将这些方法放在IBookingServiceNew上或（2）让IBookingServiceNew扩展IBookingService来解决。

Answer 2

extension methods怎么办？

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

向现有类添加方法 - 继承/注入

2 个答案: