This business owner is trying too hard.
Our latest code-quality theme, the Interface Segregation Principle, says your classes and interfaces shouldn’t try too hard, either. If one object really is going to do two jobs, give it two interfaces and let other objects talk to whichever interface they actually need. This gives you the flexibility to split the object into its constituent parts or replace some of those parts in the future.
We found several examples relevant to the Interface Segregation Principle in our code, including
- a PriceManager object that manages many different types of market data in disparate ways (classes with “manager” in the title are particularly susceptible to double-wide-interface disease)
- a single Services object that implements interfaces for various families of actions (creating, updating, and closing)
- a Builder object that had an extraneous getter floating around in its interface (we moved the getter to a more appropriate object)
You may enjoy the demotivational posters we came up with to illustrate the Interface Segregation Principle: