Section 10.4 Programming to an Interface
A common proverb when it comes to object-oriented programming, and all programming in general, is this:
Program to an interface, not an implementation.
What this pithy line suggests is that we should use the
Grade interface when possible, instead of the SimpleGrade class. But why? What difference does it make?Philosophically it makes a big difference. One of our biggest goals when it comes to designing complex software is to build that software out of smaller parts, each doing its job, knowing as little about the others, and communicating with each other in established ways. This process of making sure each object knows as little as possible about other objects is called decoupling.
As a simple example, suppose the president of the college wants to send a letter to another president. They would probably ask their secretary to draft that letter and show it to them, before the secretary sends it on its way. Does the president care what software the secretary uses to compile that letter? Probably not, as long as the end result is something readable. For all he knows the secretary might further delegate that task to one of the assistants.
Each object should get its work done by doing its bit and by asking other objects to help it along by doing something they specialize in. The details of how these other objects achieve their goal is not important, only the end result is.
And that’s what interfaces provide us! You say you need an object with these method signatures, but you don’t care how that object is going to get its work done as long as you get your result? That’s exactly what the interface does.
That still doesn’t fully drive home the reason for interfaces. But it’s a start and it gets us a bit closer to some useful examples. One such example is the
Iterable interface. It is also an illustration of another important topic:Interfaces are more logically related to their clients than their implementers.
What I mean by this is simply that the whole reason for an interface to exist is because someone needs something done. In the example above the
SimpleGrade class can exist perfectly well with or without the Grade interface. On the other hand someone who wants to do something with grades, i.e. the client of the Grade interface, cannot do its job without something like the interface. It may instead use the class SimpleGrade directly, but in any case it needs to call certain methods that the interface specifies. And it is the need for these methods to be called that gives a reason for having the interface in the first place.With that in mind,
Grade is not a great name for the interface. And in general nouns don’t make good names for interfaces.Name your interfaces based on the capabilities they represent, that their users need and their implementers implement. This often suggests adjectives as interface names (Draggable,Iterable,Runnable).
So perhaps our
Grade interface might better be called, hm, maybe Scorable? It’s not a great name, and the reason for that is that Grade is not a great interface to begin with. It is not particularly focused on what its users would need from it. A set of methods more focusing on the points that a course carries might have been more suitable, and skipping the getLetter method for example.
