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
I would call it a Failure to Encapsulate
. It's a made up term, but it is real and seen quite often
A lot of people forget that encasulation is not just the hiding of data withing an object, it is also the hiding of behavior within that object, or more specifically, the hiding of how the behavior of an object is implemented.
By having an external DoSomething()
, which is required for the correct program operation, you create a lot of issues. You cannot reasonably use inheritence in your list of things. If you change the signature of the "thing", in this case the string, the behavior doesn't follow. You need to modify this external class to add it's behaviour (invoking DoSomething()
back to the derived thing
.
I would offer the "improved" solution, which is to have a list of Thing
objects, with a method that implements DoSomething()
, which acts as a NOOP for the things that do nothing. This localizes the behavior of the thing
within itself, and the maintenance of a special matching list becomes unnecessary.