4-object oriented design heuristics (object oriented software engineering - bnu spring 2017)

14

Click here to load reader

Upload: hafiz-ammar-siddiqui

Post on 11-Apr-2017

69 views

Category:

Education


2 download

TRANSCRIPT

Page 1: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

Object Oriented Design Heuristics

FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY

Page 2: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

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

Page 3: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

Classes and Objects

FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY

Page 4: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

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

Page 5: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

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

Page 6: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

Topologies of Procedure vs Object Oriented Applications

FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY

Page 7: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

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

Page 8: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

Relationships between Classes & Objects

FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY

Page 9: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

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

Page 10: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

The Inheritance Relationship

FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY

Page 11: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

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

Page 12: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

The Association Relationship

FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY

Page 13: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

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

Page 14: 4-Object Oriented Design Heuristics (Object Oriented Software Engineering - BNU Spring 2017)

Reference■ Object Oriented Design Heuristics by Arthur Riel, Addison-Wesley, 1996

FROM: HAFIZ AMMAR SIDDIQUI – COURSE: OBJECT ORIENTED SOFTWARE ENGINEERING – INSTITUTE: BEACONHOUSE NATIONAL UNIVERSITY