This document discusses best practices for object-oriented Java design. It recommends learning design principles from books, conferences, and by analyzing code to see what works and doesn't work. Specific principles covered include the single responsibility principle, open/closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. Techniques demonstrated include using creation methods instead of constructors, replacing conditional logic with strategies, encapsulating classes with factories, and encapsulating composites with builders. The goal is to create well-designed, loosely coupled code that is easier to change and maintain.

1. Java - Better with
Design
Narayann Swaami
Agile Technical Coach
Societe Generale

2. Currently work as :
Agile Technical Coach @
http://www.socgensolutions.com/
16 yrs poking around, 10+ years on
Java
Interests:
Clean code, TDD,
Parallel/Concurrent programming
About me

3. Summary
There are many ways of approaching best practices
Learn on your own
Learn from Industry standard books
Learn from conferences/meetups

4. How this came about
Coaching teams - working with them
Analyze what worked AND what did not work
Inspect and Adapt!

5. What we will learn today
Interesting best practices - From “Refactoring To Patterns”

6. How we do this
→ μ- Workshop
→ Two - three examples [ Time-Dependent ]
→ Refactoring workflow
→ Interactivity

7. Better OOP is better Java
Why?

8. Better Design is Better Java
Why?

9. What comes to mind?
S.O.L.I.D

10. S.O.L.I.D in 120 seconds
SRP - Responsibility/Ease of change of a class
OCP - Strategy/Template Method + Interface
LSP - Car Is-a Vehicle [ Square Is-a Rectangle? ]
ISP - Many specific Interfaces
DIP - High Level / Low level modules ⇒ abstractions ⇐ details

11. Creating classes - move away from
Constructor?
Creating classes
● Use creation methods [not necessarily factory method - overkill]
● Chain Constructors
● Collecting Parameter
Consider ⇒ 3D Printed Building
What comes to mind?
● 3D Printed Building
● Area
● Dimensions
● Floors
Highlights
⇒ Intention-revealing names for
creation Methods
⇒ One constructor calling others in a
chain that follows a logical
Sequence (move to creation
Method)

12. Replace Conditional logic with Strategy
● For one of several variants of an algorithm
● Use a separate strategy for each variant and call accordingly
● 3DPrinter - how to print a building?

13. Code Study: Encapsulate classes with Factory
● “Program to interface, not to
implementation”
● “Client does not need to know where
the class resides”
● “Access through a common
interface”
● Use intention-revealing creation
Methods
Why?
See
http://grepcode.com/file/repository.grepcod
e.com/java/root/jdk/openjdk/8u40-
b25/java/util/Collections.java
Collections.synchronizedXYZ()
How?

14. Encapsulate Composite with Builder
● Let’s evaluate a Spec for the 3D
Printed Building
● Like configuration files
● Creation of composites can be error-
prone
● The XML Tag is joined by a composite
● Loose Coupling between client and
composite
Why How
● Create a builder
● Use builder to produce a one-node
Composite . Add a method to the
builder to obtain the result of its build
● Make the builder capable of building
children.
● Make the builder capable of setting
those attributes and values.
● Refactor to make it simpler

16. Reference

17. धन्यवादः।