Kĩ thuật lập trình - Lecture 17: Design patternspublisher - Subscriber

*Ivan MarsicRutgers UniversityLECTURE 17: Design PatternsPublisher-Subscriber*TopicsSoftware Design Patterns– What & WhyExample Pattern:Publisher-Subscriber (a.k.a. Observer)*What Developers Do With Software(besides development)Understand (existing software)Maintain (fix bugs)Upgrade (add new features)*The Power of PatternsCNNIBMAPPLE*The Power of Patterns*The Power of PatternsCNNIBMAPPLE*The Power of Patterns*The Power of PatternsCNNIBMAPPLECNNIBMAPPLE*Software Design PatternsDesign Patterns help anticipate software changeChange is needed to keep up with realityChange may be triggered by changing business environment or by deciding to refactor classes that are deemed potentially problematic e.g., using quality-screening metrics (see Chapter 4)Change may have bad consequences when there are unrelated reasons to change a software module/classUnrelated reasons are usually because of unrelated responsibilitiesChange in code implementing one responsibility can unintentionally lead to faults in code for another responsibilityAnother target is complex conditional logic (If-Then-Else statements, etc.)What May Change & HowWhat changes in real world are business rules  customer requests changes in softwareChanges in the small—changes in object responsibilities towards other objectsNumber of responsibilitiesData type, or method signatureBusiness rulesConditions for provision/fulfillment of responsibilitiesSometimes change is regular (follows simple rules), such as new object state defined, or another object needs to be notified about something*Object Responsibilities(toward other objects)Knowing something (memorization of data or object attributes)Doing something on its own (computation programmed in a “method”)Business rules for implementing business policies and proceduresCalling methods on dependent objects (communication by sending messages)Calling constructor methods; this is special because the caller must know the appropriate parameters for initialization of the new object.*Example Patternsfor Tackling ResponsibilitiesDelegating “knowing” and associated “doing” responsibilities (State)Delegating “calling” responsibilities (Command, Publisher-Subscriber)Delegating non-essential “doing” responsibilities (when “doing” responsibility incrementally modified) (Decorator)*Key IssuesWhen a pattern is needed/applicable?How to measure if a pattern-based solution is better?When to avoid patterns because may make things worse? All of the above should be answered by comparing object responsibilities before/after a pattern is applied**Publisher-Subscriber PatternA.k.a. “Observer”Disassociates unrelated responsibilitiesDecrease coupling, increase cohesionHelps simplify/remove complex conditional logic and allow seamless future adding of new casesBased on “Indirect Communication”?TFLike many other design patterns*Request- vs. Event-Based Comm.ClientServerRequest: doSomething( info )Request: getInfo()InfoSrcDoerinfo(1) Request: subscribe()InfoSrcDoer(2) event( info )(a)(b)(c)Direct CommunicationIndirect Comm.“Before” == A Scenario Suitable for Applying the Pub-Sub Pattern*Event DetectordetectEvent()Doer1.tellMeWhatToDo()Doer2.tellMeWhatToDo()DoerType1tellMeWhatToDo()DoerType2tellMeWhatToDo()ResponsibilitiesDoing:Detect eventsCalling dependencies:Tell Doer-1 what to doTell Doer-2 what to dounrelated! unrelated reasons to change the Event Detector: When event detection needs to change or extend When new doer types need to be told what to do“After” == Responsibilities After Applying the Pub-Sub Pattern*PublisherdetectEvent()subscriber.receive(Event)Subscriberreceive(Event)subscribers : ListUnrelated responsibilities of the Event Detector (now Publisher) are dissociated: When event detection needs to change or extend  change Publisher When new doer types need to be added  add an new Subscriber type (Subscribers need not be told what to do – they know what to do when a given event occurs!Labor Division (1)Before:Class A (and developer X) is affected by anything related to class BClassABWho developsdeveloper Xdeveloper YWho knows which methods of B to call, when, howdeveloper X—Who makes changes when classes of type B modified or new sub-types addeddeveloper X—developer Xdeveloper YLabor Division (2)After: Separation of developers’ dutiesDeveloper Y is completely responsible for class B ClassABWho developsdeveloper Xdeveloper YWho knows which methods of B to call, when, how—developer YWho makes changes when classes of type B modified or new sub-types added—developer Ydeveloper Xdeveloper Y*Publisher-Subscriber PatternFocused on detecting eventsThe focus in on the “Publisher” object and the “environment” that it is observing for “events”Example key events in safe home access:Entered key is validEntered key is invalidInstead of making decisions & issuing orders to Doers/SubscribersFocusing on other objects’ work: deciding when it is appropriate to call each one*Publisher-Subscriber PatternController (receives key-code)Key Checker (checks key validity, i.e., classifies: valid/invalid)Publishes the classification result to “subscribers”Lock ControlLight ControlAlarm ControlDo the work based on the received eventPUBLISHERSUBSCRIBERS( Assumed, during initialization: Subscribers subscribe for Events ≡ dependency graph construction )*Pub-Sub Pattern(a)(b)*Unlock Use CaseFrom Chapter 2This IF-THEN-ELSE must be changed when a new device type is introduced*Refactoring to Publisher-Subscriber1. Subscribe for appropriate eventsPubSub-1Sub-nPubSub-12. When event occurs: (a) Detect occurrence: keyIsValid / keyIsInvalid (b) Notify only the subscribers for the detected event classSub-nIf a new device is added -- just write a new class; NO modification of the Publisher!No need to consider the “appropriateness” of calling the “servers”SubscriberEvent typekeyIsValidkeyIsInvaliditIsDarkInside...LockCtrl, LightCtrlAlarmCtrlLightCtrlConditional logic is decided here, at design time, instead of run timeDesign-time decisions are better than runtime decisions, because they can be easier checked if they “work” (before the product is developed & deployed)Complexity due to decision making cannot disappear;It is moved to the design stage, which is early and easier to handle.The designer’s choice is then hard-coded, instead of checking runtime conditions.*Pub-Sub: Unlock Use CaseThis IF-THEN-ELSE needs NOT be changed when a new device type is introduced This class’s developer is not involved in new subscriber development & deployment*From Hub-and-Spokes (Star) to Token Passing (Cascading) ArchitecturePub-Sub reduced the class coupling:(dependency on an abstract type implies reduced coupling)Before:After:*Design Patterns: DelegationClientasks for serviceCustodianinitializes the patternInstantiation of theDesign Patterncollection of objects working to provide serviceAlternative names for Custodian are Assembler or Initializer*Pub-Sub: Initialization*Practical IssuesDo not design for patterns firstReaching any kind of solution is the priority;solution optimization should be secondaryRefactor the solution to patternsE.g., to reduce the complexity of the program’s conditional logicImportant to achieve a tradeoff between rapidly progressing towards the system completion versus perfecting the existing workUncritical use of patterns may yield worse solutions!