[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 16.html Wed Jan 11 07:25:57 PST 2012

Contents


    CSci 375/16 GRASP Revisitted


    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous15More Analysis401-413Q7(1-413)-
    Today16GRASP II413-435-W7(Model 2: use cases, domain, interactions, classes)
    Next17GoF435-476Q8(1-476)-

    (Close Table)

    Revision History


    Table
    Version#DateDescriptionAuthor
    02005-01-03Used boiler plate to make templateRJB
    12005-01-17Added section headingsRJB
    22005-03-02Added notesRJB
    32005-03-07Added notes and questionsRJB
    42006-02-16UpdateRJB
    52007-01-10Added link to project RJB
    62007-03-07Added notes on interfaces RJB
    72007-12-07Removing topic from schedule RJB
    82009-03-05Added sample codemfrom question answers RJB

    (Close Table)

    Chapter 25 GRASP II: Objects and Responsibilities

  1. Introduction

    Can you list the first 5 GRASP patterns without looking? [ 15answer.html ]

  2. *** 25.1 Polymorphism (vital)
  3. polymorphism::idea=following,
    1. A variable is declared as referring to a general type,
       		GeneralType * example;  //C++
    2. But is assigned to objects that are special types of that type
       		example = new SpecialType (data );
    3. Then the variable gets the behavior of the special type of object.
       		example -> function( moreData);

    Also see [ patterns.html#abstraction ]

  4. + Example: you call your Pet, and the Dog comes, but the Cat thinks about it.
  5. + Example: Snap Crackle Pop, Rice Crispies [ ../cs202/polymorphism.html#A Good Example ]
  6. * Example in NextGen: Tax calculation C++ Code: [ fig25_25_1.cpp ] [ test.fig25_25_1.cpp ] [ Sale.cpp ] [ TaxLineItems.cpp ]
  7. * Example in monopoly: squares
  8. +++ When you have a method with a switch or complex if-else-if-else... you've probably missed a chance to use polymorphism. Typical C++ code for
     			Player::Taketurn(...):
     	class Player
     	{
     		Square * location;
     		...
     		virtual Something takeTurn(....) //Fig 25.3 Page 417
     		{
     			...
     			location=board->getSquare(location, fvTot);
     			location->landedOn();
     		}
     		...
     	};
  9. Exercise [ test.poly.cpp ]
  10. +++ Notice! You don't get polymorphism until you have a pointer that points at a generalization/abstraction/interface. A pointer alone is Indirection. An inheritance hierarchy is the way things are!

  11. ***25.2 Pure Fabrication (vital)
  12. fabricate::= create | lie | make.
  13. Use it to gather similar responsibilities: persistence, dice cup, the web, an LDAP, etc. into a invented object/class.
  14. ***25.3 Indirection (vital)
  15. indirection::machine_code=When an instruction uses the address to find the address of the operand.
  16. Use to separate two objects that shouldn't be directly coupled.
  17. Tax calculator adapter
  18. Persistence
  19. ++ "Most network problems can be solved by adding a level of indirection"
  20. ++ Indirection fits with Polymorphism.
  21. ++ Also known as using a pointer in C++.

  22. ******25.4 Protected Variation or PV (vital)
  23. Hide hot points, design decisions, special concerns, etc. behind a common interface or object. Design your software so that bends rather than breaks by including "hinges" or flexible components.
  24. ***** Protected Variation is an explanation for Pure Fabrication, Polymorphism and Indirection. PV often is handled by combining indirection and polymorphism: point at the general, and define special kinds of variations.
  25. ** interesting philosophy on pages 428-432 covers several variations on PV.
  26. ** Note the anecdote on page 432: the cost of future proofing.
  27. ** Notice -- you need to document likely variations in your requirements
[ patterns.html ]

Exercises on GRASP

[ 16x.html ]

Next Quiz

Make sure you know the UML notations for interfaces and something about all the patterns (GRASP+GoF) covered up to the start of the quiz.

Online Tutorial on patterns

[ Category:Software_design_patterns ] (Vince Huston)

Questions and Answers

[ 16q.html ]

Next -- Back to the next iterations

[ 17.html ] including a quiz on UML interfaces and the GRASP+GoF.

Next Iteration of Project -- Model 2

[ w7.html ] due at start of class 17.

Review Questions

[ 16r.html ]

Standard Definitions

  • Artifact::="Anything that is created in the course of a project".
  • artifact::=see above.
  • DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  • Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  • Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  • GoF::="Gang of Four", [ patterns.html#GoF ]
  • GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  • Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  • KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  • OO::shorthand="Object-Oriented".

  • OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  • patterns::="Documented families of problems and matching solutions", see Patterns.
  • Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  • Process::="How to develop software".

  • RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  • RUP::Process="Rational UP", a proprietary version of UP.

  • SSD::="System Sequence Diagrams", see chapter 10.

  • TBA::="To Be Announced".

  • UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  • UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  • YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need now. In this class it also means "It won't be on the final or in quizzes".

  • XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.

    End