Object oriented design part-1

http://simply-the-test.blogspot.in/2009/12/eat-it.html
1

No matter how far down the wrong road you’ve
gone, turn back.

- Turkish proverb

2

Object-Oriented Design
Part-I
Presented by

Ashok Guduru
Technical Architect

Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore

3


• How many people here write objectoriented code?


4


• How many people think they are
writing object-oriented code but
write procedural code?


5

It works on my machine syndrome!

http://simply-the-test.blogspot.in/2010/05/it-works-on-my-machine.html
6

A Use Case:
Imagine that we have a system that manages room
temperatures by applying heat to the rooms when
necessary.
The basic business, as explained by our expert, is that
each room has a desired temperature and a current
temperature. If the current temperature is lower than the
desired temperature, then heat must be pumped into the
room.
However, if there is no one in the room, then the
temperature can be left to fall 10 degrees below the
desired temperature.

7


Procedural Approach:
We create a HeatFlowRegulator program that gets the:
- desired temperature for a given room ID,
- the current temperature for a given room ID, and then a
- boolean for whether or not someone is in the room.
With this data the HeatFlowRegulator program figures
out if heat should be applied to the room with the given
room ID.


8


Object-Based Approach:
• We create a HeatFlowRegulator program that gets a
Room object. The HeatFlowRegulator program asks
the object for its current temp, desired temp and
whether or not someone is in the room.
• With this data the HeatFlowRegulator program
figures out if heat should be applied to the room.

9


Object-Oriented Approach:
• We create a HeatFlowRegulator program that
gets a Room object. The HeatFlowRegulator
program asks the Room if it needs heat.

Note: The aim of this example is to help you to see the
difference

10


What is Object-Oriented Design:
Object-oriented design is a method of design
encompassing the process of object-oriented
decomposition and a notation for depicting both logical
and physical as well as static and dynamic
models of the system under design.


11

Procedural code gets

information then makes
decisions.

Object-Oriented code tells
objects to do things.

--Alec Sharp

12


13


Why we prefer an O-O design approach when
developing software?


14


The number one reason to employ an
OO design when building software is
to reduce and manage complexity
through clarity and organization
Object-Oriented Design reduces the
Complexity when done it right

15


Off course! You cannot reduce the
complexity of a given task beyond a
certain point.

Once you've reached that point, you can
only shift the burden around


16


What is Object-Oriented Design?
Wikipedia: Object-oriented design is the process of
planning a system of interacting objects for the
purpose of solving a software problem.
It is one approach to software design.


17


The 4 Tenets (Characteristics or Principles) of
Object-Oriented Programming
• Abstraction
– Allows conceptualize and model the problem
domain without much details

• Encapsulation
– Enforces Modularity

• Inheritance
– Passes "Knowledge" Down

• Polymorphism
– Takes any Shape


18


Abstraction:
• The ability to represent data at a very conceptual level
(Model) without any concrete implementation details.
• Specifies what to do but not how to do

• The best definition is: “An abstraction denotes the
essential characteristics of an object that distinguish it
from all other kinds of object and thus provide crisply
defined conceptual boundaries, relative to the
perspective of the viewer.”
— Object-Oriented Design With Applications, by G. Booch


19


Abstraction:


20


Encapsulation:
• Encapsulation is the hiding of data
implementation by restricting access to
accessors and mutators.
• Immutable: Not directly changeable without the
knowledge of the object
• Object should be able to change its internal
implementation without breaking the
consumers

21


Encapsulation:


22


Modularity:

Modularity packages abstractions into discrete units.

23


Inheritance:
• Inheritance is the process by which a class
can be derived from a base class with all the
features of base class and some of its own.
• Inheritance is a way to establish “Is-a”
relationships between classes or objects


24


Polymorphism:
• Polymorphism means one name, many forms.
(Poly + Morph) Poly = Many, Morph = Form or Shape

• This is the ability to exist in various forms
• There are 2 basic types of polymorphism.
Overriding, also called run-time polymorphism,
and Overloading, which is referred to as
compile-time polymorphism

25

One test is worth a thousand expert opinions.
- Bill Nye, The Science Guy

26


Class != Object


27


Class is a Template. Nothing More!


28


Objects are little things and do
stuff for us.


29


Objects are instances.
Instances dot not necessarily look
like class


30


A good example of a Business Object:
Public class Blender
{
_Jug
_Base
Public Juice Blend (Ingredients)
}


31


Method Call = Message
Message/Method is a Pipeline. Using with you can
get the object do the required action


32


What is Object?
Objects are usually instances of classes, are used to
interact with one another to design applications.

• Object contains:
– Identification
– State (Data)
– Behavior (Operations and Capabilities)
• Capabilities: Flyable, Enumerable, Printable,
Drinkable, Shootable, Rotatable, Readable,
Writable, Serializable, Observable, Groupable
etc.)


33


What is Object?

An object has state, exhibits some well-defined behavior, and has a unique
identity.

34


What is Object?
• Objects are about behavior (exchanging messages by
method calls)
• Objects plays Roles. Roles will have Responsibilities
• Objects have Capabilities (to do things like e.g. Walk,
Run, Execute) and Collaborate with other objects to
do the things
• Roles and Capabilities are implemented using the
interfaces (and not by inheritance. You use Interfaces
to implement object's capabilities)

35


What is Object?
• Objects are NOT data. Objects are NOT data
clumps/buckets either
• An object without a Behavior (i.e., Only State
(Data)) is known as Anemic Domain Model


36


What is Object?
• Objects are always reference types (in C# or Java)
• Whenever you check for object's equality. it
will use its system generated identity (that is
in the memory). The contents are not used
rather the address of the memory is used.


37


What is Object?
• Object-Oriented is a Mental Model of the
Business. Highest level of Abstraction of the
Business

• Objects are principally about people and
their mental models—not polymorphism,
coupling and cohesion


38

Start with the hardest. Always tackle the most
difficult problems first, and leave the simple
one towards the end.

39


Object Relationships:
• "Is a" (which is Inheritance)
• "Has a“ (which is Composition)
• Always favor Composition (delegation) over Inheritance.
• Use Composition instead of Inheritance.
• Inheritance creates the strongest form of coupling

• An Employee is a Person hence you use inheritance
which leads to dependency and increases complexity.

40


• Is a
– e.g.
• Apple is a Fruit
• Employee is a Person
• Car is Vehicle

– Based on Inheritance
• Class Inheritance or Interface Inheritance

– Inheritance is unidirectional
• e.g. House is a Building. But Building is not a House

41


• Has a (Composition)
– e.g.
• Car has a Engine, Has 4 Tires (Aggregation)
• Car has a Chassis (Composition)
• House has Bathroom

– Means use of instance variables that are
references to other objects.
filled diamond

Composition
unfilled diamond

Aggregation

42


More Object Relationships
•
•
•
•
•
•
•

Is a kind of
Part of/Made Up of/Composition
Containment/Aggregation
Associated With
Helps Describe/Identifies
Feature of/Implementation
Uses

43


• Is a kind of – A Car is a kind of Vehicle, An
Orange is a kind of Fruit
– Implies inheritance

– Typically this relationship is called is-a, however
that is just not as clear. Using is-a often results in
a poor model with things like a Boss is-a
Employee which leads to roles being
implemented via inheritance.

44


• Part Of / Made Up Of /Composition – A page is part of
a book
– A book is made up of / composed of a Cover and Pages
– Implies that the part does not exist outside of the whole.
If you destroy a book, you destroy the cover and pages.
– Part-of relationships suggest that internal objects may be
best left hidden and accessed via methods on the parent

– myBook.TurnPage() instead of
myBook.Pages.TurnPage()

45


• Containment / Aggregation – Point of
Interests and Paths are contained in a Map
– One object acts as a container, grouping other
objects together for a purpose. The parts are not
dependent on the whole. If we destroy a Map,
the Points of Interest are not destroyed.


46


• Associated With – An author is associated
with a book and vice versa
– Associated With relationships suggest that the
related object is not owned by the parent like the
part of relationship, and is often accessible via
navigation through the domain model
– myBook.GetAuthors()
– myRaceCar.GetDriver()

47


• Helps Describe / Identifies - A Title helps
describe a Book
– Implies that the object is inherent to the parent
object and there is often less danger in exposing
the object outside of the parent


48


• Feature of / Implementation - Features of a Book
include its Width and Height
– Unlike an object that helps describe or identify
another object, a feature of an object is one that
should rarely if ever be exposed
– Business logic is naturally written around features of
objects. In fact, if an implementation-related object
is not referenced in the business logic of the parent
object we should consider removing the object

49


• Uses – A Book uses the Pages to get the
number of times a word appears in the book
– Clarifies collaboration among objects
– The uses relationships is often another
relationship aside from how two objects might be
related (Part of, Associated with, etc).


50

http://simply-the-test.blogspot.in/2012/07/about-bugs-and-monsters.html
51

Blame doesn’t fix bugs. Instead of pointing
fingers, point to possible solutions. It’s the
positive outcome that counts.

52


Value Object (VO):
• Create an object that is an attribute of another
object without any identity relative to the domain
and that can be interchangeable between objects
that use the same attribute.

• You have a Person and a Person has an Address.
You have a Company and a Company has an
address. The database may have a PersonAddress
table and a CompanyAddress table. However,
there is no need to create a PersonAddress object
and a Company Address object.

53


Value Object (VO):
• Value Objects are most important: VO are
probably the most important objects you guys
should create

• Are tiny, highly focused, immutable objects
• Are always value type. If you need to compare
two VO’s (for Equality), the contents will decide
its equality

54


Value Object (VO):
• VOs can your improve your design, reusability
and code quality
• e.g. Money, Address, Range, Quantity, Size,
Date, Point, Identity (Id), Key and Enums
• Ideally there never be any objects of type ints,
longs, strings, doubles, decimals in real
business.

55


Value Object (VO): Quantity
Quantity
-amount: Number
-unit: Unit
+,-,*,/
<,>, =
To(unit): quantity
ToString()
Parse(String): quantity
Equals() bool


56

Money Class…
public class Money: IComparable
{
private double amount;
private Currency currency;
public double amount() {
}
public Currency currency() {
}

public Money(double amount, Currency currency) {
}
public Money add(Money arg) {
}
public Money subtract (Money arg) {

}
public bool equals(Object arg) {
}
public int compareTo (Object arg) {
}

}

57

Don’t fall for the quick hack. Invest the energy
to keep code clean and out in the open.

58


Command Query Segregation (CQS):
• Separates the commands (actions) from queries
(asking for information). When designing the
objects, stick to and make sure the following
principles applied.
• Command: a Void method. Does something and can
optionally mutate the object’s state (data)
• Query: Always returns some value (answers to your
query). Never allow mutating the state (data)


59

Next …

Many Kinds of Objects:
•
•
•
•
•
•
•
•
•
•
•

Business Object
Business Object Collection
Candidate Object
Entity Object
Factory Object
Identity Object
Key Object
Manager Object
Service Object
Value Object
Data Transfer Object (POCO/POJO)

60


Model-View-Controller (MVC) Pattern
• MVC is Invented by Trygve Reenskaug
• It is NOT a UI Pattern: It is an Architectural pattern.
• MVC is more about mental model and we conceptualize the
system with it.
• It is mental model and user’s view of the system

• We see this pattern time and time again in several places. It has
good Separation of Concerns (SoC)

61


Model-View-Controller (MVC) Pattern

The goal of the Controller is to coordinate multiple views


62

Next Time…

Symptoms of Bad Software

•
•
•
•

Rigidity
Fragility
Inseparability
Viscosity


63

http://simply-the-test.blogspot.in/2010/04/different-goals.html


64

http://simply-the-test.blogspot.in/2010/04/different-goals.html

When a tester didn't find any cool bugs, then he basically
has two options to think about.
a) The software is good enough to go live
b) The software wasn't tested well enough

Typically, the developer thinks it is "a". And, of course,
the tester always fears it could be option "b".

65

Learn the new; unlearn the old. When learning a
new technology, unlearn any old habits that might
hold you back.

66

References
All the illustrations, images, and quotes are taken from the following books and web sites:

1.
2.

Object-Oriented Analysis and Design with Applications by Grady Booch
Practices of an Agile Developer by Venkat Subramaniam

3.
4.

Zelger’s Blog: http://www.zelger.org (http://simply-the-test.blogspot.in)
Martin Fowler Web Site: http://martinfowler.com


67

You have to experience what you want to express
-- Vincent van Gogh

Thank you!


68

Object oriented design part-1

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Object oriented design part-1

Ähnlich wie Object oriented design part-1 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Object oriented design part-1