title: Hiding implementation details using interfaces when arbitrary implementations not allowed
body: <p>I'm building a public API for our application, using C#. I have a set of facade classes on top of DTOs used with a WCF client. It allows the API consumer to fetch, update, create, etc., from a database application. Standard stuff: Customer has a collection of Orders, Order has a collection of Line Items, etc. </p>
  
  <p>The facade classes all derive from a common base class and override methods that do validation, reading/writing the DTOs, and other plumbing stuff, all using various internal types. I'm using a factory for creating new objects and fetching existing ones.</p>
  
  <p>The question now is how best to expose the classes through the API while minimizing exposure of implementation details.</p>
  
  <p>Interfaces seem like the obvious approach as the simplest way to limit what's exposed (and may in the end be necessary anyway, as a COM-compatible interface is under consideration). The problem with the interface approach is that internally my code will be dependent on particular implementations of the interfaces.</p>
  
  <p>Suppose I have an ICustomer interface exposing my CustomerFacade, and IOrder exposing OrderFacade. Externally, ICustomer has a collection of IOrders. But internally, the CustomerFacade has a collection of OrderFacades. If the client application adds a new IOrder to a customer, I have to check that the IOrder is really an OrderFacade previously created from my factory, and not some other object outside my control that implements IOrder. That's because internally I need an order to be able to do a lot more than what an IOrder can do. </p>
  
  <p>Practically speaking this doesn't much matter--users of the API are not going to be trying to create their own Order implementations. But it feels inelegant to me, like an abuse of what the interface contract is supposed to mean.</p>
  
  <p>Exposing the facade classes directly isn't great, because the entire class hierarchy has to get exposed, along with the internal types used by protected methods, and that clutters up the API with types that the consumer won't be using and doesn't need to know about.</p>
  
  <p>The other alternative I can think of is another layer of encapsulation: An Order that contains a private OrderFacade and only exposes the members that should be public. But this seems like a lot of extra code for limited benefit.</p>
  
  <p>I considered abstract base classes but that doesn't work any better than exposing the facade classes, due to the inheritance structure. For example, if I have a ServiceItem that inherits from CatalogItem, introducing an abstract ServiceItemBase in between still requires me to expose all the protected methods in CatalogItem.</p>
  
  <p>Any recommendations on these approaches, or an alternative I haven't looked at?</p>