[...] Evidence in support of first-person knowledge is provided by the fact that different designers are likely to produce different designs for the same set of requirements. And the same designer is likely to produce different designs at different points in time even though the same requirements are presented. This is a result of the designer acquiring new knowledge while interacting with their environment. Gero, JS and Kannengiesser, U (2008) A Function-Behaviour-Structure ontology of processes, AIEDAM (to appear).
Our module structure is based on the decomposition criterion known as information hiding . According to this principle, system details that are likely change independently should be the secrets of separate modules; the only assumptions that should appear in the interface between modules are those that considered unlikely to change. Each data structure is used in only one module; it may be directly accessed by one or more programs within the module but not by prigrams outside the module. Any other program that requires information stored in a module's data structures must obtain it by calling access programs belonging to that module.
・The Single Responsibility Principle - A class should have only one reason to change.
・The Open-Closed Principle - Software entities (classes, modulues, functions, etc.) should be open for extension, but closed for modification.
・The Liskov Substitution Principle - Subtype must be substitutable for their base types.
・The Dependency Inversion Principle - Abstraction should be not depend upon details. Details should depend upon abstractions.
・The Interface Segregation Principle - Client should not be forced to depend upon methods that they do not use. Interfaces belong to clients, not to hierarchies.
・The Release-Reuse Equivalenct Principle - The granule of reuse is the granule of release.
・The Common Closure Principle - The classes in a package should be closed together against the same kinds of changes. A change that affects a closed package affects all the classes in that package and no other packages.
・The Common Reuse Principle - The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all. ・The Acyclic Dependencies Principle - Allow no cycles in the package dependency graph.
・The Stable Dpendencies Principle - Depend in the directions of stability.
・The Stable Abstractions Principle - A package should be abstract as it is stable.
・Don't Repeat Yourself - Do not write the same or similar code more than once. ・Speaking Code Principle - The code should communicate its purpose. Comments in the code could indicate that the code communicate its purpose insufficiently. ・Tell, Don't Ask - Don't ask an object about an object, but tell it what to do.
今回の記事の内容に直接関わるかどうかは分からないけど、Christopher Alexander の「The Nature of Order」のBook 2では、順番についての次の記述がある。
4. VITAL IMPORTANCE OF THE "RIGHT" SEQUENCE
In architecture, as in other things, the importance of sequence is both simple, and potentially shocking. Even when there are only two steps to be token, the order in which they are done may be all-important. And it may be highly surprising.
Consider for example the process of laying out a house on a lot.
"Common sense" says that you should first place the house, and then place the garden, This is common sense; but it is wrong. To make the environment and the formation of house garden together come out right, you have to reverse the order of these two operations, as follows: 1. First: Locate the garden in the best and most beutiful place. 2. Then: Locate the house so that i helps and supports the garden.
This example is fascinating because it illustrate the enormous significance of sequence. If you place the house first, you are stuck with the leftovers as places for the garden. In all likelihood the garden will not become a pleasant place. Possitive space will amost certainly be violated. So will view, smell, noise. But if you locate the garden first and then place the house volume in a way which supports the wholeness of the garden, the garden will come out better and so will the house.
Of the two available sequence for these two operations, one sequence is wrong, and ohe is right (90% of the time). The sequence which is wrong, is correct according to conventional wisdom, and probably considered obviouse by millions of people. The one which is right (and which gives you insight, makes things more understandable, and gets wholesome results), flies in the face of common sense, and would be rejected by nine out of ten people who first hear it. Yet it is the right answer.
Few examples explain the enormouse power and siginificance of sequences more vividly. And as you can imagine, if the sequence -- the order of steps -- is significant when dealing with only two operations, how much more siginificant it will be when dealing with ten, or twenty, or fifty steps. There the chance of getting the sequence right by accident, is extremely small.