Fun 01B Ood

Object-Oriented
Design
Java Boot Camp

Module 1
Copyright 2008 Orange & Bronze Software Labs Ltd.Co. All Rights Reserved
What You Should Learn
 Signs of a Good OO Program
 Signs of a Bad OO Program
 How Do We Write a Good OO Program?
 Steps in Designing an OO Program
This training material was developed by Orange & Bronze Software Labs, Ltd. Co.
No part
Copyright of this
2008 material
Orange shouldSoftware
& Bronze be reproduced or usedAll
Labs Ltd.Co. outside
Rightsthe Academe
Reserved
without the consent of the company. www.orangeandbronze.com
Signs of a Good OO
Program
 Maintainable
 Unit Testable
 Understandable
 Traceable
Signs of a Good OO
Program
 Maintainable
 80% of the cost of a program is in
maintenance
 New features
 Bug fixes
 It should be easy to locate where to add new
features or where problems exist.
 Changes should only affect a few lines of
code.
 Changes in one component should not affect
others.
Signs of a Good OO
Program
 Unit-Testable
 Each component should be independent of
other components, so can be tested in
isolation.
Signs of a Good OO
Program
 Understandable
 It should be easy to read the code and
understand what it does.
 If you need to fix or change something, it
should be intuitive to know where the lines of
code you need to change are located.
Signs of a Good OO
Program
 Traceable
 It should be easy to find where each
requirement is implemented in the code.
 One should be able to easily see the business
model and business requirements just by
reading the code.
Signs of a Bad OO
Program
“Code Smells”
– signs that there might be something
wrong with your code.
Signs of a Bad OO
Program
 Large classes and long methods.
 Means your code is trying to do too much.
 OOP is about creating little programs
(objects) that do just one thing, and do it well.
 Each object is so simple so as to minimize
bugs.
Signs of a Bad OO
Program
 Primitive Obsession
 Using primitives / built-in classes instead of
creating own classes.
 Data Clumps
 Data that always appears together.
 Long Parameter List

 Methods have too many parameters. A sign
that you have data clumps.
Signs of a Bad OO
Program
 Primitive Obsession, Data Clumps, Long
Parameter List
 You should group data that are used together
into a more meaningful class. Abstract away
the details.
Signs of a Bad OO
Program
 Too many switch statements
 Sign that a method or class is trying to exhibit
too many behaviors.
 Use polymorphism to encapsulate different
behaviors into specific subtypes.
Signs of a Bad OO
Program
 Refused Bequest
 When a subclass does not use members
inherited from a superclass
 Dangerous because those methods might
cause undesirable behavior in the subclass
Signs of a Bad OO
Program
 Alternative Classes with Different
Interfaces
 Closely related classes should share the
same interface, so that they can be pluggable
to the client code.
 Example: “OracleConnectionManager” and
“MsSqlServerConnectionManager” should
share the same interface.
Signs of a Bad OO
Program
 Shotgun Surgery
 Several classes changed for every new
feature / change.
 Maybe some code needs to be consolidated
in a single class?
Signs of a Bad OO
Program
 Divergent Change
 Same class changed for different reasons.
 “Well, I will have to change these three methods
every time I get a new database and I have to
change these four methods every time there is a
new financial instrument.."
 Maybe the class needs to be split?
 Ex. One class is modified for database changes
and a different class is modified for new financial
instruments.
Signs of a Bad OO
Program
 Lazy class
 Class that doesn't do much, better just move
what it does to other classes then delete it
 Duplicate Code
 The number one sin!
 Dead Code
 unused code
Signs of a Bad OO
Program
 Feature Envy
 when a method excessively accesses the
data of another class
 better to move the method to the other class
Signs of a Bad OO
Program
 Inappropriate Intimacy
 when two classes are constantly accessing
each others members
 maybe members of one should be moved to
the other or vice-versa
 maybe a new class should be created to hold
common members
Signs of a Bad OO
Program
 Message Chains
 When a client asks for an object to get
another object, which it asks to get another
object, which it asks to get another object...
before finally being able to call the method it
needs
 Better to create a method in the first object
that returns the data that the client needs
 it could navigate the chain itself or the other
classes in the chain also need to be changed to
give more immediate access to the required data
Signs of a Bad OO
Program
 Too many comments
 Comments are important, but maybe you’re
writing comments because the code is not
readable in the first place?
 Code should be readable even without
comments.
How Do We Write a Good OO
Program?
 The Once and Only Once Rule
 The One Responsibility Rule
 The OO Prime Directive
 The Law of Demeter
 Well-Defined Interfaces, Hidden
Implementations
Program?
 The Once and Only Once Rule
 don't copy-paste
 keep functionality in one spot
 avoid shotgun-surgery, changes are easier
 bugs are easier to find and fix
Program?
 The One Responsibility Rule
 Each class/method should only do
ONE THING
 Name of class/method should express that
one thing
 Long Class, Long Method and Switch
Statements are smells indicating this principle
is being broken
 Also known as “Cohesiveness”
Program?
 The OO Prime Directive
 “Never ask an object for information that you
need to do something; rather, ask the object
that has the information to do the work for
you.” (Allen Holub)
 “Ask for help, not information.”
 “The maintainability of a program is inversely
proportional to the amount of data that flows
between objects.” (James Gosling, inventor of
Java)
Program?
 The OO Prime Directives
 The more one object has access to the
internals of another object, the more the
program can break when one object changes.
 Limiting the flow of data makes bugs easier to
find.
Program?
 “Each unit should have only limited
knowledge about other units: only units
'closely' related to the current unit.”
 “Don't talk to strangers.”
 Minimize the number of collaborators of a
class.
Program?
 A method "M" of an object "O" should invoke
only the methods of the following kinds of
objects:
 itself
 its parameters
 any objects it creates/instantiates
 its direct component objects
Program?
 Well-Defined Interfaces, Hidden
Implementations
Program?
 Well-Defined Interfaces,
Hidden Implementations
 Coordination between
programmers in a team is
made easier if you decide
on the interfaces of each
class first.
 Each programmer is then at
liberty to change the
implementations of his or
her classes without
affecting the work of other
programmers.
Program?
 Well-Defined
Interfaces, Hidden
Implementations
 Supports parallel
development.
 Supports unit testing.
 Supports pluggability
and reuse.
Steps in Designing an OO
Program
 Understand the business requirements
 Model the business domain
 Define the layers of your application
 Presentation, Business & Integration
 Define the interfaces of the classes you
need to implement each requirement
 Review and repeat as necessary

Fun 01B Ood

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Fun 01B Ood

Caricato da

Copyright:

Formati disponibili

Object-Oriented

Java Boot Camp

 Long Parameter List

Potrebbero piacerti anche