Successfully reported this slideshow.
Your SlideShare is downloading. ×

Laravel 5 and SOLID

Ad

Five agile principles that should
guide you every time you write code
by Talevski Igor

Ad

Talevski
Igor

Ad

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

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Loading in …3
×

Check these out next

1 of 37 Ad
1 of 37 Ad

Laravel 5 and SOLID

Download to read offline

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

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

Advertisement
Advertisement

More Related Content

Slideshows for you (19)

Advertisement
Advertisement

Laravel 5 and SOLID

  1. 1. Five agile principles that should guide you every time you write code by Talevski Igor
  2. 2. Talevski Igor
  3. 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. 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. 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. 6. S O L I D SINGLE RESPONSIBILITY PRINCIPLE OPEN/CLOSED PRINCIPLE LISKOV SUBSTITUTION PRINCIPLE INTERFACE SEGREGATION PRINCIPLE DEPENDENCY INVERSION PRINCIPLE
  7. 7. SINGLE RESPONSIBILITY PRINCIPLE A class should have only one reason to change.
  8. 8. SINGLERESPONSIBILITYPRINCIPLE
  9. 9. SINGLERESPONSIBILITYPRINCIPLE
  10. 10. SINGLERESPONSIBILITYPRINCIPLE
  11. 11. SINGLERESPONSIBILITYPRINCIPLE
  12. 12. SINGLERESPONSIBILITYPRINCIPLE
  13. 13. SINGLERESPONSIBILITYPRINCIPLE
  14. 14. SINGLERESPONSIBILITYPRINCIPLE
  15. 15. SINGLERESPONSIBILITYPRINCIPLE
  16. 16. SINGLERESPONSIBILITYPRINCIPLE
  17. 17. S O L I D SINGLE RESPONSIBILITY PRINCIPLE OPEN/CLOSED PRINCIPLE LISKOV SUBSTITUTION PRINCIPLE INTERFACE SEGREGATION PRINCIPLE DEPENDENCY INVERSION PRINCIPLE
  18. 18. Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. OPEN/CLOSED PRINCIPLE
  19. 19. Separate extensible behavior behind an interface, and flip the dependencies OPEN/CLOSEDPRINCIPLE
  20. 20. S O L I D SINGLE RESPONSIBILITY PRINCIPLE OPEN/CLOSED PRINCIPLE LISKOV SUBSTITUTION PRINCIPLE INTERFACE SEGREGATION PRINCIPLE DEPENDENCY INVERSION PRINCIPLE
  21. 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
  22. 22. LISKOVSUBSTITUTIONPRINCIPLE
  23. 23. LISKOVSUBSTITUTIONPRINCIPLE
  24. 24. LISKOVSUBSTITUTIONPRINCIPLE
  25. 25. S O L I D SINGLE RESPONSIBILITY PRINCIPLE OPEN/CLOSED PRINCIPLE LISKOV SUBSTITUTION PRINCIPLE INTERFACE SEGREGATION PRINCIPLE DEPENDENCY INVERSION PRINCIPLE
  26. 26. A client should never be forced to implement an interface that it doesn’t use INTERFACE SEGREGATION PRINCIPLE
  27. 27. INTERFACESEGREGATIONPRINCIPLE
  28. 28. INTERFACESEGREGATIONPRINCIPLE
  29. 29. INTERFACESEGREGATIONPRINCIPLE
  30. 30. S O L I D SINGLE RESPONSIBILITY PRINCIPLE OPEN/CLOSED PRINCIPLE LISKOV SUBSTITUTION PRINCIPLE INTERFACE SEGREGATION PRINCIPLE DEPENDENCY INVERSION PRINCIPLE
  31. 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
  32. 32. DEPENDENCYINVERSIONPRINCIPLE
  33. 33. DEPENDENCYINVERSIONPRINCIPLE
  34. 34. S O L I D SINGLE RESPONSIBILITY PRINCIPLE OPEN/CLOSED PRINCIPLE LISKOV SUBSTITUTION PRINCIPLE INTERFACE SEGREGATION PRINCIPLE DEPENDENCY INVERSION PRINCIPLE
  35. 35.

Editor's Notes

  •  app:name Artisan command
  •  Tinker => Read-Eval-Print Loop
  •  app:name Artisan command
  • 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.

×