DESIGN

erik@codeborne.com

Erik Jõgi

Why design matters?

Longevity.

Code is used for years and years.

productivity vs time

Prod

uctiv

ity

0

25

50

75

100

Time

CLEAN CODE

Clean Code A Handbook of Agile

Software Craftsmanship

Robert C. Martin, 2008“Uncle Bob”

–Ward Cunninghaminventor of Wiki and Fit

co-inventor of eXtreme Programming

“You know you are working on clean code when each routine you read

turns out to be pretty much what you expected.”

FOUR ELEMENTS OF SIMPLE DESIGN

1. Passes all tests

2. No duplication

3. Expresses intent

4. Small

Kent Beck — Creator of Extreme Programming, author of JUnit

NAMINGvariables, methods, classes, ...

let’s look at some examples…

CORRECT ENGLISH ONLY, PLEASE!

• Word-for-word translation might not be the correct solution

• Use correct domain terminology - ask domain experts what they use

• Spelling and grammar

• Can you read your code like a story?

USE THE SAME TERM CONSISTENTLY

• Customer – Client – Party – Counterparty

• state – status

• Contract – Agreement

• get – load – fetch – find – retrieve

• regCode – regNumber – personalCode

• … and don’t reuse the same term in another meaning/context

FUNCTIONS

A GOOD FUNCTION• short

• very few indentation levels

• does only one thing - only one level of abstraction

• “Functions should do one thing. They should do it well. They should do it only.” —Robert “Uncle Bob” Martin

for example…

FUNCTION ARGUMENTS

• Less is more!

• Ideally none, one and two are OK

• Three is usually too much, anything more is a design smell

for example…

NO SIDE-EFFECTS

• A function that seems to be read-only according to its name, should behave as such

• If a function changes state then name it accordingly

COMMENTS

NO COMMENTS!• Comments lie:

• You cannot tie them to code

• You cannot refactor them

• You cannot test them

• The truth is in the code

• Do not use a comment when an appropriately named variable or function would do!

for example…

WHEN ARE COMMENTS OK?“The proper use of comments is to compensate for our failure to

express ourselves in code.”

• Legal comments

• Warning of consequences

• TODO comments

• Amplification

• javadocs in public APIs

KEEP YOUR CODE CLEAN

THE BOY SCOUT RULE

Leave the campground cleaner than you found it

Can you imagine working on a project where code simply got better as time passed?

Do you believe that any other option is professional?

OBJECT-ORIENTED DESIGN

Agile Software Development

Principles, Patterns, and Practices

Robert C. Martin, 2003

INTERFACES AND ABSTRACT CLASSES

Ignore implementation detailsProgram to interfaces

JAVA COLLECTIONS API• Iterable

• Collection

• List: ArrayList, LinkedList

• Set: HashSet, LinkedHashSet

• SortedSet: TreeSet

• Map: HashMap, LinkedHashMap

• SortedMap: TreeMap

JAVA.IO• byte based I/O

• InputStream & OutputStream

• FileInputStream, SocketInputStream, ByteArrayInputStream, GZIPInputStream

• character based I/O

• Reader & Writer

• FileWriter, StringWriter, OutputStreamWriter

abstract class example…

DEPENDENCY INJECTION INVERSION OF CONTROL

• The Hollywood Principle: Don’t call us – we’ll call you

• Don’t create your dependencies - they will be given to you

• Cleaner design

• Easier to test

DI example…

DEPENDENCY INJECTION

• Guice – github.com/google/guice

• Dagger - google.github.io/dagger/

• Spring Framework – projects.spring.io/spring-framework/

• Mockito – mockito.org

FAVOR COMPOSITION OVER INHERITANCE

• Inheritance is for “is-a” relationships - when the same interface is most logical

• Composition is for “consists-of”, “contains”, “uses”, “has” relationships - providing decoupling – independence of each other's changes

for example…

IMMUTABILITY

• An immutable object is an object whose state cannot be modified after it is created

• What is the most common immutable object in the Java SDK?

• Why?Caching, thread-safety, map keys

DESIGN PATTERNS

Design Patterns Elements of Reusable

Object-Oriented Software

[Gang of Four Book – GOF]

Erich GammaRichard Helm Ralph Johnson John Vlissides

1994

PATTERNS

• Common solutions to frequent problems arising in object-oriented design

• A systematized catalog of solutions by skilled and experienced developers

• Simplifies communication between developers –“we are using the Strategy pattern”

CREATIONAL PATTERNS

the process of object creation

Factory MethodAbstract Factory

BuilderPrototypeSingleton

STRUCTURAL PATTERNS the composition of classes

DecoratorAdapter (Wrapper)

ProxyFaçade

FlyweightBridge

CompositeNull Object

BEHAVIORAL PATTERNShow classes or objects interact and distribute

responsibility

Template methodObserver (Publish-Subscribe, Listener)

InterpreterMemento

Chain of Responsibility

BEHAVIORAL PATTERNShow classes or objects interact and distribute

responsibility

StateCommandStrategyIteratorVisitor

Mediator

Refactoring to Patterns

Joshua Kerievsky, 2004

Avoid:- over-engineering

- under-engineering

–Antoine de Saint-Exupery

“A designer knows he has achieved perfection not when there is nothing left to add,

but when there is nothing left to take away.”

FINAL WORLDS

The Boy Scout Rule

Experience, experience, experience

Read a lot of others’ code