Sponsored Link •
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.
Comparable also means: I can sort an array or collection
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
means something different, then I can't make that class Serializable because it breaks the (meta-) semantics
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.