Auxiliary Concepts


The following terms do not define objects or concepts about objects. Instead, they add nuances to, alter our understanding of, or enhance our perspectives of  those familiar terms.

Domain

The term domain refers to the arbitrarily bounded space we are simulating, in whole or in part, with the objects we design and implement. We understand objects based on how they reflect phenomena and concepts in the domain. A domain might be a business enterprise or a type of business (for example, banking or government). A domain might be nothing more than a focused community of objects collectively providing a particular set of services ”for example, the domain of graphics or the domain of money.

When we are constructing a class library or a set of components , our goal should be to create a set that is capable of simulating the entire business enterprise or, preferably, the industry of which the enterprise is a member. It is almost always a mistake to define the domain as coextensive with an application program. A domain class library can be constructed incrementally as long as every class added is a simulation of behaviors expected in the domain as a whole and not just the application in which a class is first encountered . Behaviors can be added and moved via refactoring if the definition of classes is domain driven. Yet this is the level at which too many object-oriented texts provide illustrations and examples.

It is possible to define your domain as the computer ”the implementation environment. This is, in theory, what object language designers do. If that is your domain of interest, object thinking should apply as much to that domain as it does to any other. Relatively few attempts have been made to apply object thinking to these domains. Of course, it is precisely this area where you might expect the greatest resistance to object ideas and the greatest allegiance to machine thinking alternatives. Perhaps this is appropriate, but it would be a lot of fun to seriously attempt the creation of an operating system that reflects pure objects and nothing but objects. (There have been attempts along this line, and Squeak, for example, has all operating system services built into the class hierarchy so there is no need for an operating system at all.)

This is probably a good point to insert a caveat about the material presented in subsequent chapters of this book. Almost all of the examples and discussions focus on application domains. Both an implementation domain and  an execution domain are assumed.

The implementation domain will be a programming language and its accompanying class library. In most examples, we simply assume the existence of objects such as strings, characters , and collections. Also assumed are typical behaviors for those objects. Typical behavior is considered a superset of those behaviors included in object programming languages such as Smalltalk, Visual Basic, C#, Java, and C++. Sometimes, especially in dealing with collections, the assumptions are biased by the capabilities of Smalltalk collections (and my familiarity with that language), which are more extensive than in any other programming language.

An execution domain consists of the virtual machine or compiler and the operating system. Again, assumptions are made about services provided by these entities. It s also assumed that these entities are not generally object-oriented environments. Because the operating system, for example, is not object-oriented, it is frequently necessary to compromise object principles to some degree in order to make it possible for objects to interact with nonobjects.

A special kind of execution domain would be a database management system (DBMS). You could say that the very idea of a DBMS is antithetical to object thinking, [5] but such systems are an implementation necessity for most organizations. Almost from the inception of object development, there has been conflict between object applications and DBMS execution environments. The problem even has its own name : the impedance mismatch problem. (See Chapter 10 for further discussion.)

Business Requirement

A business requirement is defined as any task, decision, procedure, or process that supports a business objective, goal, or mission. A business requirement might be satisfied by an individual object or by a group of cooperating objects. Those objects can be human, mechanical, or software based. If the business requirement can be satisfied by a single object, it becomes a responsibility of that object. If a group of objects is required, the business requirement is  most likely to be expressed as a set of individual object responsibilities plus a script that ensures the proper coordinated invocation of those responsibilities. Most of the time we will use story , as used in XP, as a synonym for business requirement.

Business Process Reengineering

Business process reengineering was first defined outside the world of objects by Hammer and Champy. [6] The inclusion of the term here is simply to provide a bridge linking object thinking with business thinking. David Taylor illustrates how object thinking can be applied to the business enterprise as a whole, resulting in improved understanding and providing mechanisms for rethinking the enterprise itself. There is another important link between the ideas of business reengineering and thinking about objects. The better the object thinking, the more likely the need to reengineer the business so that it matches the simplicity, elegance , and flexibility of the new software. Object thinking almost necessarily reveals better ways to do business, even when that thinking is ostensibly directed toward software development.

Application

Application is the term used for a community of objects focused on accomplishing a well-defined set of collective responsibilities. As used here, the term application has almost the same meaning in object terms that it does in traditional software development.

Note  

We have come to the end of our vocabulary list and have not included one of the most mentioned terms in object literature ”reuse. There are several reasons for this. First, reuse is not a goal of object thinking; composability is. Composable objects will be reused as a matter of course, so reuse is but a byproduct of a more general goal. Second, there are ways to obtain reuse that are not related to object thinking ”code libraries, for example ”and the distraction is not really helpful. Lastly, reuse was once touted as the premier benefit of object orientation ”a claim that proved to be highly overstated. Worse, perhaps, was the claim that maximum reuse could best be obtained via inheritance. Object thinking claims to lead to the discovery and crafting of composable objects. The goal is to create a mindset that leads to evolving flexible applications and systems that directly reflect and support an application domain. Reuse will emerge, but it is not a driving force.

[5] Centralized hierarchical control and manipulation of passive data things: clearly, DBMS design, especially relational DBMS design, is not predicated on the kind of object philosophy and thinking discussed so far in this book.

[6] Hammer, Michael, and James Champy. Reengineering the Corporation , Revised Edition : A Manifesto for Business Revolution . Harper Business, 2001.




Microsoft Object Thinking
Object Thinking (DV-Microsoft Professional)
ISBN: 0735619654
EAN: 2147483647
Year: 2004
Pages: 88
Authors: David West

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net