The Splinterface

It starts off well, you have a class which has grown too complex, so you pull out some functionality into a separate class. You've pulled it out because now it is no longer fixed. It can be cyclic or non-cyclic perhaps.

All is good.

There are some parts that are shared by cyclic and non-cyclic, so you pull them out and create an interface. But over time, cyclic and non-cyclic diverge. You add a method to the interface that's only used by cyclic, and another which is specific to non-cyclic.

And eventually you can add comments to your interface that look like this

// cyclic uses these
...
// non-cyclic uses these
...
/// this one is shared by both
...

Now you have a Splinterface.

It provides the illusion of shared functionality and shared code, but that's all. It hinders change as you have lost clarity of what is and is not used. It promotes code duplication.

It's cause seems to be allied to designing interfaces based on what something is, not what services it provides.

Chances are you have 2 implementations of your Splinterface and liskov substitution is gone out the window.

Really it's time to stop, document what's going on in your code, take a long hard look, understand what should be done and fix it.

Or you could just add more code and hope for the best. If you take that approach, let me know how it all works out.

Ps- Thanks to JackH who came up with the name.