Yes, this is quite a bit advanced thing that you need to learn better beforehand. From Laravel 4 the SOLID design principle has been maintained and in Laravel 5 it becomes more familiar so that you can avoid hard coding and write cleaner codes. Let us see what this SOLID design principle is.
SOLID design principle is the five principles articulated by Robert “Uncle Bob” Martin that consist of five principles. In a nutshell I am going to tell them one by one. In the final part I will discuss it in detail and hopefully by that time you will have been get acquainted with the basic principles of Laravel application logic.
SOLID stands for
1) Single Responsibility Principle
2) Open Closed Principle
3) Liskov Substitution Principle
4) Interface Segregation Principle
5) Dependency Inversion Principle
The Single Responsibility Principle means a class should have one and I mean, ‘only one’ reason to change. Limiting class knowledge is important. The class’ scope should be narrowly focused. A class would do its job and not at all be affected by the change that takes place on its dependencies. Remember if we can build a library of small classes with well defined responsibilities our code will be more decoupled and easy to test and run. Open Closed Principle means a class is always open for extension but closed for modification. How is that? Nothing but it states that change the behavior without modification of source codes. If you can do your job without touching the source code, nothing like that! Remember what Uncle Bob says, “Seperate extensible behavior behind an interface and flip the dependencies.” The thing is anytime you modify your code there is a possibility to break the old functionalities completely adding new bugs.
But if you can plan your application in the beginning based on Open Closed Principle, you could modify your code base as quickly as possible without getting affected. What is Liskov Substitution Principle? Don’t get frightened. This looks intimidating, but as a principle it is extremely helpful and easy to understand. It says: Derived classes must be substitutable for their based class. It means objects should be replaceable with instances of their subtypes without altering the correctness of program. If you can not follow it just moves on, I will explain these principles in detail with examples and screenshot so that the picture will be much clearer.
Interface Segregation Principle is an echo of Singular Responsibilities. If it is broken, Singular Responsibility is broken. In a nutshell it says: interface is granular and focused. No implementation of interface should be forced on methods that it does not use. Accordingly break into small interfaces as you require them for your implementation. Plan it before and enjoy the decoupled easy going ride.
Finally, the Dependency Inversion Principle states that highlevel codes should not depend on lowlevel codes. Instead the highlevel code depends on ‘Abstraction’ that plays a middle man between highlevel and lowlevel. The second aspect is abstraction does not depend upon details but details depend upon abstractions. For the beginners these principles may look not comfortable enough but don’t worry when we will discuss it in detail with examples; by that time you will have gained enough confidence to tackle this conceptual lingo. You have already found the term ‘Interface’ and ‘Abstraction’ more than once, may be many times to be a deserving candidate for having been discussed. So let’s spend some time with those omnipotent terms that often come across in our Laravel application.