I primarily write server code in Java, for context.
I write interfaces in 2 primary situations:
- Any
time I need a contract between major modules, or between my code and
code someone else owns. The contract includes the interface
definition(s) and all the types that pass through that interface. That’s
a package, and is declared as such.
- Any
time I design a general-purpose process which takes different
implementations. Right now, for example, I am working on a machine that
executes tasks in a sequence depending on the outcome of the previous
task. The interface for each task has a single execute method which
takes a process status object and returns one of 4 results, all of which
are defined in an enumeration.
I
seldom write abstract classes—but when I do, they generally implement
an interface, and are intended to remove a lot of boilerplate code so
implementers don’t have to fully understand the interface behavior to
use it effectively. Abstract classes are a lot more common (and have a
lot more use cases) in frameworks. Framework developers do this more
than server engineers because their software is intended to be extended
by others, whereas my software is usually intended as an end in itself.