What is the name of this bad practice / anti-pattern?

Question

I'm trying to explain to my team why this is bad practice, and am looking for an anti-pattern reference to help in my explanation. This is a very large enterprise app, so here's a simple example to illustrate what was implemented:

public void ControlStuff()     {         var listOfThings = LoadThings();         var listOfThingsThatSupportX = new string[] {"ThingA","ThingB", "ThingC"};         foreach (var thing in listOfThings)         {             if(listOfThingsThatSupportX.Contains(thing.Name))             {                 DoSomething();             }         }     } 

I'm suggesting that we add a property to the 'Things' base class to tell us if it supports X, since the Thing subclass will need to implement the functionality in question. Something like this:

public void ControlStuff()     {         var listOfThings = LoadThings();         foreach (var thing in listOfThings)         {             if (thing.SupportsX)             {                 DoSomething();             }         }     } class ThingBase {     public virtual bool SupportsX { get { return false; } } } class ThingA : ThingBase {     public override bool SupportsX { get { return true; } } } class ThingB : ThingBase { } 

So, it's pretty obvious why the first approach is bad practice, but what's this called? Also, is there a pattern better suited to this problem than the one I'm suggesting?

Answer 1

Normally a better approach (IMHO) would be to use interfaces instead of inheritance

then it is just a matter of checking whether the object has implemented the interface or not.

Answer 2

I think the anti-pattern name is hard-coding :)

Whether there should be a ThingBase.supportsX depends at least somewhat on what X is. In rare cases that knowledge might be in ControlStuff() only.

More usually though, X might be one of set of things in which case ThingBase might need to expose its capabilities using ThingBase.supports(ThingBaseProperty) or some such.