Laravel 5 and SOLID
Download as PPTX, PDF35 likes10,168 views
The document outlines five key agile principles for coding: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, collectively known as SOLID principles. Each principle emphasizes best practices for software design, ensuring that code is maintainable, extensible, and robust. The emphasis is on allowing classes and modules to manage changes efficiently while promoting high-level abstractions.
Laravel 5 and SOLID
- 1. Five agile principles that should guide you every time you write code by Talevski Igor
- 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
- 7. SINGLE RESPONSIBILITY PRINCIPLE A class should have only one reason to change.
- 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
- 19. Separate extensible behavior behind an interface, and flip the dependencies OPEN/CLOSEDPRINCIPLE
- 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
- 36. …
Editor's Notes
- #4: app:name Artisan command
- #5: Tinker => Read-Eval-Print Loop
- #6: app:name Artisan command
- #8: 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
- #9: 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?
- #10: hmmm… do we need Auth::check() in this controller? What if this was API? Or what if we run this from command line
- #11: 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 ?
- #12: 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..
- #14: 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).
- #15: 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.
- #16: - HTML implementation of the Interface
- #17: TEXT implementation of the Interface And this hit the Open/Close principies
- #19: 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,
- #20: Advantage of the Dynamic Nature of PHP *Strategy Design Pattern Template Method Design Pattern What do I need to do for PDF print?
- #24: What is wrong here? Response…. Return type …. Collection vs Array … Exception hm…
- #25: What is wrong here? Signature must match Preconditions CAN’T be greater Post conditions at least equal to Exception types must match
- #30: 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.
- #33: Depend on abstractions, not on concretions. All of this is about decoupling code.