The key ingredients that make an object well-designed, therefore, are things that client programmers would care about. The two main qualities I look for in an object are 1) it does its job well, and 2) it is easy to use. These are, in fact, the same two qualities I look for in just about any machine I bring into my everyday life. If I buy a new cyclometer for my bicycle, for example, I want that cyclometer to work well -- to reliably keep accurate time, distance, and speed records. But I also want it to be easy to use. I want services that I request often from my cyclometer, such as switching the display between distance, time of day, speed, and average speed, to be quick and easy to get at. I don't mind terribly if services that I request less often, such as setting my tire size or the current time, are more difficult to get at. But in no case do I want to invest more than a few minutes of my time pressing buttons and, if necessary, consulting the instruction booklet to access any functionality offered by my cyclometer.

Similarly, if I buy an implementation of an API and instantiate one of its classes, I want the resulting object to work well. I want the object to do what it promises to do, in an efficient manner, every time I ask it. But I also want the object to be easy to use. I want the object's interface to be designed such that I can, with no more than a few minutes of looking through the APIs documentation, figure out how to ask the object to do whatever I want it to do.

Semantics

• Guideline: Appreciate the significance of semantics.
• interface = syntax + semantics
• semantics = semantic contract + meta-semantics
• Semantic contract: what the object can do for me (how it will behave) and how I use it
• Meta-semantics: what I can do with the object
• An organ keyboard has:
  • interface syntax: the positions of the keys
  • interface semantics: the frequency of the tones generated when you push the keys
  • implementation: pipes, electronic guts, etc...
• THIS IS THE SIGNIFICANCE: Common understanding of semantics between designer and client is crucial to getting things working together in the first place and fulfillment of the "can change the implementation without breaking code" promise.

Comparable also means: I can sort an array or collection with Arrays.sort() or Collections.sort() (meta-semantics)

meta-semantics of Serializable is that if there's a readObject method with a certain signature in a Serializable object's class, then the semantics of that method are... So, if I have a readObject that means something different, then I can't make that class Serializable because it breaks the (meta-) semantics of Serializable.

Giving objects responsibilities helps people understand software, becuase that's how we get work done among people, so programmers are familiar with this way of doing things. It's how we organize our socities. The big difference is that when someone doesn't do their job right, or there's a misunderstanding of (or different perspectives on) the requirements, then people can talk it out or, if that doesn't work, go to court. Software just doesn't work.