Programming Paradigm Seminar 4
-
Upload
neoxiuting -
Category
Documents
-
view
726 -
download
1
Transcript of Programming Paradigm Seminar 4
Seminar 4: Wrapping up
Programming Paradigms
[The Paradigms - Group 2]
2
3. Selecting Core Classes
2. Clarifying the Scope
1. Discovering Candidate Classes
CRC Card
Previous Seminar
3
This Seminar
6. Identifying Hierarchies
5. Assigning Collaborators
4. Assigning Responsibilities
3. Core Classes Identified
4. Assigning Responsibilities
Responsibilities includes the behaviors exhibited by a class or the knowledge which a class holds.
Account
Know balanceVerify customerAuthorize transactionTrack ActivityReport balance…
Collaboration
Behaviors
Knowledge
Assigning Responsibilities
Main TaskUse of scenarios and role play for the discovery of
responsibilities. Scenario:Withdrawing cash
from ATM
Assigning Responsibilities
Actor ATMActor Customer Receipt Printer Class
Key Rule of the Game
“Focus on What the classes need to do, not how they do it.”
Assigning Responsibilities
Let’s get it started…
1.Brainstorm First, Refine Later
2.Think Simple, Factor Out Complexity
3. Use Abstraction to Advantage
4. Don’t Marry One Solution, Play the Field First
Responsibility Detection Guidelines
Assigning Responsibilities
1. Brainstorm First, Refine Later.
Responsibility Detection Guidelines
Brainstorm to identify a set of candidate responsibilities for the core classes.
Strive for inclusion of responsibilities rather than exclusion
Assigning Responsibilities
Think in a more complex way will have most responsibilities listed in one of two classes.
2. Think Simple, Factor Out Complexity.
Responsibility Detection Guidelines
Account Class
WithdrawalClass
Deposit Class
BankCardClass
BalanceInquiryClass
Assigning Responsibilities
Reduce classes to “records”, which they simply know what information they hold.
2. Think Simple, Factor Out Complexity.
Assigning ResponsibilitiesResponsibility Detection Guidelines
Account
Accept Withdrawal…
Withdraw
Withdraw Funds…
Interacts
Aim to have distinct role for each classes to encourage reuse!
Abstract related classes which have common responsibilities to build hierarchies of classes.
3. Use abstraction to advantage.
Responsibility Detection Guidelines
Deposit
…
Withdrawal
…
Transfer
…
Inquiry
…
All of them execute a final transaction
Assigning Responsibilities
3. Use abstraction to advantage.
Responsibility Detection Guidelines
Abstract class make clear and cohesive responsibility assignment and take advantage of use polymorphism!
Abstract Transaction
Execute Transaction…
Deposit
Execute Transaction…
Withdrawal
Execute Transaction…
Transfer
Execute Transaction…
Inquiry
Execute Transaction…
Assigning Responsibilities
Responsibility Detection Guidelines
Experiment with different configuration of classes or assignments of responsibilities.
4. Don’t Marry One Solution, Play the Field First
Account
Know balanceVerify customerAuthorize transactionTrack ActivityReport balance
CollaborationChanging the CRC cards are easier
than changing the code later in the
project.
Assigning Responsibilities
4. Assigning Responsibilities
5. Assigning Collaborators
Guidelines
Using Scenarios and Role Play
Using Class Hierarchy
Using Dependencies
Using Client, Servers and Contract Map
Assigning Collaborators
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
Many practitioners uses role play and scenarios before listing the responsibilities
for each classes
Scenarios & Role Play Class Hierarchy Dependencies Client, Servers, Contracts
Assigning Collaborators
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
Scenarios & Role Play Class Hierarchy Dependencies Client, Servers, Contracts
Assigning Collaborators
Example
19
Scenarios & Role Play Class Hierarchy Dependencies Client, Servers, Contracts
Transactions
ExecuteFinancialTransaction()
Withdrawal
ExecuteFinancialTransaction()
Deposit
ExecuteFinancialTransaction()
BalanceInquiry
ExecuteFinancialTransaction()
Assigning Collaborators
Using Dependencies
• A class that depend on another for information
When dealing with dependencies think of encapsulation
Scenarios & Role Play Class Hierarchy Dependencies Client, Servers, Contracts
Assigning Collaborators
Example
21
Scenarios & Role Play Class Hierarchy Dependencies Client, Servers, Contracts
Transaction
ExecuteFinancialTransaction()
ReceiptPrinter
printReceipt()
Assigning Collaborators
Using Client, Servers and Contract Map
• Client is a class that requires service from another
• Servers are providers for the services
A Class can be a server and a client in a system
Scenarios & Role Play Class Hierarchy DependenciesClient, Servers,
Contracts
Assigning Collaborators
Using Client, Servers and Contract Map
• Contracts can be used to track client server collaboration
• Using role play can rapidly mapped out the collaboration
Alternative in using client server would be identifying of message passing in the
system
Scenarios & Role Play Class Hierarchy DependenciesClient, Servers,
Contracts
Assigning Collaborators
Example of ContractScenarios & Role Play Class Hierarchy DependenciesClient, Servers,
Contracts
Assigning Collaborators
Warning!!!!
• Collaborations can be hard to spot before role play
• Try to avoid class with the same responsibilities
5. Assigning Collaborators
6. Identifying Hierarchies
Guidelines
Look for “Kind-of” relationship
Do not confuse “Part-of ” with “Kind-of”
Name Key Abstractions
Look for Framework
Look for “Kind-of” relationship
• Find classes that
– Share Same Responsibilities
– Share Same Behavior
–Belong Together
Kind-of Part-of Name Key Abstractions Framework
Example
29
Transactions
# completeTransaction()
Withdrawal
# completeTransaction()
Deposit
# completeTransaction()
BalanceInquiry
# completeTransaction()
Kind-of Part-of Name Key Abstractions Framework
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
Kind-of Part-of Name Key Abstractions Framework
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
Kind-of Part-ofName Key
AbstractionsFramework
Example
Form
Secure Form
Kind-of Part-of Name Key Abstractions Framework
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
Kind-of Part-of Name Key Abstractions Framework
34
6. Identifying Hierarchy
5. Assigning Collaborators
4. Assigning Responsibilities
3. Selecting Core Classes
2. Clarifying the Scope
1. Discovering Candidate Classes
CRC Card
The CRC Card Technique
Thank you!
End of Presentation