6. Assigning Responsibilities Main Task Use of scenarios androle play for the discovery of responsibilities. Scenario: Withdrawing cash from ATM Actor Customer Receipt Printer Class Actor ATM
7. Assigning Responsibilities “Focus on What the classes need to do, not how they do it.” Asking how a class behaves will result deriving false semantic distinctions which disallow the use of polymorphism.
9. Assigning Responsibilities Responsibility Detection Guidelines Brainstorm to identify a set of candidate responsibilities for the core classes. Strive for inclusion of responsibilities rather than exclusion
10. Assigning Responsibilities Responsibility Detection Guidelines Think in a more complex way will have most responsibilities listed in one of two classes. Account Class Deposit Class BankCard Class Insignificant to reuse Insignificant to reuse Inflexible to reuse BalanceInquiry Class Withdrawal Class Insignificant to reuse Insignificant to reuse
11. Assigning Responsibilities Responsibility Detection Guidelines Reduce classes to “records”, which they simply know what information they hold. Interacts Aim to have distinct role for each classes to encourage reuse!
12. Assigning Responsibilities Responsibility Detection Guidelines Abstract related classes which have common responsibilities to build hierarchies of classes. All of them execute a final transaction
13. Assigning Responsibilities Responsibility Detection Guidelines Abstract class make clear and cohesive responsibility assignment and take advantage ofuse polymorphism!
14. Assigning Responsibilities Responsibility Detection Guidelines Experiment with different configuration of classes or assignments of responsibilities. Changing the CRC cards are easier than changing the code later in the project.
15.
16. Assigning Collaborators Guidelines Using Scenarios and Role Play Using Class Hierarchy Using Dependencies Using Client, Servers and Contract Map
17. Use Scenarios and Role Play Make a list of scenarios using the CRC core classes Fill in the cards as you role play the different scenario Assigning Collaborators Many practitioners uses role play and scenarios before listing the responsibilities for each classes
18. Using Class Hierarchy Hierarchy is a signal for collaboration Look up a hierarchy to class that is more abstract responsibilities Look down a hierarchy to carry out more specialize responsibilities Look for class that share same responsibilities Assigning Collaborators
20. Using Dependencies A class that depend on another for information Assigning Collaborators When dealing with dependencies think of encapsulation
21. Example 21 Assigning Collaborators Transaction ReceiptPrinter ExecuteFinancial Transaction() printReceipt()
22. Using Client, Servers and Contract Map Client is a class that requires service from another Servers are providers for the services Assigning Collaborators A Class can be a server and a client in a system
23. Using Client, Servers and Contract Map Contracts can be used to track client server collaboration Using role play can rapidly mapped out the collaboration Assigning Collaborators Alternative in using client server would be identifying of message passing in the system
24. Example of Contract Assigning Collaborators Contract 1: Access and Modify Account Balance Server: Account Client: withdrawal, Transfer, Deposit, Inquiry Description: Defines the manner in which account can be accessed or modified
30. Do not confuse “Part-of ” with “Kind-of” Part-of DO NOT: Shared same behavior A class maybe part of another class A and also a kind of another class B
31. Name Key Abstractions Name a key abstraction class identify abstract classes that do not draw on colloquial ways of talking about system diagram A single class that have choices depending on situation
33. Look for Framework This take advantage of successful framework rather then inventing them Using of analysis pattern to help looking for your own frameworks “Party” Pattern
Discovering Candidate ClassesRead Requirements DocumentsUnderline nouns and noun phrasesAdd them to candidate class listBrainstorm to find other potential classesClarifying the ScopeSelecting Core ClassesArchitectural DesignIdentify hot spotsUse appropriate design patternsTake advantage of existing software frameworksEliminate Unnecessary ClassesRemove ghost classesCombine synonyms Distinguish attributes from classes
Discovering Candidate ClassesRead Requirements DocumentsUnderline nouns and noun phrasesAdd them to candidate class listBrainstorm to find other potential classesClarifying the ScopeSelecting Core ClassesArchitectural DesignIdentify hot spotsUse appropriate design patternsTake advantage of existing software frameworksEliminate Unnecessary ClassesRemove ghost classesCombine synonyms Distinguish attributes from classes
Behavior:Do things that meet the demands of the uses of the systemKnowledge: Supply information about themselves
Strive for inclusion of relevant responsibilities rather than exclusion. Don't worry about duplication. Later refine the lists of responsibilities. Name each carefully. Given a set of core classes:Brainstorm to identify a set of candidate responsibilities for the core classes.
Instead of having all responsibilities listed in one or two classes, which is more towards a procedural perspective. Does not take advantage of Polymorphism and encapsulation.ATM example: A tendency might be to give most of the responsibility to the Account class, which becomes a strong, busy "manager" procedure giving commands to relatively weak, ill-defined "worker" classes. Account is probably too inflexible to be directly reused; the other classes are probably too insignificant to be reused. Give each class a distinct role in the system. Strive to make each class a well-defined, complete, cohesive abstraction. Such a class has higher probability of being reused. ATM example: Give class Withdrawal the responsibility "Withdraw Funds", making it potentially useful to any other class needing to do a withdrawal. Give class Account the responsibility "Accept Withdrawal", which will, of course, be carried out by collaborating with Withdrawal. Factoring out complexity also involves identifying specialized behaviors that occurs repeatedly and, as appropriate, spinning off new classes. ATM example: The capturing and responding to user requests might be factored out into a new class Form with a responsibility "ask user for information".
Instead of having all responsibilities listed in one or two classes, which is more towards a procedural perspective. Does not take advantage of Polymorphism and encapsulation.ATM example: A tendency might be to give most of the responsibility to the Account class, which becomes a strong, busy "manager" procedure giving commands to relatively weak, ill-defined "worker" classes. Account is probably too inflexible to be directly reused; the other classes are probably too insignificant to be reused. Give each class a distinct role in the system. Strive to make each class a well-defined, complete, cohesive abstraction. Such a class has higher probability of being reused. ATM example: Give class Withdrawal the responsibility "Withdraw Funds", making it potentially useful to any other class needing to do a withdrawal. Give class Account the responsibility "Accept Withdrawal", which will, of course, be carried out by collaborating with Withdrawal. Factoring out complexity also involves identifying specialized behaviors that occurs repeatedly and, as appropriate, spinning off new classes. ATM example: The capturing and responding to user requests might be factored out into a new class Form with a responsibility "ask user for information".
Build hierarchies of classes. Abstract the essence of related classes by identifying where they have common responsibilities -- where they do the same thing, but do it differently -- same "what", different "how". That is, look for opportunities for the classes to use polymorphism to implement the same responsibility differently. The new parent classes may be abstract classes. That is, no actual objects may ever exist of that type. The abstract class exists to link together similar concrete types of objects. ATM example: Create an abstract class Transaction that is a superclass for Withdrawal, Deposit, etc. It can have an abstract responsibility "execute a financial transaction", that is implemented differently for each subclass
Build hierarchies of classes. Abstract the essence of related classes by identifying where they have common responsibilities -- where they do the same thing, but do it differently -- same "what", different "how". That is, look for opportunities for the classes to use polymorphism to implement the same responsibility differently. The new parent classes may be abstract classes. That is, no actual objects may ever exist of that type. The abstract class exists to link together similar concrete types of objects. ATM example: Create an abstract class Transaction that is a superclass for Withdrawal, Deposit, etc. It can have an abstract responsibility "execute a financial transaction", that is implemented differently for each subclass
The cards are either physical cards or electronic which are both inexpensive to erase. Don’t hesitate to make changes early in CRC cards, than make changes later in the code.
Discovering Candidate ClassesRead Requirements DocumentsUnderline nouns and noun phrasesAdd them to candidate class listBrainstorm to find other potential classesClarifying the ScopeSelecting Core ClassesArchitectural DesignIdentify hot spotsUse appropriate design patternsTake advantage of existing software frameworksEliminate Unnecessary ClassesRemove ghost classesCombine synonyms Distinguish attributes from classes
![Seminar 4: Wrapping up Programming Paradigms [The Paradigms - Group 2]](https://image.slidesharecdn.com/seminar4-notreleased-110410101026-phpapp02/85/Programming-Paradigm-Seminar-4-1-320.jpg)
