>< nextprevious

Object Oriented Design PrinciplesHow 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

>< nextprevious

“Proper Object Oriented design makes a developer's life easy, whereas bad

design makes it a disaster.”

2

Table of Contents

01 Design Principles first look‣ What is Design Principle? ‣ Design Principle vs Design Pattern

020304

>< 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

>< 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

>< 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

>< 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

>< 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

>< 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

>< 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 principle9

>< 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

>< nextprevious

SOLID in depth

11

>< 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

>< nextprevious

SOLID in depth

13

>< 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

>< nextprevious

SOLID in depth

15

>< 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

>< nextprevious

SOLID in depth

17

>< 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

>< nextprevious

SOLID in depth

19

>< 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

>< 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

>< 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

>< nextprevious

SOLID in depth

• SOLID in Action - Checkout examples at Github https://github.com/wataridori/solid-php-example

23

>< 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

>< 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

>< nextprevious

“MVC is killing you” ~ Taylor Otwell - Laravel’s creator ~

26

>< nextprevious

Think different! “Think outside of the ‘Model’ Box”

27

>< 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

>< nextprevious

• Symptoms of Bad Design

‣ Rigidity

‣ Fragility

‣ Immobility

‣ Viscosity

‣ Needless Complexity

‣ Needless Repetition

‣ Opacity

Building well-designed app

29

>< nextprevious

• Funny: Avoid STUPID codes

‣ Singleton Pattern

‣ Tight coupling

‣ Untestability

‣ Premature Optimization

‣ Indescriptive Naming

‣ Duplication

Building well-designed app

30

>< 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

>< 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

>< nextprevious

Summarisation

Extract Responsibilities &&

Programming to the Interface

33

>< 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

>< nextprevious

Thank you for listening!

Q&A

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

35