4-object oriented design heuristics (object oriented software engineering - bnu spring 2017)
TRANSCRIPT
Object Oriented Design Heuristics
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
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 heuristicsare 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
Classes and Objects
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
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
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
Topologies of Procedure vs Object Oriented Applications
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
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
Relationships between Classes & Objects
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
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
The Inheritance Relationship
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
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 sharingclass
■ 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 dataand methods
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
The Association Relationship
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY
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
Reference■ Object Oriented Design Heuristics by Arthur Riel, Addison-Wesley, 1996
FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY