Object Oriented Design - Good , Bad and Ugly

Object Oriented Design (OO-D)
Good, Bad and Ugly
Amod Kadam
Cloud Manthan Software Solutions Pvt. Ltd.
Sep 2012
V 1.0 Cloud Manthan Software Solutions Pvt. Ltd. 1

MODULE 2 – DESIGN
Objective(s)
• To understand the why and what of design
Topics
• What and Why of Design ?
• Design Characteristics
• Design Process
• Design Principles
• Design Heuristics

What is DESIGN ?

What comes to mind ?

Design Perspective

What influences design ?

Defining Design

Some Design Definitions
• “It’s where you stand with a foot in two worlds—the world of
technology and the world of people and human purposes—and
you try to bring the two together”
- Creator of Lotus Notes - Mitch Kapor
• Software design is a process of problem solving and planning for
a software solution. After the purpose and specifications of
software are determined, software developers will design or
employ designers to develop a plan for a solution
- Wikipedia

WHY DESIGN ?
‘Writing a clever piece of code that works is one thing ; designing
something that can support a long lasting business is quite another’

Purpose of Design
• Solve problem
• Satisfy need
• Create mental model before building it
• Communicate with stakeholders
• Visualize Solution / Problem !
• Understand Complexity
• Create better experience
• Make Happy

Impact of Design
• Results in long lasting system
• Makes things work without problem
• Tries to avoid potential problem during construction or after
construction
• Gives pleasure
• Feel good
• Promotions
• Adverse Management Policy
• Sad
• Frustration
• Loosing jobs

DESIGN CONCEPTS
“Design is not the narrow application of formal skills, it is a way of
thinking”
- Chris Pullman

Context

Functionality

Easy to Use

Easy to Understand

Intuitive

Easy to maintain

What else ?
• Feel Good
• Easy to explain
• …

SOFTWARE DESIGN CHARACTERISTICS

Rigidity
• Tendency for software to be difficult to change, even in simple ways
• Every change causes a cascade of subsequent changes in dependent
modules
• Don’t know, with any reliability, when the change will be finished
• Manager fears to allow changes to software
• Official rigidity sets in
• Starts with design deficiency but leads to adverse management policy

Fragility
• Tendency of the software to break in many places every time it is
changed
• Breakage occurs in areas that have no conceptual relationship with
the area that was changed
• Fills the hearts of managers with a feeling that something bad will
happen
• Every time managers authorize a fix, they fear that the software
will break in some unexpected way
• Impossible to maintain

Immobility
• Inability to reuse software from other projects or from parts of the
same project
• Similar modules exists but with too much baggage
• Work and risk required to separate the desirable parts of the
software from the undesirable parts are too great to tolerate
• Simply rewritten instead of reused

Viscosity…
• Viscosity of the design
– Comes about when changes sets in and there are more than one ways to
make the change
– Some of the ways preserve the design, others do not (i.e. they are hacks.)
– Design preserving methods are harder to employ than the hacks, then the
viscosity of the design is high
– It is easy to do the wrong thing, but hard to do the right thing

… Viscosity
• Viscosity of the environment
– Comes about when the development environment is slow and inefficient
– High Compile Time
• Engineers will be tempted to make changes that don’t force large recompiles, even
though those changes are not optimal from a design point of view
– High Check in/Checkout
• Hours to check in just a few files

Modularity
• Separately named addressable components
• Allows a program to be intellectually manageable
• Easier to solve a complex problem when you break it into manageable
pieces
– Ease of development
– Ease of planning
– Software increments can be defined and delivered
– Changes can be more easily accommodated
– Testing and debugging can be conducted more effectively
• Don’t over modularize
– The simplicity of each small module will be overshadowed by the complexity
of Integration

Functional Independence
• Modules should have
– single-minded function
– aversion to excessive interaction with other modules
• Promote reuse and/or repurpose
• Easier to maintain and test
• Cohesion
– Qualitative Indication of Functional Independence
• Coupling
– Qualitative indication of the degree to which a module is connected to other
modules and outside world

Cohesion
• Degree to which the elements of a module belong together
• Coincidental cohesion (ugly)
– parts of a module are grouped arbitrarily (misc. classes)
• Logical Cohesion
– parts of a module are grouped because they logically are categorized to do the
same thing, even if they are different by nature
– e.g. grouping all mouse and keyboard input handling routines
• Temporal Cohesion
– parts of a module are grouped by when they are processed - the parts are
processed at a particular time in program execution
– E.g. catch an exception and close open files, creates an error log , notify user

…Cohesion
• Procedural Cohesion
– parts of a module are grouped because they always follow a certain sequence
of execution
– (e.g. a function which checks file permissions and then opens the file)
• Sequential Cohesion
– parts of a module are grouped because the output from one part is the input
to another part like an assembly line
– e.g. a function which reads data from a file and processes the data
• Functional Cohesion (Good)
– Parts of a module are grouped because they all contribute to a single well-
defined task of the module
– e.g. tokenizing a string of XML

Consequences of Low Cohesion
• Increased difficulty in understanding modules
• Increased difficulty in maintaining a system, because logical
changes in the domain affect multiple modules, and because
changes in one module require changes in related modules
• Increased difficulty in reusing a module because most applications
won’t need the random set of operations provided by a module

Coupling…
• In computing and systems design a loosely coupled system is one in
which each of its components has, or makes use of, little or no
knowledge of the definitions of other separate components
- Wikipedia
• In software engineering, coupling or dependency is the
degree to which each program module relies on each one of
the other modules.
- Wikipedia
• Software modules, objects will always have some form of
coupling

…Coupling…
• Content Coupling
– one module modifies or relies on the internal workings of another module
(e.g., accessing local data of another module)
• Global Coupling (common coupling)
– Sharing same global data
• External Coupling
– Sharing externally imposed data format , communication protocol
• Control Coupling
– Control coupling is one module controlling the flow of another, by passing it
information on what to do (e.g., passing a what-to-do flag)

Coupling…
• Data Structured Coupling (stamp)
– Share a composite data structure and use only a part of it, possibly a different
part
• Data Coupling
– share data through, for example, parameters
• Message Coupling
– message passing
• No Coupling
– Modules do not communicate at all with one another

…Coupling
- Wikipedia
Implications of Tight Coupling
•One module usually forces a ripple
effect of changes in other modules
•Assembly of modules might require
more effort and/or time due to the
increased inter-module dependency
•A particular module might be
harder to reuse and/or test because
dependent modules must be
included

DESIGN PROCESS

Design Process
• Incremental
• Iterative
• Focus on essential
aspects
• Intellectual
• Creative
• Rational
• Early designs never an
exact match of shipped
version
• Sloppy Process
• Nondeterministic

Sloppy Process
• Finished design looks well-organized ,clean but Process is Sloppy
• Process is Myopic
– Take False Steps and go down blind alleys
• Making mistakes is the point of design
• Design corrections are simpler than correcting after full blown code
• Hard to know when design is good enough ?
– Good Solution is subtly different than a poor one
• How much details is enough ?
• How do you know - When are you done ?

Nondeterministic
• Same problem is solved differently by each person
• Person Dependent ?
• No. of ways to solve problem
• Which one is correct ?

All about Tradeoffs
• Choosing one over another
• Is Fast Response Rate is a more important or minimizing development
time ?
• Is Scale critical or performance ?
• Is it configurability or performance ?
• Should be easy to use or development time critical ?
• ….

Heuristic Process
• Rules of Thumb
• Things to try which works in most of the cases
• Involves trial and error
• Not a repeatable process
• No guarantee that you will produce the exact same software design
elements

Controlling Possibilities
• Design should create possibilities
– Legal possibilities
– Consistent mechanism – way of doing
• Design should Partly restrict possibilities
– Bring discipline
– Prevent ad-hoc way of doing the things
– E.g. Constructing object in no. of ways - problematic

Refinement
• Process of elaboration
• Part of top-down design strategy
• Helps designer to specify the low-level details as design progresses

How to Create Good Design ?
• Design Principles
– Guiding philosophy
• Design Heuristics
– Rules of Thumb
• Refactoring
– Process of improving internal structure of code without modifying its
functionality

DESIGN PRINCIPLES

Principles , Patterns & Practices
Principles
Practices
Establish overriding
philosophy for guiding
designer
Design
Representations
(UML)
Software
Design
Guides in building
Heuristics
Patterns

Software Engineering Principles
• The Reason It All Exists - To provide value to its users
• Keep it Simple , Stupid ! (KISS)
• Maintain the Vision - Avoids ‘two [or more] minds’ about itself
• What You Produce, Others Will Consume
• Be Open to the Future
• Plan ahead for reuse

Design Modeling Principles
• Design should be traceable to the analysis model
• Design in the context of Architecture
• Design of data is as important as design of processing functions
• Interfaces must be designed with care
• User Interface design should be tuned to the needs of an end user
• Component-level design should be functionally independent
• Components should be loosely coupled to one another and to the external
environment
• Design representations should be easily understandable
• Strive for design simplicity with each iteration

SOFTWARE DESIGN HEURISTICS

Definition : Heuristics
• Heuristic ( Greek: "find" or "discover") refers to experience-based
techniques for problem solving, learning, and discovery
• Where an exhaustive search is impractical, heuristic methods are used to
speed up the process of finding a satisfactory solution
• Examples : a rule of thumb, an educated guess, an intuitive judgment,
or common sense

Where do we stand
• Day 1
– Module 1 – Setting the Context
– Module 2 – Design
– Module 3 – Object Oriented (OO) Paradigm
• Day 2
– Module 4 – OO Principles
– Module 5 – Design Patterns
– Module 6 – Creational Patterns

Cloud Manthan Software Solutions
Pvt. Ltd.
http://www.cloudmanthan.com
V 1.0 www.cloudmanthan.com 51
Cloud Manthan Software Solutions Private Limited
E-3,Lokmanya Pan Bazar,Opp. Everard Nagar
Chunabhatti (E) , Eastern Express Highway, Sion
Mumbai - 400 022
amod.kadam@cloudmanthan.com
+91 98923 00901

Object Oriented Design - Good , Bad and Ugly

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (20)

Similar to Object Oriented Design - Good , Bad and Ugly

Similar to Object Oriented Design - Good , Bad and Ugly (20)

More from amodkadam

More from amodkadam (7)

Recently uploaded

Recently uploaded (20)

Object Oriented Design - Good , Bad and Ugly

Editor's Notes