Fundamentals of Object-Oriented Design in UML

Author: Meilir Page-Jones List Price: $49.99 Our Price: Click to see the latest and low price ISBN: 020169946X Publisher: Addison-Wesley Pub Co (03 November, 1999) Edition: Paperback Sales Rank: 71,206 Average Customer Rating: 4.52 out of 5

Buy now directly from Amazon.com -

Customer Reviews

He catalogs attributes of object-oriented design by which we may intelligently discuss their quality: connascence, encumbrance, cohesion, type conformance, contravariance, covariance, closed behavior, ideal states, ideal behavior, and others. Patterns and anti-patterns are also exhibited, but the distinctive feature is the presentation of principles that all patterns must obey.

Each chapter begins with an overview and ends with a summary followed by exercises with answers. Be sure to read them all. The exercises are interesting, and the "summaries" sometimes (Chapters 5 and 6, for example) introduce new concepts.

The glossary is excellent. The bibliography is unfortunately not annotated. Some passages are over-peppered with footnotes, especially when their point is merely humorous. Overall the footnotes are valuable and the humor is appreciated.

The text takes care to reference backward and forward to related topics, helping readers to trace their own threads.

Some readers want more details about UML. Part II clearly describes a basic subset of UML probably sufficient for 90% of business scenarios, but many of the fine points are omitted.

Part III treats the reader to a series of thought-provoking discussions of the qualities of good software design. Some of the thoughts provoked involve differences of opinion that this reader would like to describe below. Before doing so, however, he must emphasize first just how valuable he found the time spent considering the ideas of Mr. Page-Jones and how strongly he advises others to spend their own time in a like fashion.

This reader was taken aback by the following advice: "Even when designing non-distributed applications, you should try to split a large class (one like Customer . . .) into several 'aspect' classes, using the composition construct to link their objects. For example . . . CustomerFinancials, CustomerShipping, and CustomerProfile. An object of class Customer would contain references to the objects of all three (p. 204)."

There could be in some cases justification for such splitting, but none is offered here. The point of the classes is to represent subjects in the business domain, not to categorize their attributes by their primary use. (And what's the difference between a Customer and a CustomerProfile anyway?)

The composition construct is intended to represent composites from the business perspective, not at the level of the meta-data. While it might be true that the DATA ABOUT the Customer is composed of financial attributes and shipping attributes, it is not true that the Customer ITSELF is a composite of things called "shipping" and "financials." The advice makes the classes model the data about the customer instead of modeling the customer itself.

Another similar pollution of the business perspective occurs in a class diagram showing class ResourceType as aggregate of ResourceInstance, accompanied by the explanation, " . . . all three class diagrams deal with types, each of which aggregates a bunch of instances (p. 391)."

Now, a "type class" always has the potential to be used to define aggregates of the objects of the "instance class." Whether it is in fact so used in a given business depends on the existence of a business operation appropriate for every object of the "type class" and affecting every object of the "instance class". But what operation can we define for class ResourceType equally appropriate for Employees, Rooms, and Whiteboards--and affecting every instance of one of them? Operation PAINT might apply to Rooms, but not to Employees. FIRE to Employees but not to Rooms. Even ERASE would not apply to every Whiteboard simultaneously.

If the business does not have aggregate operations on objects of a type, then the type should not be modeled as an aggregate. Every association having a maximum multiplicity of 1 for one class and * for the other is not an aggregation.

This reader read with great sympathy while Mr. Page-Jones bashed the "know how" cliché of object-oriented design, as in "a document should know how to print itself (p. 250)." In a subsequent footnote, he continues in the same vein: "I find this anthropomorphic view of object orientation to be specious and irrelevant (p. 251)."

It is difficult for this reader to understand how it can be a "lie (p. 247)" to say that a non-commissioned salesperson has a commission payment of $0 while it is not a lie to say that a non-dog-owner owns zero dogs (p. 251). Designers often treat an object "having zero" as belonging to a different class when it can be very truthfully represented as merely being in a different state of the same class. The situation gets further complicated when special names have arisen for the objects having zero (non-commissioned), for the objects having more than zero (dog-owner), or for both. The same problem occurs with the distinction between objects "having just one" and objects "having more than one" (single-family vs. multi-unit, for example).

Why does RectangleInFrame not inherit from Frame, asks Exercise 2 at the end of Chapter 13? The facile answer, "A rectangle is not a frame (p.344)," implies that software representations should never abbreviate the reality represented in order to realize a cost-saving simplification. Clearly, the case is otherwise. Why, even in the example that is the subject of this exercise we see some important--and justifiable--abbreviation: objects in the Rectangle class are represented with attributes recording their location in a coordinate system, even though location is not strictly speaking an inherent property of a rectangle. There might be circumstances where a shortcut permitting RectangleInFrame to inherit from Frame would be equally justifiable. Questions like this are better answered by describing the trade-off between accuracy of representation and complexity of implementation.

The book raised other minor quibbles and qualms, but mostly it left an abiding respect for the conciseness and the rigor of its design principles. Every software developer should learn them and apply.

Similar Products