More Related Content
Similar to Object Oriented Design: Part-1 (20)
Object Oriented Design: Part-1
- 2. No matter how far down the wrong road you’ve
gone, turn back.
- Turkish proverb
2
- 5. Object-Oriented Design
• How many people think they are
writing object-oriented code but
write procedural code?
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
5
- 6. It works on my machine syndrome!
http://simply-the-test.blogspot.in/2010/05/it-works-on-my-machine.html
6
- 7. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
7
- 8. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
8
- 9. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
9
- 10. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
10
- 11. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
11
- 12. Procedural code gets
information then makes
decisions.
Object-Oriented code tells
objects to do things.
--Alec Sharp
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
12
- 14. Object-Oriented Design
Why we prefer an O-O design approach when
developing software?
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
14
- 15. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
15
- 16. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
16
- 17. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
17
- 18. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
18
- 19. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
19
- 21. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
21
- 24. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
24
- 25. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
25
- 26. One test is worth a thousand expert opinions.
- Bill Nye, The Science Guy
26
- 31. Object-Oriented Design
A good example of a Business Object:
Public class Blender
{
_Jug
_Base
Public Juice Blend (Ingredients)
}
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
31
- 32. Object-Oriented Design
Method Call = Message
Message/Method is a Pipeline. Using with you can
get the object do the required action
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
32
- 33. Object-Oriented Design
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.)
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
33
- 34. Object-Oriented Design
What is Object?
An object has state, exhibits some well-defined behavior, and has a unique
identity.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
34
- 35. Object-Oriented Design
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)
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
35
- 36. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
36
- 37. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
37
- 38. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
38
- 39. Start with the hardest. Always tackle the most
difficult problems first, and leave the simple
one towards the end.
39
- 40. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
40
- 41. Object-Oriented Design
Object Relationships:
• 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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
41
- 42. Object-Oriented Design
Object Relationships:
• 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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
42
- 43. Object-Oriented Design
More Object Relationships
•
•
•
•
•
•
•
Is a kind of
Part of/Made Up of/Composition
Containment/Aggregation
Associated With
Helps Describe/Identifies
Feature of/Implementation
Uses
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
43
- 44. Object-Oriented Design
Object Relationships:
• 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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
44
- 45. Object-Oriented Design
Object Relationships:
• 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()
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
45
- 46. Object-Oriented Design
Object Relationships:
• 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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
46
- 47. Object-Oriented Design
Object Relationships:
• 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()
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
47
- 48. Object-Oriented Design
Object Relationships:
• 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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
48
- 49. Object-Oriented Design
Object Relationships:
• 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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
49
- 50. Object-Oriented Design
Object Relationships:
• 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).
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
50
- 52. Blame doesn’t fix bugs. Instead of pointing
fingers, point to possible solutions. It’s the
positive outcome that counts.
52
- 53. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
53
- 54. Object-Oriented Design
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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
54
- 55. Object-Oriented Design
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.
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
55
- 56. Object-Oriented Design
Value Object (VO): Quantity
Quantity
-amount: Number
-unit: Unit
+,-,*,/
<,>, =
To(unit): quantity
ToString()
Parse(String): quantity
Equals() bool
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
56
- 57. Object-Oriented Design
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) {
}
}
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
57
- 58. Don’t fall for the quick hack. Invest the energy
to keep code clean and out in the open.
58
- 59. Object-Oriented Design
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)
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
59
- 60. 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)
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
60
- 61. Object-Oriented Design
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)
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
61
- 63. Misconception
Common misconception between testers and project leaders/
managers:
There is never enough time and money to make things right
from ground up. The weird thing is that there is surprisingly
always enough of time and money to fix the problems later on.
http://simply-the-test.blogspot.in/2008/11/misconception.html
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
63
- 64. Next Time…
Symptoms of Bad Software
•
•
•
•
Rigidity
Fragility
Inseparability
Viscosity
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
64
- 66. 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".
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
66
- 67. Learn the new; unlearn the old. When learning a
new technology, unlearn any old habits that might
hold you back.
67
- 68. 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
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
68
- 69. You have to experience what you want to express
-- Vincent van Gogh
Thank you!
Copyright © 2013 Coextrix Technologies Pvt. Ltd., Bangalore
69