Object Oriented Design Principles ~ How to become a SOLID programmer ~ ~ A guide to make a well-designed application with Laravel ~ "Proper Object Oriented Design makes a developer's life easy, whereas bad design makes it a disaster"

1. >< nextprevious
Object Oriented Design Principles
How to become a SOLID programmer
Tran Duc Thang
Framgia Vietnam - Business Strategy Office - Human Development Section
A guide to make a well-designed application with Laravel
1

2. >< nextprevious
“Proper Object Oriented design makes
a developer's life easy, whereas bad
design makes it a disaster.”
2

3. Table of Contents
01
Design Principles first look
‣ What is Design Principle?
‣ Design Principle vs Design Pattern
02
03
04
>< nextprevious
SOLID in depth
‣ What are SOLID?
‣ Decoding SOLID
‣ Other related principles
Building well-design app
‣ A story with MVC
‣ Some ideas when working with Laravel
‣ Symptoms of Bad Design
Summarisation
‣ Annotations, disclaims and notes
3

4. >< nextprevious
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 Object-
Oriented Software” was published in 1994
by the so-called “Gang of Four”
4

5. >< nextprevious
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.
‣ It’s abstract. (Not concrete).
5

6. >< nextprevious
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.
6

7. >< nextprevious
Design Principles
• Some Software Design Principles in examples
‣ DRY (Don’t Repeat Yourself)
‣ KISS (Keep It Simple, Stupid!)
‣ YAGNI (You Aren't Gonna Need It)
7

8. >< nextprevious
Design Principles
• Design Patterns vs Design Principles
‣ Principles: low-level, general guidelines
‣ Patterns: high-level, concrete examples.
Provide reusable solutions to real world
problems.
‣ Good Design Patterns should comply good
Design Principles
8

9. >< nextprevious
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
9

10. >< nextprevious
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.
10

11. >< nextprevious
SOLID in depth
11

12. >< nextprevious
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
12

13. >< nextprevious
SOLID in depth
13

14. >< nextprevious
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.
14

15. >< nextprevious
SOLID in depth
15

16. >< nextprevious
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.
16

17. >< nextprevious
SOLID in depth
17

18. >< nextprevious
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.
18

19. >< nextprevious
SOLID in depth
19

20. >< nextprevious
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
20

21. >< nextprevious
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.
21

22. >< nextprevious
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 Object-
Oriented Software”
22

23. >< nextprevious
SOLID in depth
• SOLID in Action - Checkout examples at Github
https://github.com/wataridori/solid-php-example
23

24. >< nextprevious
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!
24

25. >< nextprevious
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?
25

26. >< nextprevious
“MVC is killing you”
~ Taylor Otwell - Laravel’s creator ~
26

27. >< nextprevious
Think different!
“Think outside of the ‘Model’ Box”
27

28. >< nextprevious
• Some ideas when working with Laravel
‣ Get rid of “Model” with lots of business, try “Entity”
‣ 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
‣ Design Patterns
‣ …
Building well-designed app
28

29. >< nextprevious
• Symptoms of Bad Design
‣ Rigidity
‣ Fragility
‣ Immobility
‣ Viscosity
‣ Needless Complexity
‣ Needless Repetition
‣ Opacity
Building well-designed app
29

30. >< nextprevious
• Funny: Avoid STUPID codes
‣ Singleton Pattern
‣ Tight coupling
‣ Untestability
‣ Premature Optimization
‣ Indescriptive Naming
‣ Duplication
Building well-designed app
30

31. >< nextprevious
Summarisation
• SOLID principles, as well as other design
principles and design patterns help you to build
large applications which are easy-to-be-
extended, easy-to-be-maintained, easy-to-be-
tested.
31

32. >< nextprevious
Summarisation
• SOLID principles, as well as other design
principles and design patterns help you to build
LARGE applications which are easy-to-be-
extended, easy-to-be-maintained, easy-to-be-
tested.
• Principles are just a set of GUIDELINES. They
are not LAWS!
• Don’t take the above argument as a reason to
be lazy!
32

33. >< nextprevious
Summarisation
Extract Responsibilities
&&
Programming to the Interface
33

34. >< nextprevious
References
‣ https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
‣ http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
‣ http://www.oodesign.com/
‣ https://lostechies.com/derickbailey/2009/02/11/solid-
development-principles-in-motivational-pictures/
‣ https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-
SOLID.html
‣ http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/
‣ http://www.codeproject.com/Articles/567768/Object-Oriented-
Design-Principles
‣ “Design Principles and Design Patterns” - Robert C. Martin
‣ “From Apprentice To Artisan” - Taylor Otwell
34

35. >< nextprevious
Thank you for listening!
Q&A
For any discussion, you can refer this post on Viblo
https://viblo.asia/thangtd90/posts/pVYRPJPmG4ng
35