Lecture 30: OO DesignHeuristicsKenneth M. AndersonObject-Oriented Analysis and DesignCSCI 6448 - Spring Semester, 2003April 24, 2003 © University of Colorado, 2003 2Credit is where Credit is Due Some material for this lecture is takenfrom Object-Oriented Design Heuristics by Arthur J. Riel ISBN: 0-201-63385-X as such, it is copyright, © 1999, by AddisonWesleyApril 24, 2003 © University of Colorado, 2003 3This Lecture Cover OO Design Heuristics Classes and Objects Topologies of Procedural versus Object-Oriented Applications Relationships between Classes andObjects The Inheritance Relationship Multiple InheritanceApril 24, 2003 © University of Colorado, 2003 4Typical Problem I have created an OO design for mysystem Is it good? Bad? Somewhere in between? Ask an OO “guru” A design is good when “it feels right” So, how do we know when it feels right?April 24, 2003 © University of Colorado, 2003 5One Approach: Design Heuristics “The guru runs through a subconsciouslist of heuristics, built up through his orher design experience, over the design.If the heuristics pass, then the designfeels right, and if they do not pass, thenthe design does not feel right” from Object-Oriented Design Heuristics by Arthur J. RielApril 24, 2003 © University of Colorado, 2003 6Riel’s Take We would be in a sorry state if we dependedon designers to gain heuristics only throughexperience Riel’s book documents 61 heuristics that he has developed working as a faculty member atNortheastern University and as a consultant on real-world OO A&Dsoftware development projects Lets take a look at a some of these heuristicsApril 24, 2003 © University of Colorado, 2003 7Note on Heuristics Not all heuristics work together Some are directly opposed! This occurs because there are always trade-offs in analysis and design Sometimes you want to make a change to reducecomplexity…this may have the consequence thatit also reduces flexiblity You will have to decide which heuristic makes themost sense for your particular contextApril 24, 2003 © University of Colorado, 2003 8Classes and Objects Heuristics All data should be hidden within its class When a developer says “I need to make this piece of data public because…” They should ask themselves “What is it that I’m trying to do with the data and whydoesn’t the class perform that operation for me?” Users of a class must be dependent on its publicinterface, but a class should not be dependent onits users Why?April 24, 2003 © University of Colorado, 2003 9Classes and Objects, continued Heuristics Minimize the number of messages in the protocolof a class The problem with large public interfaces is that you cannever find what you are looking for…smaller publicinterfaces make a class easier to understand and modify Do not put implementation details such ascommon-code “helper” functions into the publicinterface of a class Users of a class do not want to see operations in thepublic interface that they are not supposed to useApril 24, 2003 © University of Colorado, 2003 10Classes and Objects, continued Heuristics Classes should only exhibit nil or export couplingwith other classes, that is, a class should only useoperations in the public interface of another classor have nothing to do with that class This resonates with what we have seenbefore on coupling earlier in the semester nil coupling: no coupling export coupling: make use of public interface overt coupling: make use of private detailsApril 24, 2003 © University of Colorado, 2003 11Classes and Objects, continued Heuristics A class should capture one and only one key abstraction e.g. a class should be cohesive; Riel defines “key abstraction”as an element of the problem domain Keep related data and behavior in one place Similar to the “Move Method” refactoring pattern Spin off non-related information into another class Similar to the “Extract Class” refactoring pattern (not covered) Most of the methods defined on a class should be usingmost of the data members most of the time All of these heuristics deal with class cohesionApril 24, 2003 © University of Colorado, 2003 12Topologies of Procedural vs.OO Applications These heuristics help you identify the use ofnon-OO structures in OO Applications Procedural topologies break an application downby functions, which then share data structures while it is easy to see which functions access which datastructures, it is difficult to go the other way, to see whichdata structures are used by which functions The problem: a change to a data structure may haveunintended consequences because the developer wasnot aware of all the dependencies on the data structureApril 24, 2003 © University of Colorado, 2003 13Typical problems There are two typical problems thatarise when developers familiar withprocedural techniques try to create anOO design The God Class A single class drives the application, all otherclasses are data holders Proliferation of Classes Problems with modularization taken too farApril 24, 2003 © University of Colorado, 2003 14OO Topologies Heuristics (God Class) Distribute system intelligence horizontallyas uniformly as possible, that is, the top-level classes in a design should share thework uniformly Do not create god classes/objects in yoursystem. Be very suspicious of a classwhose name contains “Driver”, “Manager”,“System”, or “Subsystem”April 24, 2003 © University of Colorado, 2003 15OO Topologies Heuristics (God Class) Beware of classes that have many accessormethods defined in their public interface. Havingmany implies that related data and behavior arenot being kept in one place Beware of classes whose methods operate on aproper subset of the data members of a class.God classes often exhibit this behaviorApril 24, 2003 © University of Colorado, 2003 16OO Topologies, continued God Class Example A heat flow regulator needs to decide whento activate a furnace to keep a room at acertain temperature Consider the following three designs Unencapsulated Encapsulated Distributed IntelligenceApril 24, 2003 © University of Colorado, 2003 17God Class ExampleDesired TempActual TempOccupancyHeat FlowRegulatorFurnacetemp()temp()occupied()UnencapsulatedApril 24, 2003 ©
View Full Document
Unlocking...