L5 SOLID - Five agile principles that should guide you every time you write code
Part:1. Laravel 5 NEW things - quick review
Part: 2. SOLID
- - -
S - Single Responsibility (SRP)
O - Open/Close
L - Liskov's Substitution
I - Interface Segregation
D - Dependency Inversion
3. L 5 : N E W T H I N G S - Q U I C K R E V I E W
STRUCTURE Default namespace: App
app/models=> null
app/start => null
NEW => app/Providers
Controllers => app/Http
Middleware => app/Http
Requests => app/Http
Route filters=> middleware
language files => resources
directory
views => resources directory
4. L 5 : N E W T H I N G S - Q U I C K R E V I E W
Contracts:
illuminate/contracts
Controller Method
Injection
Event Objects
Commands / Queueing
Route Middleware (Filters)
Form Requests /
Controller Request
Validation
Route Cache
Database Queue
Laravel Scheduler
Elixir
Socialite
Filesystem abstraction:
Flysystem
DotEnv
Authentication Scaffolding
Configuration Cache
New Generators
Tinker
Symfony VarDumper
5. L 5 : N E W T H I N G S - Q U I C K R E V I E W
NOMORE…
6. S O L I D
SINGLE RESPONSIBILITY PRINCIPLE
OPEN/CLOSED PRINCIPLE
LISKOV SUBSTITUTION PRINCIPLE
INTERFACE SEGREGATION PRINCIPLE
DEPENDENCY INVERSION PRINCIPLE
17. S O L I D
SINGLE RESPONSIBILITY PRINCIPLE
OPEN/CLOSED PRINCIPLE
LISKOV SUBSTITUTION PRINCIPLE
INTERFACE SEGREGATION PRINCIPLE
DEPENDENCY INVERSION PRINCIPLE
18. Software entities (classes, modules, functions,
etc.) should be open for extension,
but closed for modification.
OPEN/CLOSED PRINCIPLE
20. S O L I D
SINGLE RESPONSIBILITY PRINCIPLE
OPEN/CLOSED PRINCIPLE
LISKOV SUBSTITUTION PRINCIPLE
INTERFACE SEGREGATION PRINCIPLE
DEPENDENCY INVERSION PRINCIPLE
21. Let q(x) be a property provable about objects
x of type T.
Then q(y) should be provable for objects y of
type S
where S is a subtype of T.
LISKOV SUBSTITUTION PRINCIPLE
25. S O L I D
SINGLE RESPONSIBILITY PRINCIPLE
OPEN/CLOSED PRINCIPLE
LISKOV SUBSTITUTION PRINCIPLE
INTERFACE SEGREGATION PRINCIPLE
DEPENDENCY INVERSION PRINCIPLE
26. A client should never be forced to
implement an interface that it
doesn’t use
INTERFACE SEGREGATION PRINCIPLE
30. S O L I D
SINGLE RESPONSIBILITY PRINCIPLE
OPEN/CLOSED PRINCIPLE
LISKOV SUBSTITUTION PRINCIPLE
INTERFACE SEGREGATION PRINCIPLE
DEPENDENCY INVERSION PRINCIPLE
31. A. High-level modules should not depend
on low-level modules. Both should depend
on abstractions.
B. Abstractions should not depend upon
details. Details should depend upon
DEPENDENCYINVERSIONPRINCIPLE
Dependency inversion
principle
34. S O L I D
SINGLE RESPONSIBILITY PRINCIPLE
OPEN/CLOSED PRINCIPLE
LISKOV SUBSTITUTION PRINCIPLE
INTERFACE SEGREGATION PRINCIPLE
DEPENDENCY INVERSION PRINCIPLE
The Audience
Persistence Module - Audience include DBAs and software architects.
Reporting Module - Audience include clerks, accountants, and operations.
Payment Computation Module for a Payroll System - Audience may include lawyers, managers, and accountants.
Roles and Actors
So a responsibility is a family of functions that serves one particular actor. (Robert C. Martin)
Source of Change
An actor for a responsibility is the single source of change for that responsibility. (Robert C. Martin
Objects That Can "Print" Themselves
Objects That Can "Save" Themselves
do you have seen code like this?
what is wrong here?
is this a SOLID?
hmmm… do we need Auth::check() in this controller?
What if this was API?
Or what if we run this from command line
A database call ?
Ask your self, do I need to this here?
who will ask this to change? A business, designer or DBAdmin
What if boss decide to switch database from MySQL to MongoDB ?
hm…. HTML…
A spaghetti code ?
Who will ask to change this? Designer…are you the designer ?
What if we have multiple implementation…. For example: Web/HTML, Console… or Mobile…iOS..
hm…. Is this more clean….
What we have here… Repository
PHP 5 introduces type hinting. Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype), interfaces, arrays (since PHP 5.1) or callable (since PHP 5.4).
Interface…yes, but for this example we don’t expect database changes.
Repository will connect Factories with Gateways (persistence).
Decoupled architecture
Pros:
Separation of concerns; the application need not know about or track any or all data sources.
Allows easy unit testing as the repositories are bound to interfaces which are injected into classes at run time.
DRY (Dont Repeat Yourself) design, the code to query and fetch data from data source(s) is not repeated.
Cons:
Adds another layer of abstraction which adds a certain level of complexity making it an overkill for small applications.
- HTML implementation of the Interface
TEXT implementation of the Interface
And this hit the Open/Close principies
The Open/Closed Principle, OCP in short, is credited to Bertrand Mayer, a French programmer, who first published it in his book n Object-Oriented Software Constructionin 1988.
The principle rose in popularity in the early 2000s when it became one of the SOLID principles defined by Robert C. Martin in his book Agile Software Development,
Advantage of the Dynamic Nature of PHP
*Strategy Design Pattern
Template Method Design Pattern
What do I need to do for PDF print?
What is wrong here?
Response…. Return type …. Collection vs Array … Exception hm…
What is wrong here?
Signature must match
Preconditions CAN’T be greater
Post conditions at least equal to
Exception types must match
ISP teaches us to respect our clients more than we thought necessary.
Respecting their needs will make our code better and our lives as programmers easier.
Depend on abstractions, not on concretions.
All of this is about decoupling code.