I'm reading this bookabout Object-Oriented Analysis and Design. These are some excerpts I would like to take note of:
The Role of Decomposition
"The technique of mastering complexity has been known since ancient times: divide et impera (divide and rule)". When designing a complex software system, it is essential to decompose it into smaller and smaller parts, each of which we may then refine independently. In this manner, we satisfy the very real constraint that exists on the channel capacity of human cognition: To understand any given level of a system, we need only comprehend a few parts (rather than all parts) at once. Indeed, as Parnas observes, intelligent decomposition directly addresses the inherent complexity of software by forcing a division of a system's state space.
The Role of Abstraction
Earlier, we referred to Miller's experiments, from which he concluded that an individual can comprehend only about seven, plus or minus two, chunks of information at one time. This number appears to be independent of information content. As Miller himself observes, "The span of absolute judgment and the span of immediate memory impose severe limitations on the amount of information that we are able to receive, process and remember. By organizing the stimulus input simultaneously into several dimensions and successively into a sequence of chunks, we manage to break ... this informational bottleneck". In contemporary terms, we call this process chunking or abstraction.
As Wulf describes it, "We (humans) have developed an exceptionally powerful technique for dealing with complexity. We abstract from it. Unable to master the entirety of a complex object, we choose to ignore its inessential details, dealing instead with the generalized, idealized model of the object". For example, when studying how photosynthesis works in a plant, we can focus on the chemical reactions in certain cells in a leaf and ignore all other parts, such as the roots and stems. We are still constrained by the number of things that we can comprehend at one time, but through abstraction, we use chunks of information with increasingly greater semantic content. This is especially true if we take an object-oriented view of the world because objects, as abstractions of entities in the real world, represent a particularly dense and cohesive clustering of information.
Elements of the Object Model
1. Abstraction
2. Encapsulation
3. Modularity
4. Hierarchy
By major, we mean that a model without any one of these elements is not object-oriented.
There are three minor elements of the object model:
1. Typing
2. Concurrency
3. Persistence
By minor, we mean that each of these elements is a useful, but not essential, part of the object model.
Abstraction:
Abstraction focuses on the essential characteristics of some object, relative to the perspective of the viewer.
Encapsulation:
Encapsulation hides the details of the implementation of an object.
Abstraction and encapsulation are complementary concepts: Abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to this behavior. Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods. "No part of a complex system should depend on the internal details of any other part". Whereas abstraction "helps people to think about what they are doing," encapsulation "allows program changes to be reliably made with limited effort".
Modularity:
Modularity packages abstractions into discrete units.
Hierarchy:
Abstractions form a hierarchy.
Typing:
Strong typing prevents mixing of abstractions.
Concurrency:
Concurrency allows different objects to act at the same time.
Persistence:
Persistence saves the state and class of an object across time or space.