Your SlideShare is downloading. ×
Stoop 421-design heuristics
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Stoop 421-design heuristics


Published on

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. S.Ducasse 1 QuickTime™ and aTIFF (Uncompressed) decompressorare needed to see this picture. Stéphane Ducasse Design Heuristics
  • 2. S.Ducasse 2 License: CC-Attribution-ShareAlike 2.0
  • 3. S.Ducasse 3 Roadmap • Inspired from Object-Oriented • Design Heuristics by Arthur Riel • Read the Heuristics… • Find reasons why • We will discuss them during the lectures
  • 4. S.Ducasse 4 Different Relationships • Uses • Contains • Specializes
  • 5. S.Ducasse 5 Hidding Data • All data should be hidden within its class
  • 6. S.Ducasse 6 No Dependence on Clients • Users of a class must be dependent on its public interface, but a class should not be dependent on its users
  • 7. S.Ducasse 7 Class = one Clear Responsibility • Minimize the number of messages in the protocol of a class
  • 8. S.Ducasse 8 Supporting Polymorphism • Implement a minimal interface that all classes understand • To send the same message to different objects • To be able to substitute them • Remember: • grObjects do: [:each | each translate: 10@10] • Example: Object>>printString, Object>>copy…
  • 9. S.Ducasse 9 Clear Public Interface • Do not put implementations details such as common- code private functions into the public interface of a class • Example: • Private/protected in C++ • Private method categories in Smalltalk • Do not clutter the public interface of a class with items that clients are not able to use or are not interested in using
  • 10. S.Ducasse 10 Minimize Class Interdependencies • A class should only use operations in the public interface of another class or have nothing to do with that class
  • 11. S.Ducasse 11 Class = one Responsibility • A class should capture one and only one key abstraction
  • 12. S.Ducasse 12 Strengthen Encapsulation • Keep related data and behavior in one place • Spin off non related information into another class • => Move Data Close to Behavior
  • 13. S.Ducasse 13 Object: a Cohesive Entity • Most of the methods defined on a class should be using most of the instance variables most of the time
  • 14. S.Ducasse 14 Roles vs. Classes • Be sure the abstractions you model are classes and not the roles objects play • Are mother and father classes or role of Person? • No magic answer: Depend on the domain • Do they have different behavior? So they are more distinct classes
  • 15. S.Ducasse 15 one Class = one Responsibility • Distribute system intelligence horizontally as uniformly as possible, i.e., the top-level classes in a design should share the work
  • 16. S.Ducasse 16 one Class = one Responsibility • Do not create god classes/objects (classes that control all other classes). • Be very suspicious of class whose names contains Driver, Manager, System, SubSystem.
  • 17. S.Ducasse 17 Model and Interfaces • Model should never be dependent on the interface that represents it.The interface should be dependent on the model • What is happening if you want two different Uis for the same model?
  • 18. S.Ducasse 18 Basic Checks for God Class • Beware of classes that have many accessor methods defined in their public interface. May imply that data and behavior is not being kept at the same place • Beware of classes having methods that only operate on a proper subset of the instance variables.
  • 19. S.Ducasse 19 One Class: One Responsibility • One responbility: coordinating and using other objects • OrderedCollection maintains a list of objects sorted by arrival order: two indexes and a list • Class should not contain more objects than a developper can fit in his short-term memory. (6 or 7 is the average value)
  • 20. S.Ducasse 20 Classes Evaluation • Model the real world whenever possible • Eliminate irrelevant classes • Eliminate classes that are outside of the system • A method is not a class. Be suspicious of any class whose name is a verb or derived from a verb, especially those that only one piece of meaningful behavior
  • 21. S.Ducasse 21 Minimizing Coupling between Classes • Minimize the number of classes with which another class collaborates • Minimize the number of messages sent between a class and its collaborators • Counter example:Visitor patterns • Minimize the number of different messages sent between a class and its collaborators
  • 22. S.Ducasse 22 Use
  • 23. S.Ducasse 23 About the Use Relationship • When an object use another one it should get a reference on it to interact with it • Ways to get references • (containment) instance variables of the class • Passed has argument • Ask to a third party object (mapping…) • Create the object and interact with it
  • 24. S.Ducasse 24 Containment and Uses • If a class contains object of another class, then the containing class should be sending messages to the contained objects (the containment relationship should always imply a uses relationships) • A object may know what it contains but it should not know who contains it.
  • 25. S.Ducasse 25 Representing Semantics Constraints • How do we represent possibilities or constraints between classes? • Appetizer, entrée, main dish… • No peas and corn together… • It is best to implement them in terms of class definition but this may lead to class proliferation • => implemented in the creation method
  • 26. S.Ducasse 26 Objects define their logic • When implementing semantic constraints in the constructor of a class, place the constraint definition as far down a containment hierarchy as the domain allows • => Objects should contain the semantic constraints about themselves
  • 27. S.Ducasse 27 Third party constraint holder • If the logic of a constraint is volatile, then it is better to represent it in a separate object
  • 28. S.Ducasse 28 Classes - Subclasses • Superclass should not know its subclasses • Subclasses should not use directly data of superclasses • If two or more classes have common data and behavior, they should inherit from a common class that captures those data and behavior
  • 29. S.Ducasse 29 Controversial • All abstract classes must be base classes • All base classes should be abstract classes • => Not true they can have default value method
  • 30. S.Ducasse 30 Avoid Type Checks • Explicit case analysis on the type of an objects is usually an error. • An object is responsible of deciding how to answer to a message • A client should send message and not discriminate messages sent based on receiver type
  • 31. S.Ducasse 31 Summary Digest Read code Think about it Be critic