Question

I’ve done some searching (maybe I’m not describing my problem well enough) but haven’t been able to find an answer for this

Let’s say you have the following POCO:

public class StandardObject
{
   public string A {get;set;}
   public string B {get;set;}
}

Somewhere else in the program there is some logic to handle StandardObjects.
There exists a case where sometimes a StandardObject may need to be handled differently. We know this when we create the StandardObject however none of the current properties can be used to determine this further down the chain. One approach would be to add and set a flag or type enum on StandardObject and check this when handling the objects. E.G.

if(standardObject.IsSpecial){...}

if(standardObject.ObjectType == StandardObjectTypeEnum.Special){...}

This doesn’t seem like the best approach though.

The other option would be to create a derived class:

public class SpecialObject : StandardObject { }

So now rather than checking a property, we can check the type. E.G.

if(standardObject.GetType() == typeof(SpecialObject)){...}

(Depending on what we were doing, the type checking might be implemented differently)

Note that SpecialObject does not add to or change StandardObject in any way. It is essentially the same object. This approach has the advantage of being more flexible (E.G. We could add some additional properties to SpecialObject) but in reality it won’t change. It will always be identical.

To me inheritance seems like the better approach. Type flags seem like code smell and going forward inheritance seems more like the correct OOP approach. The thing I’m not sure about here is that, given that StandardObject and SpecialObject are the same, is it bad practice to do this? Or are there any reasons why this should be avoided?

There is a similar question here:

Chess piece hierarchy design: inheritance vs type fields

However most of the discussion seems to focus on the chess problem rather than what is considered good design

EDIT:

Encapsulation seems to be the popular solution. The reason why I’ve avoided encapsulation is best described in the example below:

• StandardObject is essentially a DTO
• There is a list of StandardObject.
• The list gets processed, StandardObject gets serialized
• The serialized data is sent somewhere over any number of different protocols
• One of the protocols requires certain parameters to be set if StandardObject is “special”

Given that the additional logic for “special” cases is only required by one of a number of different mechanisms that process StandardObject, the logic for this does not seem like it belongs anywhere near StandardObject

Answer 1

They are both code smells. If you have special handling that must be accomplished differently between two related types, have them both implement some virtual method or interface operation that allows them to handle the special case (or not, if it’s not necessary).