When to hide an inheritance hierarchy in a concrete class?

Question

Whenever I am in a situation where I have a factory returning abstract-base-class implementations to a user based on some "low-level" type parameter such as a protocol or the format of an external resource, I am always tempted to convert the abstract class into a concrete class with an internal "strategy factory" so that users can just pass the implementation type to the constructor and work with the base-class directly.

I noticed the .Net framework chose to implement Socket this way (instead of creating a DatagramSocket you pass the SocketType at construction). What are some guidelines to deciding when it is acceptable to flatten the hierarchy into a single concrete class like this?

Answer 1

I think that the point is : "how much of the low level details should the client be aware of?".

If you choose the first solution(abstract base class) you are hiding more details to the client class. This way the client can ignore completely the low level details (protocol, format of an external resource.). When the goal is to hide completely the implementations details and the types used inside that implementation i prefer this approach.

Otherwise, if the client is already aware of some details of the low level implementation (for example client knows that socket he will use is UDP and he also WANT to know that kind of information), then abstract base class approach can be substituted with an internal "strategy factory".