Code Smells

Reading Only

When defining an interface, strive to create a thin interface.

If the purpose of the interface is to define a contract, we should make the contract easy to understand and implement by making it clear and focused. Each interface should represent a single functionality or a cohesive set of functionality.

The best way to do that is by defining only the method signatures that are necessary for the contract. This will reduce interface bloat.

That's one of the reasons we didn't include the validateOrder method in the interface for IAccount. Not all account types may need their orders validated. It also was not something that the OrderController necessarily needed to know about. So we left it out. This was a judgment call, there's no definitive right or wrong answer.

In general, I'd recommend being cautious by keeping interfaces as thin as you can.

Over Engineering

There's a fine line between preparing for the future and over engineering. Creating interfaces for future "just in case" scenarios, without a current need, can lead to unnecessary complexity.

You may never need the interface, or worse, you might build the wrong interface. If you do this, be careful what assumptions you're making about your future needs. Those anticipated future scenarios may never materialize. The interface you've created may never be needed or may need to change significantly because of inflexibility and lead to increased refactoring overhead.

Leaky Abstractions

Interfaces are an Apex mechanism to create abstractions so that complexity can be hidden. Our abstractions can become "leaky". If the interface reveals too much about the underlying implementation or if the implementers have to know too much about the inner workings to use the interface. Here's a great article by the person who coined the term.