Programming Paradigm Seminar 4


Published on

  • Be the first to comment

  • Be the first to like this

Programming Paradigm Seminar 4

  1. 1. Seminar 4: Wrapping up<br />Programming Paradigms<br />[The Paradigms - Group 2]<br />
  2. 2. 2<br />Previous Seminar<br />
  3. 3. 3<br />This Seminar<br />
  4. 4.
  5. 5. Assigning Responsibilities<br />Responsibilities includes the behaviors exhibited by a class or the knowledge which a class holds.<br />Knowledge<br />Behaviors<br />
  6. 6. Assigning Responsibilities<br />Main Task<br />Use of scenarios androle play for the discovery of responsibilities.<br />Scenario:<br />Withdrawing cash from ATM<br />Actor Customer<br />Receipt Printer Class<br />Actor ATM<br />
  7. 7. Assigning Responsibilities<br />“Focus on What the classes need to do, not how they do it.” <br />Asking how a class behaves will result deriving false semantic distinctions which disallow the use of polymorphism.<br />
  8. 8. Assigning Responsibilities<br />Let’s get it started…<br />Responsibility Detection Guidelines<br />
  9. 9. Assigning Responsibilities<br />Responsibility Detection Guidelines<br />Brainstorm to identify a set of candidate responsibilities for the core classes. <br />Strive for inclusion of responsibilities rather than exclusion<br />
  10. 10. Assigning Responsibilities<br />Responsibility Detection Guidelines<br />Think in a more complex way will have most responsibilities listed in one of two classes.<br />Account Class<br />Deposit <br />Class<br />BankCard<br />Class<br />Insignificant to reuse<br />Insignificant to reuse<br />Inflexible to reuse<br />BalanceInquiry Class<br />Withdrawal<br />Class<br />Insignificant to reuse<br />Insignificant to reuse<br />
  11. 11. Assigning Responsibilities<br />Responsibility Detection Guidelines<br />Reduce classes to “records”, which they simply know what information they hold.<br />Interacts<br />Aim to have distinct role for each classes to encourage reuse!<br />
  12. 12. Assigning Responsibilities<br />Responsibility Detection Guidelines<br />Abstract related classes which have common responsibilities to build hierarchies of classes.<br />All of them execute a final transaction<br />
  13. 13. Assigning Responsibilities<br />Responsibility Detection Guidelines<br />Abstract class make clear and cohesive responsibility assignment and take advantage ofuse polymorphism!<br />
  14. 14. Assigning Responsibilities<br />Responsibility Detection Guidelines<br />Experiment with different configuration of classes or assignments of responsibilities.<br />Changing the CRC cards are easier than changing the code later in the project.<br />
  15. 15.
  16. 16. Assigning Collaborators<br />Guidelines<br />Using Scenarios and Role Play<br />Using Class Hierarchy<br />Using Dependencies<br />Using Client, Servers and Contract Map<br />
  17. 17. Use Scenarios and Role Play<br />Make a list of scenarios using the CRC core classes<br />Fill in the cards as you role play the different scenario<br />Assigning Collaborators<br />Many practitioners uses role play and scenarios before listing the responsibilities for each classes<br />
  18. 18. Using Class Hierarchy<br />Hierarchy is a signal for collaboration<br />Look up a hierarchy to class that is more abstract responsibilities<br />Look down a hierarchy to carry out more specialize responsibilities<br />Look for class that share same responsibilities<br />Assigning Collaborators<br />
  19. 19. Example<br />19<br />Assigning Collaborators<br />Transactions<br />Withdrawal<br />Deposit<br />BalanceInquiry<br />ExecuteFinancialTransaction()<br />ExecuteFinancial<br />Transaction()<br />ExecuteFinancial<br />Transaction()<br />ExecuteFinancial<br />Transaction()<br />
  20. 20. Using Dependencies<br />A class that depend on another for information<br />Assigning Collaborators<br />When dealing with dependencies think of encapsulation<br />
  21. 21. Example<br />21<br />Assigning Collaborators<br />Transaction<br />ReceiptPrinter<br />ExecuteFinancial<br />Transaction()<br />printReceipt()<br />
  22. 22. Using Client, Servers and Contract Map<br />Client is a class that requires service from another<br />Servers are providers for the services<br />Assigning Collaborators<br />A Class can be a server and a client in a system<br />
  23. 23. Using Client, Servers and Contract Map<br />Contracts can be used to track client server collaboration <br />Using role play can rapidly mapped out the collaboration<br />Assigning Collaborators<br />Alternative in using client server would be identifying of message passing in the system<br />
  24. 24. Example of Contract<br />Assigning Collaborators<br />Contract 1: Access and Modify Account Balance<br />Server: Account<br />Client: withdrawal, Transfer, Deposit, Inquiry<br />Description: Defines the manner in which account can be accessed or modified<br />
  25. 25. Warning!!!!<br />Collaborations can be hard to spot before role play<br />Try to avoid class with the same responsibilities <br />
  26. 26.
  27. 27. Guidelines<br />Look for “Kind-of” relationship<br />Do not confuse “Part-of ” with “Kind-of”<br />Name Key Abstractions<br />Look for Framework<br />
  28. 28. Look for “Kind-of” relationship<br />Find classes that<br /> Share Same Responsibilities<br />Share Same Behavior<br />Belong Together<br />
  29. 29. Example<br />Transactions<br />Withdrawal<br />Deposit<br />BalanceInquiry<br /># completeTransaction()<br /># completeTransaction()<br /># completeTransaction()<br /># completeTransaction()<br />29<br />
  30. 30. Do not confuse “Part-of ” with “Kind-of”<br />Part-of DO NOT:<br />Shared same behavior<br />A class maybe part of another class A and also a kind of another class B<br />
  31. 31. Name Key Abstractions<br />Name a key abstraction class<br />identify abstract classes that do not draw on colloquial ways of talking about system diagram<br />A single class that have choices depending on situation<br />
  32. 32. Example<br />
  33. 33. Look for Framework<br />This take advantage of successful framework rather then inventing them<br />Using of analysis pattern to help looking for your own frameworks<br />“Party” Pattern<br />
  34. 34. 34<br />The CRC Card Technique<br />
  35. 35. Thank you!<br />End of Presentation<br />