Class Responsibilities
Class responsibilities are what a class is charged with doing. They represent an implicit contract with the other objects in the system that covers what it will do and when it will do it.
There is typically no one-to-one mapping between a class's responsibilities and a class's methods. This is because the responsibilities are decided at a stage generally earlier in the design process and at a higher level of abstraction than the stage at which a class's operations are distilled into a class's methods.
The difference between an operation and a method is that operations describe processes performed by the class whereas a method performs some specific coded function. An operation is something invoked on an object, and a method is the code that gets executed. Because some object-orientated programming languages support polymorphism, there may not be a one-to-one correspondence between operations and methods. The reason for this is that the method that actually gets called for an operation request depends on the type of object from which the operation was requested. It is at the conceptual stage of the design where a class's operations are being decided that the class responsibilities should also be established.
The first stage in designing an object-orientated program usually involves conceptually splitting the system up into easily identifiable entities. These are not usually well-defined classes in the object-oriented sense, but rather are just "things" that the system will probably contain. For example, a payroll system will probably have employee names in it.
When the list of probable classes is considered to be reasonably stable the classes' responsibilities can be defined. The list of responsibilities for each class represents what the object is responsible for doing in the context of the system. In the object-orientated sense, these responsibilities indicate the behavioural interface of the class, or the public methods it will probably support. That is, when the designer indicates an entity within the system, he usually has some idea of what it is supposed to do.
Often a class's initial list of responsibilities will change because the design process will also identify for each class a set of collaborator classes, classes that work with objects of the class under consideration to help it fulfil its responsibilities.
In general every class should be responsible for one "thing," and every "thing" in the system should be the responsibility of some class. As an example of this, consider a class that manages a resource, like a C++ pointer. Pointers in C++ are fraught with errors: not only can they cause catastrophic failure if they are not handled properly, but if they are allocated and then not explicitly deleted, they cause "memory leaks." A memory leak is caused when an object is created and not destroyed when there are no longer any references to it; it takes up memory for absolutely no purpose, thus depriving the system of that resource.
The solution is to put pointers inside classes that manage them: each instance of the class, or object, is responsible for managing exactly one pointer. Managing the pointer might mean allocating it when the object is created, initialising it and the object it represents, and then deleting it when it is no longer needed. All access to the pointer itself would be via methods on the object managing the pointer. In short, the class that manages the pointer is responsible for it.
This is the complete article, containing 558 words
(approx. 2 pages at 300 words per page).
