What is SOLID?
SOLID principles is a set of five foundational principles in object-oriented programming that help developers create more maintainable, scalable, and easily understood software systems. These principles were introduced by Robert C. Martin (aka ‘Uncle Bob’) to guide developers toward writing software that is easier to maintain and adaptable to changes and new requirements over time.
Writing clean and efficient code is crucial in software development. By adhering to SOLID principles, developers can reduce the risk of bugs, improve collaboration, and ensure their software can grow with the business’s needs. In my role as a senior developer, SOLID is an important tool to have as a set of principles to refer developers to, who are earlier in their career.
The SOLID principles are beneficial when working with PHP, a language that should be used in an object-oriented manner. It is utilised by a vast number of websites and web applications across the internet, including being the language base of the WordPress CMS and the Laravel Framework; two of the technologies of choice for Contactpoint client projects.
Both WordPress and Laravel are implemented in an object-oriented manner, making SOLID highly applicable in these environments. WordPress Plugins should be developed in such a way as to complement the WordPress core, and also allow for customisation of plugins via extending classes, so that the inevitable plugin updates (important for performance and security) do not alter customisations. Unfortunately some developers of the millions of WordPress plugins do not follow OO principles well, and so informed plugin selection (assuming there are options for a particular feature) is vital.
SOLID principles are summarised in the diagram below. They provide a clear path for structuring code, promoting flexibility and reducing complexity, whether building a small web application or a large-scale enterprise system, applying these principles will result in a more robust and future-proof design.
Why SOLID Principles?
Below is a more detailed description of the benefits of SOLID principles.
1. Improved Code Maintainability
One of the primary benefits of SOLID principles is that they promote better code organisation, making it easier to maintain and update. By following these principles, developers can modify system parts without affecting unrelated components, reducing the risk of unintended side effects.
2. Enhanced Code Reusability
Adhering to SOLID principles encourages modular design, enabling developers to re-use code across different parts of an application or even in other projects. This reduces redundant code, leading to a more efficient development process.
3. Better Scalability
As applications become complex, adhering to SOLID principles ensures that new features can be added with minimal impact on existing code. This makes scaling applications more manageable and more efficient, as modifications can be made with confidence.
4. Easier Debugging and Testing
SOLID principles help create a clear separation of concerns, allowing developers to isolate and test individual components. This results in more manageable unit tests, simplifying debugging and improving software quality.
5. Improved Readability and Collaboration
Following SOLID principles leads to well-structured code that is easier to read and understand. This is particularly beneficial in team environments where multiple developers work on the same project. Clear, modular code improves collaboration and reduces onboarding time for new developers.
6. Reduced Code Coupling and Increased Flexibility
When followed well, SOLID principles help reduce dependencies between components, making the system more flexible. This means that changes in one module are less likely to break other application parts, enhancing long-term stability.
7. Encourages Best Practices
Applying SOLID principles naturally enforces good design patterns, such as dependency inversion and single responsibility, which are crucial for writing high-quality software. It also aligns well with other modern software development methodologies, such as Agile and Test-Driven Development (TDD).
Breaking Down the SOLID Principles: A Detailed Guide
The following detailed explanations of SOLID principles assume some knowledge of terms related to object oriented programming, however, even without this knowledge the definition and explanation will still make sense with regard to their benefits.
1. S: Single Responsibility Principle (SRP)
Definition:
A class should have only one reason to change, meaning it should have only one responsibility.
Explanation:
Each class should do one thing well. Having a single responsibility makes the class easier to understand, test, and maintain.
If you start identifying multiple consumers or multiple reasons to change the class, well, chances are you need to extract some of that logic into a dedicated class.
Example:
A class handling user authentication should not also be responsible for logging errors.
A class Generate sale report should not be responsible for authentication, printing output, or fetching reports from a database.
SalesReporter.php
<?php namespace Acme\Reporting;
use Auth, DB, Exception;
class SalesReporter {
public function between($startDate, $endDate)
{
// perform authentication
if (!Auth::check()) throw new Exception ('Authentication required for reporting.');
//Get sales from db
$sales = $this->queryDBForSaLesBetween($startDate, $endDate);
// return results
return $this->format($sales);
}
protected function queryDBForSaLesBetween($startDate, $endDate){
return DB::table('sales')
->whereBetween ('created _at', [$startDate, $endDate])
->sum( 'charge') / 100;
}
protected function format($sales){
return "<h1>Sales: $sales</h1>";
}
}
routes.php
<?php
Route::get('/', function()
{
$report = new Acme\Reporting\SalesReporter ();
$begin = Carbon\Carbon::now()->subDays(10);
$end = Carbon\Carbon::now();
return report-›between ($begin, send);
});
- User authentication must not be performed in this class because it is not its responsibility. Since we can receive different requests from different sources, we must transfer it to the controller.
- The output must not be performed in this class because if we need to change the output in the future, we need to change this class, or if we need to have the output in JSON instead of HTML, we need to change this class.
- The fetching of the data from the database must not be in this class because this class must not know about the under-layer, and if we need to change the database fetching in future, we need to change this class.
SalesReporter.php
<?php namespace Acme\Reporting;
use Acme\Repositories\SalesRepository;
use Auth, DB, Exception;
class SalesReporter {
private $repo;
public function __construct(SalesRepository $repo)
{
$this->repo = $repo;
}
public function between($startDate, $endDate, SalesOutputInterface $formatter)
{
$sales = $this->repo->between($startDate, $endDate);
// return results
$formatter->output($sales);
}
}
SalesRepository.php
<?php namespace Acme\Repositories;
use DB;
class SalesRepository {
public function between($startDate, $endDate)
{
return DB:: table('sales')
->whereBetween ('created_at', [$startDate, $endDate])
->sum( 'charge') / 100;
}
}
SalesOutputInterface.php
<?php namespace Acme\Reporting;
interface SalesOutputInterface {
public function output($sales);
}
HtmlOutput.php
<?php namespace Acme\Reporting;
use Acme\Reporting\SaLesOutputInterface;
class HtmLOutput implements SalesOutputInterface {
public function output($sales)
{
return "<h1>Sales: $sales</h1>");
｝
}
routes.php
<?php
Route::get('/', function()
$report = new Acme\Reporting\SalesReporter(new \Acme\Repositories\SalesRepository);
$begin = Carbon\Carbon::now()->subDays(10);
$end = Carbon\Carbon::now();
return $report->between($begin, $end, new Acme\Reporting\HtmLOutput);
});
2. O: Open/Closed Principle (OCP)
Definition:
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
Explanation:
You should be able to add new functionality without altering existing code. This is often achieved through abstraction and polymorphism.
This is the goal, however it is very hard to follow it 100%.
Changing the behaviour without modifying source code. Avoid code rot.
Example:
Instead of modifying a class to add a new feature, create a new class that extends the existing one.
<?php namespace Acme;
class Square {
public $width;
public $height;
function _construct($height, $width)
{
$this->height = $height;
$this->width = $width;
}
}
<?php namespace Acme;
class Circle {
public $radius;
function _construct Radius)
{
$this->radius = Sradius;
}
}
<?php namespace Acme;
class AreaCaLculator {
public function calculate($shapes)
{
foreach($shapes as $shape)
{
if (is_a($shape, 'Square'))
{
$area[] = $shape->width * $shape->height;
}
else
{
$area[] = $shape->radius * $shape->radius * pi();
}
}
return array_sum($area);
}
}
If in the future we need to calculate the area of triangle shape this implementation breaks the open/closed Principle again because we need to change the source code of the AreaCalculator class to calculate the area of triangle.
So we fall into the code rot every time we need to calculate the area of another shape and therefore need to modify our code.
The solution for this is what uncle Bob says:
When you have module you want to extend without modification what we do is: separate extensible behavior behind an interface, and flip the dependencies.
Separate extensible behavior behind an interface:
<?php namespace Acme;
interface Shape {
public function area();
}
<?php namespace Acme;
class Square implements Shape {
public $width;
public $height;
function _construct($height, $width)
{
$this->height = $height;
$this->width = $width;
}
public function area(){
return $this-›height * $this->width;
}
}
<?php namespace Acme;
class Circle implements Shape {
public $radius;
function _construct Radius)
{
$this->radius = Sradius;
}
public function area(){
return $this->radius * $this->radius * pi();
}
}
Flip the dependencies:
<?php namespace Acme;
class AreaCaLculator {
public function calculate($shapes)
{
foreach($shapes as $shape)
{
$area[] = $shape->area();
}
return array_sum($area);
}
}
So in this implementation we would never need to update the AreaCalculator class to add another shape such as a triangle.
3. L: Liskov Substitution Principle (LSP)
Definition:
Subtypes must be substitutable for their base types without altering the correctness of the program.
Explanation:
Derived classes must be substitutable for their base classes.
If a class is a subclass of another, it should be usable wherever the parent class is expected. Violations often occur when subclasses override methods in incompatible ways.
Coined by Barbara Liskov, this principle states that any implementation of an abstraction (interface) should be substitutable in any place that the abstraction is accepted.
This principle requires that you adhere to the following:
- Signature must match
- Preconditions can’t be greater
- Post conditions at least equal to
- Exception types must match
Example:
If a Bird class has a method fly, a subclass Penguin should not override fly in a way that breaks the code expecting all birds to fly.
<?php
class VideoPLayer {
public function play($file)
// play the video
}
}
class AviVideoPLayer extends VideoPLayer {
public function play($file)
{
if (pathinfo($file, PATHINFO_EXTENSION) |== 'avi')
{
throw new Exception; // violates the LSP
}
}
}
In this example we can’t use AviVideoPLayer child class in every place where we use its parent VideoPLayer class because if format of file is not equal to avi the child class will throw an exception.
<?php
interface LessonRepositoryInterface {
public function getALL();
}
class FiLeLessonRepository implements LessonRepositoryInterface {
public function getALL()
{
// return through filesystem
return [];
}
}
class DbLessonRepository implements LessonRepositoryInterface {
public function getALL()
{
return Lesson::all(); // violates the LSP
}
}
function foo(LessonRepositoryInterface $lesson)
$lessons = $lesson->getALL();
if(is_a()) // violates the OCP
}
In the above example we can’t use the DbLessonRepository child class in every place where we would use FileLessonRepository class because both of the child implement interface LessonRepositoryInterface because one of them returns an array and one returns a collection object, thus breaking the LSP rule. If we want to change the code to comply with the LSP rule, we would then break the OCP rule.
Note: When we need to handle variable types in our code, checking the type explicitly (e.g., using if statements to apply different logic for each type) can break the SOLID principles. Instead, we should design our code to avoid type-checking by leveraging polymorphism, interfaces, or dependency injection, ensuring that each class or component adheres to its specific responsibility.
<?php
interface LessonRepositoryInterface {
/**
* Fetch all records
*
* @return array
*/
public function getALL();
}
class FiLeLessonRepository implements LessonRepositoryInterface {
public function getALL()
{
// return through filesystem
return [];
}
}
class DbLessonRepository implements LessonRepositoryInterface {
public function getALL()
{
return Lesson::all()->toArray(); // violates the LSP
}
}
4. I: Interface Segregation Principle (ISP)
Definition:
A class should not be forced to implement interfaces it does not use.
Explanation:
Instead of creating one large interface, divide it into smaller, more specific interfaces. This ensures that classes only need to implement the methods they need.
Example:
A printer interface might be split into print and scan interfaces so that a basic printer isn’t forced to implement scanning functionality.
<?php
interface ManageableInterface {
public function beManaged();
}
interface WorkableInterface {
public function work();
}
interface SleepabLeInterface {
public function sleep();
}
class Humanworker implements WorkableInterface, SleepabLeInterfaceeInterface, ManageableInterface (
{
public function work()
{
return 'human working';
}
public function sleep()
{
return 'human sleeping';
}
public function beManaged()
{
$this->work();
$this->sleep();
}
}
class Androidworker implements WorkableInterface, ManageableInterface {
public function work()
{
return 'android working';
}
public function beManaged()
{
$this->work();
}
}
class Captain {
public function manage (ManagableInterface $worker)
$worker->beManaged();
}
}
5. D: Dependency Inversion Principle (DIP)
Definition:
Depends on abstractions, not on concrete implementations.
Explanation:
There’s a common misunderstanding that “dependency inversion” is simply another way to say “dependency injection.” However, the two are not the same.
High-level modules should not depend on low-level modules; both should depend on abstractions. This reduces the impact of changes in the implementation.
High level code isn’t as concerned with details.
Low level code is more concerned with details and specifics.
Example:
A PaymentProcessor class should depend on an interface like PaymentGateway, not on specific implementations like StripePaymentGateway.
<?php
class PasswordReminder {
/**
* @var MySQLConnection
*/
private $dbConnection;
public function _construct(MySQLConnection $dbConnection)
{
$this-›dbConnection = $dbConnection;
}
}
Why should the PasswordReminder class be concerned with the type of database connection being used?
The high level module PasswordReminder must not depend on the low level module MySQLConnection.
The high level module must depends on abstractions, not on concrete implementations. Both should depend on abstractions.
<?php
interface ConnectionInterface {
public function connect();
}
class DbConnection implements ConnectionInterface {
public function connect()
{
// TODO: Implement connect method.
}
}
class PasswordReminder {
private $dbConnection;
public function _construct(ConnectionInterface $dbConnection)
{
$this-›dbConnection = $dbConnection;
}
}
Why should the PasswordReminder class be concerned with the type of database connection being used?
The high level module PasswordReminder must not depend on the low level module MySQLConnection.
The high level module must depends on abstractions, not on concrete implementations. both should depend on abstractions.
Tips & Tricks for Applying SOLID Principles in PHP
It’s clear from the definitions and explanations above that it isn’t always easy to follow SOLID principles in every situation. When helping our team to apply the principles, I have found the following tips and tricks to be very helpful:
1. Follow SRP: Keep classes focused on a single responsibility. If a class is doing too much, break it down into smaller, dedicated classes.
2. Use Interfaces for OCP: Instead of modifying existing classes, extend functionality using interfaces or abstract classes to make your code more flexible.
3. Avoid Violating LSP: Ensure that subclasses can replace their parent class without unexpected behavior changes. Design your classes to adhere to expected functionality.
4. Break Down Large Interfaces (ISP): If an interface has too many methods, split it into smaller, more specific interfaces to avoid forcing classes to implement unused methods.
5. Use Dependency Injection for DIP: Instead of hardcoding dependencies, inject them via constructors or setters to make your code more modular and testable.
6. Refactor Regularly: Applying SOLID isn’t a one-time task. Review your code periodically to identify violations and improve maintainability. Of course, refactoring should only be performed after considering of overall project team budget, priorities, and downstream impacts.
7. Write Unit Tests: SOLID-compliant code is easier to test. Writing unit tests helps enforce these principles and ensures code remains reliable.
8. Leverage PHP Design Patterns: Patterns like Factory, Strategy, and Dependency Injection complement SOLID and improve code structure.
9. Use Autoloading & Namespaces: Keep your classes organised using PHP’s autoload and namespace features to maintain clean, scalable code.
10. Think Long-Term: Design your application with future changes in mind. Following SOLID ensures your codebase remains adaptable as requirements evolve.
Conclusion
Applying SOLID principles in PHP is essential for building maintainable, scalable, and flexible applications. By following these principles, developers can write cleaner, more structured code that is easier to modify, test, and extend as project requirements evolve.
Whether working on a small project or a large-scale enterprise application, adhering to SOLID ensures better code organisation, improved collaboration, and reduced technical debt. While it may take time to fully integrate these principles into your coding workflow, the long-term benefits far outweigh the initial effort.
Mastering SOLID is not an overnight process—it takes time, practice, and experience. A developer will naturally progress in their development career as they gain a deeper understanding of when and how to apply SOLID principles effectively through continuous learning and hands-on coding. Junior developers often struggle to balance SOLID principles with practical application. Still, as a developer refines their ability to design flexible and maintainable architectures, they will transition from junior to mid-level and eventually to senior, demonstrating a firm grasp of clean, scalable code.
By keeping Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion in mind and consistently practicing SOLID principles and refining their approach over time, a developer will gradually improve their skills, making their code more robust, maintainable, and future-proof. 🚀
