 Jens Bennedsen 2002Objektorienteret systemudvikling GRASP mønstre Basale ansvarsplaceringsregler.

Præsentationer af emnet: " Jens Bennedsen 2002Objektorienteret systemudvikling GRASP mønstre Basale ansvarsplaceringsregler."— Præsentationens transcript:

1  Jens Bennedsen 2002Objektorienteret systemudvikling GRASP mønstre Basale ansvarsplaceringsregler

2  Jens Bennedsen 2002Objektorienteret systemudvikling Objektorienteret design Der er mange mulige aktiviteter og artifakter i analyse og design, og en masse principper og guidelines. Hvis vi skulle vælge én ting blandt alle dem der er diskuteret - ”en øde ø egenskab” - hvad skal det så være? Hvorfor? Fordi det er den eneste aktivitet der SKAL udføres og den har den mest vidtrækkende effekt på rubusthed, vedligeholdbarhed og genbrug. Craig Larman, 1998 Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design The most single important ability in object- oriented analysis and design is to skillfully assign responsibilities to software components.

3  Jens Bennedsen 2002Objektorienteret systemudviklingInteraktion.3 Kontrakt En beskrivelse af en klasse kan opfattes som en kontrakt: Udlejning start(nr) end duration number Anvender Kan anvende egenskaberne men ikke andet Implementør Kan opfylde egenskaberne men ikke andet

4  Jens Bennedsen 2002Objektorienteret systemudvikling GRASP Patterns (Larman) What are the GRASP patterns? –The GRASP patterns describe fundamental principles of assigning responsibilities to objects, expressed as patterns –Patterns are named problem/solution pairs that codify good advice and principles The patterns –Expert –Creator –Low coupling –High cohesion –Controller –Polymorphism –Pure Fabrication –Indirection –Protected variations

5  Jens Bennedsen 2002Objektorienteret systemudvikling Goals Two types of patterns High Cohesion Low Coupling Information Expert CreatorControler Polymorphism

6  Jens Bennedsen 2002Objektorienteret systemudvikling Expert Which class is responsible for performing an operation? Expert Pattern –Assign a responsibility to the class or classes that have the information required to carry out the responsibility! Where to place the pris() operation?

7  Jens Bennedsen 2002Objektorienteret systemudvikling Creator Who is responsible for creating an object? Creator pattern –Determine which class should create instances of a class based on the relationship between the potential creator classes and the class to be created B is responsible for creating A if: –Instances of B composes or aggregates inst. of A –Instances of B contains inst. of A –Instances of B records inst. of A –Instances of B directly uses inst. of A –Instances of B have the data that is passed to constructors of A

8  Jens Bennedsen 2002Objektorienteret systemudvikling Controller Who handles a system event? –A special class (normally not a ”domain class”) –Facade controller A small system Gets easy low cohesive (blured controller) –Use case controller A larger system More cohesive

9  Jens Bennedsen 2002Objektorienteret systemudvikling Low coupling Coupling –Dependencies between one class and other classes’ properties We shall strive for low coupling –Minimize the dependency of other classes properties Why? –To minimize rippling when modifying classes so that changes only have local consequences.

10  Jens Bennedsen 2002Objektorienteret systemudvikling What does coupling look like?

11  Jens Bennedsen 2002Objektorienteret systemudvikling High cohesion The inner relatedness within the properties of a class Strive for uniqueness within a class –Maximize the uniqueness of a class’ responsibility –Maximize the mutual connection between the properties within a class Strive for a high degree of cohesion!

12  Jens Bennedsen 2002Objektorienteret systemudvikling On coupling and cohesion If –a class is so highly coupled or lacking in cohesion as to make a design brittle or difficult to modify... Then –apply other appropriate GRASP patterns to reassign the class’s responsibilities.

13  Jens Bennedsen 2002Objektorienteret systemudvikling Polymorphism Avoid if-statements –When alternate behaviours are selected based on the type of an object, use a polymorphic method call to select the behaviour rather that using if statements to test on the type