Object Oriented Design Principles

How to become a SOLID programmer

A guide to make a well-designed application with Laravel

Tran Duc Thang

Framgia Vietnam - Business Strategy Office - Human Development Section

<

previous

next
1

>

Proper Object Oriented design makes

a developer's life easy, whereas bad
design makes it a disaster.

<

previous

next
2

>

Table of Contents

<

01

Design Principles first look

02

SOLID in depth

What is Design Principle?

Design Principle vs Design Pattern

What are SOLID?

Decoding SOLID
Other related principles

previous

03

Building well-design app

04

Summarisation

A story with MVC

Some ideas when working with Laravel
Symptoms of Bad Design

Annotations, disclaims and notes

next
3

>

Design Principles

<

Object Oriented Design Patterns

A general repeatable solution to a commonly

occurring problem in software design.

A description or template for how to solve a

problem that can be used in many different
situations.

Gained popularity after the book Design

Patterns: Elements of Reusable ObjectOriented Software was published in 1994
by the so-called Gang of Four

previous

next
4

>

Design Principles

<

Object Oriented Design Principles

Associated to Robert Cecil Martin who

gathered them in Agile Software
Development: Principles, Patterns, and
Practices

Represent a set of guidelines that ensures

OOP concepts, then helps us to avoid having
a bad design.

Its abstract. (Not concrete).

previous

next
5

>

Design Principles

<

Robert Cecil Martin

Agile software development:

principles, patterns, and
practices.

Clean code: a handbook of

agile software craftsmanship.

The clean coder: a code of

conduct for professional
programmers.

previous

next
6

>

Design Principles

<

Some Software Design Principles in examples

DRY (Dont Repeat Yourself)

KISS (Keep It Simple, Stupid!)
YAGNI (You Aren't Gonna Need It)

previous

next
7

>

Design Principles

<

Design Patterns vs Design Principles

Principles: low-level, general guidelines

Good Design Patterns should comply good

Design Principles

Patterns: high-level, concrete examples.

Provide reusable solutions to real world
problems.

previous

next
8

>

SOLID in depth

<

What are SOLID?

A mnemonic acronym introduced by Michael

Feathers for the first five principles
named by Robert Cecil Martin.

Single responsibility principle

Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

previous

next
9

>

SOLID in depth

<

Single responsibility principle (SRP)

A class should have only a single

responsibility. In other words, a class should
have one, and only one, reason to change.

previous

next
10

>

SOLID in depth

<

previous

next
11

>

SOLID in depth

<

Open/closed principle (OCP)

Software entities (classes, modules,

functions, etc.) should be open for
extension, but closed for modification

An entity can allow its behaviour to be

extended without modifying its source code

previous

next
12

>

SOLID in depth

<

previous

next
13

>

SOLID in depth

<

Liskov substitution principle (LSP)

If S is a subtype of T, then objects of type T

may be replaced with objects of type S
without altering any of the desirable
properties of that program.

previous

next
14

>

SOLID in depth

<

previous

next
15

>

SOLID in depth

<

Interface segregation principle (ISP)

No client should be forced to depend on

methods it does not use.

Many client-specific interfaces are better than

one general-purpose interface.

previous

next
16

>

SOLID in depth

<

previous

next
17

>

SOLID in depth

<

Dependency inversion principle (ISP)

High-level modules should not depend on

low-level modules. Both should depend on
abstractions.

Abstractions should not depend on details.

Details should depend on abstractions.

previous

next
18

>

SOLID in depth

<

previous

next
19

>

SOLID in depth
Some other concepts related to SOLID

<

Separation of Concerns (SoC)

The process of breaking a computer program

into distinct features that overlap in
functionality as little as possible

previous

next
20

>

SOLID in depth

<

Law of Demeter (LoD) aka Principle of Least

Knowledge

Each unit should have only limited knowledge

about other units: only units "closely" related
to the current unit.

Each unit should only talk to its friends; don't

talk to strangers.

Only talk to your immediate friends.

previous

next
21

>

SOLID in depth

<

Program to an interface, not an implementation

One of good object-oriented design

techniques that GoF mentioned in Design
Patterns: Elements of Reusable ObjectOriented Software

previous

next
22

>

SOLID in depth

SOLID in Action - Checkout examples at Github

https://github.com/wataridori/solid-php-example

<

previous

next
23

>

SOLID in depth

All SOLID principles work perfectly together.

Breaking one principle may also make some (or even
all) of the remaining principles become broken too!

<

previous

next
24

>

Building well-designed app

<

The MVC Story: Model vs Controller

Where to put your business logic?

Fat Controllers - Skinny Models?
Fat Models - Skinny Controllers?
Fat Models - Fat Controllers?

previous

next
25

>

MVC is killing you

~ Taylor Otwell - Laravels creator ~

<

previous

next
26

>

Think dierent!
Think outside of the Model Box

<

previous

next
27

>

Building well-designed app

<

Some ideas when working with Laravel

Get rid of Model with lots of business, try Entity

Design Patterns

Repository design pattern for Data Access Layer

Form Request Validation
Job
Event
View Presenter, or any kind of wrappers that helps you get rid of
God Object

previous

next
28

>

Building well-designed app

<

Symptoms of Bad Design

Rigidity
Fragility
Immobility
Viscosity
Needless Complexity
Needless Repetition
Opacity

previous

next
29

>

Building well-designed app

<

Funny: Avoid STUPID codes

Singleton Pattern
Tight coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication

previous

next
30

>

Summarisation

<

SOLID principles, as well as other design

principles and design patterns help you to build
large applications which are easy-to-beextended, easy-to-be-maintained, easy-to-betested.

previous

next
31

>

Summarisation

<

SOLID principles, as well as other design

principles and design patterns help you to build
LARGE applications which are easy-to-beextended, easy-to-be-maintained, easy-to-betested.

Principles are just a set of GUIDELINES. They

are not LAWS!

Dont take the above argument as a reason to

be lazy!

previous

next
32

>

Summarisation
Extract Responsibilities
&&
Programming to the Interface

<

previous

next
33

>

<

References

https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASPSOLID.html

http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/

Design Principles and Design Patterns - Robert C. Martin

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
http://www.oodesign.com/
https://lostechies.com/derickbailey/2009/02/11/soliddevelopment-principles-in-motivational-pictures/

http://www.codeproject.com/Articles/567768/Object-OrientedDesign-Principles

From Apprentice To Artisan - Taylor Otwell

previous

next
34

>

Thank you for listening!

Q&A
For any discussion, you can refer this post on Viblo
https://viblo.asia/thangtd90/posts/pVYRPJPmG4ng

<

previous

next
35

>