Request for advice on class design, inheritance / aggregation

Question

I started writing my own WebDAV server class in .NET, and the first class I start with is the WebDAVListener class, modeled after the HttpListener class HttpListener .

Since I do not want to redefine the basic processing of the HTTP protocol, I will use the HttpListener for all its merits, and therefore I have a question.

What would be the proposed way to handle this:

• Deploy all the methods and properties found inside the HttpListener by simply changing the class types where it is important (i.e. GetContext + EndGetContext methods return another class for WebDAV contexts) and save and use the HttpListener object inside
• Build a WebDAVListener by passing it the HttpListener class to use?
• Create a wrapper for an HttpListener with an interface and constrct WebDAVListener, passing it an object that implements this interface?

If you are following the path of the HttpListener (masked or otherwise) to the WebDAVListener, can you open the main listener object via a property, or do you expect the program using the class to reference the base HttpListener ?

Also, in this case, could you open some of the HttpListener methods via WebDAVListener , for example, Start and Stop, or do you expect the program that used it to keep the HttpListener link around all these things?

My initial reaction tells me that I need a combination. First, I would like my WebDAVListener class WebDAVListener look like a complete implementation, hiding the fact that there is an HttpListener object under it.

On the other hand, I would like to build unit tests without actually rotating the network server, so it would be nice to have some mocking ability, which suggests that I need a wrapper interface.

One way to solve this problem would be to:

 public WebDAVListener() : WebDAVListener(new HttpListenerWrapper()) { } public WebDAVListener(IHttpListenerWrapper listener) { } 

And then I would execute all the HttpListener methods (at least all those that make sense) in my own class, basically just associating the call with the underlying HttpListener object.

What do you think?

The final question: if I go along the interface path, assuming the interface maps 1-to-1 to the HttpListener class and is written to add support for ridicule, is this interface called a shell or adapter?

Answer 1

First, I will answer your last question: a class is an adapter if it implements some ITarget interface using the contained object corresponding to some ISource adapter from ISource to ITarget. In this case, there is no source interface, you are trying to add it, so I would call it a shell.

I would be prone to

• Create a WebDavListener class that has all the methods necessary for its own behavior, internally uses the HttpListener and does not report anything to the HttpListener.

• If and when you need it, do IHttpListenerWrapper and HttpListenerWrapper, as you suggest, and change WebDavListener to use IHttpListenerWrapper in its constructor. Assuming all methods are the same, this should be a simple search and replace. You can even leave the original constructor there and create a shell constructor and call a new constructor.

• If and when you need it, make an IWebDavListener for it if you think you might need a dummy WebDAV listener to unit-test other things.

Such a design problem - which is why I love refactoring tools like ReSharper: Extract Interface, Create Derived Implementation, etc., makes it much easier to make such changes, so you can worry less about whether to do it now or later :-) (Assuming you are allowed to freely change the source later, of course, which depends on how you deliver things.)