684 DESIGN CASE STUDY:MULTI-PANEL INTERACTIVE SYSTEMS $20.5 20.5 AN OBJECT-ORIENTED ARCHITECTURE The very deficiencies of top-down functional decomposition point to what we must do to obtain a good object-oriented version. The law of inversion What went wrong?Too much data transmission in a software architecture usually signals a flaw in the design.The remedy,which leads directly to object-oriented design,may be expressed by the following design rule: Law of inversion If your routines exchange too many data,put your routines in your data. Instead of building modules around operations (such as execute session and execute state)and distributing the data structures between the resulting routines,with all the unpleasant consequences that we have seen,object-oriented design does the reverse:it uses the most important data types as the basis for modularization,attaching each routine to the data type to which it relates most closely.When objects take over,their former masters,the functions,become their vassals. The law of inversion is the key to obtaining an object-oriented design from a classical functional(procedural)decomposition,as in this chapter.Such a need arises in cases of reverse-engineering an existing non-O-O system to make it more maintainable and prepare its evolution;it is also frequent in teams that are new to object-oriented design and think“functional”first. It is of course best to design in an object-oriented fashion from the beginning;then no inversion is needed.But the law of inversion is useful beyond cases of reverse- engineering and novice developers.Even someone who has been exposed to the principles of object-oriented software construction may come up with an initial design that has pockets of functional decomposition in an object landscape.Analyzing data transmission is a good way to detect and correct such design flaws.If you see-even in a structure intended as O-O-a data transmission pattern similar to what happens with states in the example of this chapter,it should catch your attention.Probing further will in most cases lead you to the discovery of a data abstraction that has not received its proper due in the software's architecture. State as a class The "state"example is typical.Such a data type,appearing so pervasively in the data transmissions between routines,is a prime candidate for serving as one of the modular components of an object-oriented architecture,which must be based on classes(abstractly described data types).684 DESIGN CASE STUDY: MULTI-PANEL INTERACTIVE SYSTEMS §20.5 20.5 AN OBJECT-ORIENTED ARCHITECTURE The very deficiencies of top-down functional decomposition point to what we must do to obtain a good object-oriented version. The law of inversion What went wrong? Too much data transmission in a software architecture usually signals a flaw in the design. The remedy, which leads directly to object-oriented design, may be expressed by the following design rule: Instead of building modules around operations (such as execute_session and execute_state) and distributing the data structures between the resulting routines, with all the unpleasant consequences that we have seen, object-oriented design does the reverse: it uses the most important data types as the basis for modularization, attaching each routine to the data type to which it relates most closely. When objects take over, their former masters, the functions, become their vassals. The law of inversion is the key to obtaining an object-oriented design from a classical functional (procedural) decomposition, as in this chapter. Such a need arises in cases of reverse-engineering an existing non-O-O system to make it more maintainable and prepare its evolution; it is also frequent in teams that are new to object-oriented design and think “functional” first. It is of course best to design in an object-oriented fashion from the beginning; then no inversion is needed. But the law of inversion is useful beyond cases of reverse￾engineering and novice developers. Even someone who has been exposed to the principles of object-oriented software construction may come up with an initial design that has pockets of functional decomposition in an object landscape. Analyzing data transmission is a good way to detect and correct such design flaws. If you see — even in a structure intended as O-O — a data transmission pattern similar to what happens with states in the example of this chapter, it should catch your attention. Probing further will in most cases lead you to the discovery of a data abstraction that has not received its proper due in the software’s architecture. State as a class The “state” example is typical. Such a data type, appearing so pervasively in the data transmissions between routines, is a prime candidate for serving as one of the modular components of an object-oriented architecture, which must be based on classes (abstractly described data types). Law of inversion If your routines exchange too many data, put your routines in your data