Java Reference
In-Depth Information
Abstraction
A program provides solutions to a real-world problem. The size of the program may range from a few lines to a few
million lines. It may be written as a monolithic structure running from the first line to the millionth line in one place.
A monolithic program becomes harder to write, understand, and maintain if its size is over 25 to 50 lines. For easier
maintenance, a big monolithic program must be decomposed into smaller subprograms. The subprograms are then
assembled together to solve the original problem. Care must be taken when a program is being decomposed. All
subprograms must be simple and small enough to be understood by themselves, and when assembled together, they
must solve the original problem.
Let's consider the following requirement for a device:
Design and develop a device that will let its user type text using all English letters, digits,
and symbols.
One way to design such a device is to provide a keyboard that has keys for all possible combinations of all letters,
digits, and symbols. This solution is not reasonable as the size of the device will be huge. You may realize that we are
talking about designing a keyboard. Look at your keyboard and see how it has been designed. It has broken down the
problem of typing text into typing a letter, a digit, or a symbol one at a time, which represents the smaller part of the
original problem. If you can type all letters, all digits, and all symbols one at a time, you can type text of any length.
Another decomposition of the original problem may include two keys: one to type a horizontal line and another
to type a vertical line, which a user can use to type in E , T , I , F , H , and L because these letters consist of only horizontal
and vertical lines. With this solution, a user can type six letters using the combination of just two keys. However, with
your experience using keyboards, you may realize that decomposing the keys so that a key can be used to type in only
part of a letter is not a reasonable solution, although it is a solution.
Why is providing two keys to type six letters not a reasonable solution? Aren't we saving space and number of
keys on the keyboard? The use of the phrase “reasonable” is relative in this context. From a purist point of view, it may
be a reasonable solution. My reasoning behind calling it “not reasonable” is that it is not easily understood by users.
It exposes more details to the users than needed. A user would have to remember that the horizontal line is placed at
the top for T and at bottom for L . When a user gets a separate key for each letter, he does not have to deal with these
details. It is important that the subprograms that provide solutions to parts of the original problem must be simplified
to have the same level of detail to work together seamlessly. At the same time, a subprogram should not expose details
that are not necessary for someone to know in order to use it.
Finally, all keys are mounted on a keyboard and they can be replaced separately. If a key is broken, it can
be replaced without worrying about other keys. Similarly, when a program is decomposed into subprograms, a
modification in a subprogram should not affect other subprograms. Subprograms can also be further decomposed by
focusing on a different level of detail and ignoring other details. A good decomposition of a program aims at providing
the following characteristics:
Simplicity
Isolation
Maintainability
Each subprogram should be simple enough to be understood by itself. Simplicity is achieved by focusing on the
relevant pieces of information and ignoring the irrelevant ones. What pieces of information are relevant and what are
irrelevant depends on the context.
Each subprogram should be isolated from other subprograms so that any changes in a subprogram should have
localized effects. A change in one subprogram should not affect any other subprograms. A subprogram defines an
interface to interact with other subprograms. The inner details about the subprogram are hidden from the outside
world. As long as the interface for a subprogram remains unchanged, the changes in its inner details should not affect
the other subprograms that interact with it.
Each subprogram should be small enough to be written, understood, and maintained easily.
 
Search WWH ::




Custom Search