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
>
