The document serves as a guide to well-designed application development using Laravel and emphasizes the importance of object-oriented design principles, specifically the SOLID principles. It outlines various design principles, compares design patterns, and offers practical advice for building maintainable and testable applications. Key concepts include the separation of concerns, interfaces, and recognizing symptoms of bad design to avoid common pitfalls in software development.

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