MELJUN CORTES JAVA_OOD

8/10/2019 MELJUN CORTES JAVA_OOD

1/34

Object-Oriented

Design

Java Fundamentals and Object

Oriented Programming

MELJUN CORTES MBA MPA BSCS


2/34

What You Should Learn

1. What is a Good OO Program?

2. What is a Bad OO Program?

3. How Do We Write a Good OO Program?

4. Steps in Designing an OO Program


3/34

What is 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.


4/34

What is a Good OO

Program?

Unit-Testable

Each component should be independent of

other components, so can be tested in

isolation.


5/34

What is 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, itshould be intuitive to know where the lines of

code you need to change are located.


6/34

What is a Bad OO

Program?

Code Smells signs that there might be

something wrong with your code.


7/34

What is 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 dojust one thing, and do it well. Each object is so simple so as to minimize

bugs.


8/34

What is 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 signthat you have data clumps.


9/34

What is 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 awaythe details.


10/34

What is 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 differentbehaviors into specific subtypes.


11/34

What is a Bad OO

Program?

Refused Bequest

When a subclass does not use members

inherited from a superclass

Dangerous because those methods mightcause undesirable behavior in the subclass


12/34

What is a Bad OO

Program?

Alternative Classes with Different

Interfaces

Closely related classes should share the same

interface, so that they can be pluggable to theclient code.

Example: OracleConnectionManager and

MsSqlServerConnectionManager should

share the same interface.


13/34

What is a Bad OO

Program?

Shotgun Surgery

Several classes changed for every new

feature / change.

Maybe some code needs to be consolidated ina single class?


14/34

What is 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 tochange 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 changesand a different class is modified for new financial

instruments.


15/34

What is 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


16/34

What is 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


17/34

What is a Bad OO

Program?

Inappropriate Intimacy

when two classes are constantly accessing

each others members

maybe members of one should be moved tothe other or vice-versa

maybe a new class should be created to hold

common members


18/34

What is a Bad OO

Program? Message Chains

When a client asks for an object to get anotherobject, which it asks to get another object,which it asks to get another object... beforefinally being able to call the method it needs

Better to create a method in the first objectthat 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 togive more immediate access to the required data


19/34

What is a Bad OO

Program?

Too many comments

Comments are important, but maybe youre

writing comments because the code is not

readable in the first place? Code should be readable even without

comments.


20/34

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


21/34


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


22/34


Program?

The One Responsibility Rule Each class/method should only do ONE

THING

Name of class/method should express thatone thing

Long Class, Long Method and SwitchStatements are smells indicating this principleis being broken

Also known as Cohesiveness


23/34


Program?


Never ask an object for information that you

need to do something; rather, ask the objectthat has the information to do the work foryou.

- Allen Holub


24/34


Program?


Ask for help, not information.


25/34


Program?


The maintainability of a program is inversely

proportional to the amount of data that flowsbetween objects.

- James Goslinginventor of Java


26/34


Program?


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.


27/34


Program?

The Law of Demeter

Each unit should have only limitedknowledge about other units: only units

'closely' related to the current unit.


28/34


Program?

The Law of Demeter

Don't talk to strangers.


29/34


Program?

The Law of Demeter

Minimize the number of collaborators of aclass.


30/34


Program?

The Law of Demeter

A method "M" of an object "O" should invoke

only the methods of the following kinds of

objects:1. itself

2. its parameters

3. any objects it creates/instantiates

4. its direct component objects


31/34


Program?


Implementations


32/34


Program?


Implementations

Coordination between programmers

in a team is made easier if you

decide on the interfaces of eachclass first.

Each programmer is then at liberty to

change the implementations of his or

her classes without affecting the

work of other programers.


33/34


Program?

Well-Defined Interfaces,

Hidden Implementations

Supports parallel development.

Supports unit testing. Supports pluggability and

reuse.


34/34

Steps in Designing an OO

Program

1. Understand the bus iness requ i rements

2. Model the business domain

3. Define the layers of your application

Usually three: Presentation, Business &Integration

4. Define the interfaces of the classes you

need to implement each requirement5. Review and repeat as necessary

Documents

MELJUN CORTES JAVA_OOD