Keep Things Simple!

Every time we modify source code, we make design decisions.

Even if we don't think about design decisions in this very moment.

Even when we don't modify some piece of code, that's sometimes a design decision.

Things
will change.

Requirements
will change.

Teams
will change.

The business
will change.

We
will change.

Can we anticipate the future?

How?

Keep Things Simple!

David

David Tanzer business@davidtanzer.net

Oliver

Oliver Szymanski oliver.szymanski@source-knights.com

Today

The Four Rules
of Simple Design

-- Kent Beck

Design that is simple...

 

Design that is simple...

passes its tests

  • Design must serve its purpose
  • Some way to verify the design
  • Not necessarily automated

Design that is simple...

maximizes clarity

  • Names are easy to understand
  • Names express intent
  • Less relationships
  • Only absolutely necessary abstractions
  • Low coupling / high cohesion

Design that is simple...

minimizes duplication

  • Think: Conceptual duplication
  • Not only code duplication!
  • The right abstractions
  • "Attractive" code
  • High cohesion

Design that is simple...

has fewer elements

  • Only absolutely necessary functionality
  • Only absolutely necessary code
  • Only absolutely necessary design elements
  • Only absolutely necessary abstractions

Coupling / Cohesion

cou·ple (verb)

to join (something) to something else

In Software

In software engineering, coupling or dependency is the degree to which each program module relies on each one of the other modules.
Diagram: Low Coupling
Diagram: High Coupling

Which is the better design?

co·here

to hold together firmly as parts of the same mass

broadly : stick, adhere

In Software

In computer programming, cohesion refers to the degree to which the elements of a module belong together. Thus, it is a measure of how strongly related each piece of functionality expressed by the source code of a software module is.
Diagram: Low Cohesion
Diagram: High Cohesion

Which is the better design?

Coupling / Cohestion and The Four Rules

Coupling / Cohestion and The Four Rules

The SOLID principles

SOLID

Single Responsibility Principle

There should never be more than one reason for a class to change.

Diagram: SRP
Diagram: SRP
Diagram: SRP

Single Responsibility Principle

Open/Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Diagram: OCP
Diagram: OCP

Open/Closed Principle

Liskov Substitution Principle

Functions that use objects of a base class must be able to use objects of derived classes without knowing it. (Paraphrased)

Liskov Substitution Principle

Interface Segregation Principle

Clients should not be forced to depend upon interfaces they do not use.

Diagram: ISP

Interface Segregation Principle

Dependency Inversion Principle

High level modules should not depend upon low level modules. Both should depend upon abstractions.

Abstractions should not depend upon details. Details should depend upon abstractions.

Diagram: DIP
Diagram: DIP
Diagram: DIP

Dependency Inversion Principle

Testing / Test Driven Development

Design that is simple...

passes its tests

Testing

Diagram: TDD
Outlook
To Recap...

Keep Things
Small

Keep Things
Clear

Keep Things
Distinct

Keep Things
Extensible

Keep Things
Simple

Never implement anything you don't need
Right Now!

Don't try to anticipate the future