Is Inheritance the correct approach.

Question

We have a base TCP Server class which provides Server functionallity. Now we want to provided secure TCP Server functionality as well. There were two approaches we were debating on.

1. Pass a value to TCP server constructor, indication whether it should act as TCPServer or TCP secure server.

2. Create a TCPSecure class inheriting from TCP Server class, this will require overiding few of the methods of base class.

The first approach has benefits that it will keep everything in a single class.

The second approach looks more correct design wise. But we dont expect more types of derivation happening. So is it worth introducing a new class for this?

Thanks in advance.

Answer 1

The second approach is the correct one if, and only if, every TCPSecure can be used as a drop-in replacement for a non-secure server without objects using the server ever noticing that they are using a secure server.

This is called the Liskov substitution principle and is one of the cornerstones of OO design.

Answer 2

Instead of passing in a value to indicate how the object is constructed (which sounds fine when there are only 2 types but not for N types) pass in an object which handles that type of logic. That is, use composition to split the areas which will vary within your class so that you can encapsulate the variance in its own object. Composition over inheritance will make future refactorings easier to handle and implement. If a change spans all N child types, that's N places you'll need to change it but if it only spans one of the objects that compose some object, well, you see the benefit?

Answer 3

You have to see what's changing and encapsulate it in its own class. Sometimes simply using a variable doesn't work although it seems the easiest approach to use. But over time as requirements change, which will definitely happen, it becomes a burden to maintain the code and play with it i.e. dependency. Inheritance is something that people overuse, but in this situation it might be the better solution. I wouldn't go with using a variable to distinguish secure from not secure. It's going to be hard to maintain the code over time.

Answer 4

Behavior switches are not as easy to get right as subclasses, in general, so I'd tend to favor the subclassing. I wouldn't worry about the lack of future subclassing. Probably the best way to do it would be to have a Server base class with Secure and Insecure subclasses (or whatever you want to call them).

Remember the Liskov principle: the TCPSecure should be a drop-in replacement for TCPServer, in that it will do everything TCPServer will do from a programming point of view. It doesn't need to do it the same way, and it can in fact block certain user behavior, but the code calling it shouldn't need to know, and calling functions should not get unexpected results.

Another issue is that security is not just a quick add-on. It requires attention to the whole system. I'd think that this favors subclassing, in that it puts the secure behavior all in one place. If you go with the behavior switch, I'd suggest having every feature document what it does differently with it set to secure or insecure.

Answer 5

It sounds like the second approach is a good one. A good metric is to make sure it doesn't violate the Liskov Substitution Principle.