4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)
0 likes441 views
The document discusses object-oriented design heuristics, providing simplified rules to enhance design practices while acknowledging that not all heuristics work cohesively. It elaborates on key principles such as data encapsulation, minimizing class dependencies, and avoiding complex relationships among classes. The text highlights best practices in class and object relationships, inheritance, and associations to create effective and maintainable software designs.
4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)
- 1. Object Oriented Design Heuristics FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 2. Object Oriented Design Heuristics ■ Heuristics are techniques used for solving a problem ■ Coding and designing are different skills ■ Design principles are complicated and difficult to implement but design heuristics are easier to learn and apply ■ Design heuristics are simple rules of thumb which help us avoid design pitfalls – Heuristics help and identify where design can be improved – Heuristics are not hard and fast rules – Not all heuristics work together – Some heuristics are opposite to each other – There are always trade-offs in design depending on which heuristics are applied – Sometimes heuristics are ignored in designs that are considered good FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 3. Classes and Objects FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 4. Classes and Objects ■ Hide data – All data should be hidden within its class ■ 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 ■ Minimize methods – Minimize the number of messages in the protocol of a class ■ Minimal public interface – Implement a minimal public interface which all classes understand ■ Avoid interface clutter – Do not clutter the public interface of a class with things that users of that class are not able to use or are not interested in using FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 5. Classes and Objects ■ Minimize classes interdependencies – A class should only use operations in the public interface of another class or have nothing to do with that class ■ One key abstraction – A class should capture one and only one key abstraction ■ Group related data and behavior – Keep related data and behavior in one place ■ Separate related data and behavior – Spin off non-related information into another class ■ Classes vs roles – Be sure the abstractions you model are classes and not the roles objects play FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 6. Topologies of Procedure vs Object Oriented Applications FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 7. Procedure vs Object Oriented Applications ■ Distribute system uniformly – Distribute system intelligence horizontally as uniformly as possible, that is, the top- level classes in a design should share the work uniformly ■ Avoid God classes – Do not create god classes/objects (classes that control all other classes). Be very suspicious of classes whose name contains Driver, Manager, System, Sub System ■ Avoid many accessors – 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 ■ Avoid non-communicating behavior – Beware of classes which have too much non-communicating behavior, i.e. methods which operate on a proper subset of the data members of a class FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 8. Relationships between Classes & Objects FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 9. Relationships between Classes & Objects ■ Minimize class collaborations – Minimize the number of classes with which another class collaborates ■ Minimize message collaborations – Minimize the number of message sends between a class and its collaborator ■ Containment rule – If a class contains objects of another class, then the containing class should be sending messages to the contained objects ■ Avoid contained objects relationships – Objects which share lexical scope, i.e. those contained in the same containing class, should not have uses relationships between them FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 10. The Inheritance Relationship FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 11. Inheritance Relationship ■ Inheritance for specialization – Inheritance should only be used to model a specialization hierarchy ■ Dependency inversion rule – Derived classes must have knowledge of their base class by definition, but base classes should not know anything about their derived classes ■ Common data class – If two or more classes only share common data (no common behavior) then that common data should be placed in a class which will be contained by each sharing class ■ Common base class – If two or more classes have common data and behavior (i.e. methods) then those classes should each inherit from a common base class which captures those data and methods FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 12. The Association Relationship FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 13. Association Relationship ■ Containment vs association – When given a choice in an object-oriented design between a containment relationship and an association relationship, choose the containment relationship FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
- 14. Reference ■ Object Oriented Design Heuristics by Arthur Riel, Addison-Wesley, 1996 FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY