|
Is it too much of a simplification to say that this paper is basically advocating object-oriented design, before that term was coined? My summary: The paper compares two different ways of dividing a codebase into modules. The program under question is KWIC. In the first case, the modules are divided into the four major steps of executing the KWIC algorithm: Input, Circular Shift, Alphabetizing, and Output. In the second case, the modules are nearly the same, but they are more service-oriented than action-oriented, e.g. Circular Shifter and Alphabetizer instead of Circular Shift and Alphabetizing. The chief difference is the interfaces between the two. In the first case, the contract between modules is the format of the data structures being passed from step to step. In the second case, the data structures are encapsulated, and the contract between modules is the api for manipulating the hidden data structures. The author argues that the second way is better in terms of changeability, independence of development, comprehensibility. At this point I lost interest in the paper (because I sing in the choir), but scanning the rest, the author talks about how to avoid taking a performance penalty when using the second design, and then gives a second example, this time of a markov algorithm translator instead of a KWIC. |