Download - Object Oriented Design Principles
>< 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