Lecture
Narrowly Specific Problems
We believe that certain problem domains deserve special architectural consideration.
Designing an effective user interface is more an art than a science. In this area the use of prototypes is absolutely essential. Intensive feedback from end users should be established as early as possible, in order to identify characteristic hand motions, reactions to errors, and other interaction paradigms. In analyzing a user interface, constructing scenarios is highly effective.
Some applications have their own database; other applications may require integration with an existing database whose schema cannot be changed (usually because the database is already filled with a large amount of data - a variety of the legacy complexity problem). In such cases the principle of separation of concerns works well: it is best to encapsulate access to such databases in a small number of well-defined class interfaces. This principle is especially important when object-oriented decomposition and relational database (RDB) technology are used together. Object-oriented databases (OODBs) mesh better with object programs, but we must remember that OODBs are more suited to providing persistence for objects and less suited to storing large volumes of data.
Let us also touch on real-time systems. The notion of real time is understood differently in different contexts. In interactive systems it may mean a response within less than one second, whereas in data acquisition and control systems a response faster than one microsecond may be required. It is important to understand clearly that even under very stringent timing requirements, not every component must (or can) be optimized. For complex systems the greatest risk lies in whether or not the system will be completed, not in whether it will satisfy the performance requirements. For this reason we caution against premature optimization. Concentrate on creating a simple architecture, and the bottlenecks will reveal themselves in the course of the system's evolution (and early enough at that), so that you will be able to take measures.
The term "legacy complexity" refers to applications in which large capital investments have been made and which, for economic or safety reasons, cannot be abandoned. However, such systems may have a prohibitive maintenance cost, which is why in time they have to be replaced. Fortunately, legacy complexity can be dealt with in much the same way as databases: encapsulate access to their services in the context of well-defined class interfaces, and then gradually, function by function, displace them with an object-oriented architecture. Of course, it is necessary to have a picture of the final result, so that the system does not turn into a patchwork quilt in the course of uncontrolled changes.
The Transition to Object Technologies
In Kempf's view, "Learning object-oriented programming may turn out to be a far more difficult task than merely mastering yet another language. In this case one must learn a different style of programming, and not simply memorize a syntax. That is, what has to be learned is not a language but a way of thinking" [18]. How does one develop an object-oriented world view? We recommend the following:
Good candidates for the first projects are tools or domain-specific class libraries, which can later be used as resources for subsequent projects.
In our experience, a professional developer needs several weeks to become comfortable with the syntax and semantics of a new programming language. It will take several times as long for that same developer to begin to appreciate the importance and power of classes and objects. Finally, more than six months of experimentation may be required for a developer to mature into a good designer of classes. This is not necessarily a bad thing - learning a craft always takes time.
We believe that learning by example often proves to be an effective and sensible approach. Once an organization has accumulated a critical mass of applications built in the object-oriented style, it becomes far easier to train new developers and managers in this work. Developers begin as implementing programmers, applying ready-made, well-structured abstractions. After a time, developers who have studied and used these components under the supervision of more experienced colleagues acquire enough experience themselves to design classes.
Comments