SOLID Principles in PHP: How we applied them to a real industrial catalogue

Introduction

When we at Portocarrero started designing the ProSilicones64 architecture, we had a clear problem: the catalogue wasn't a flat list of products. It was 30 products that could be manufactured in 19 different silicone series, each series with its own thermal and hardness properties, applicable to 10 different industrial sectors, and subject to 127 standards and certifications.

If we'd crammed everything into a 2,000-line ProductController with switches and conditionals, the system would have worked... for about three months. After that, every change would have been a nightmare.

SOLID principles gave us the structure to let the code grow. We didn't apply them for academic purism, but because a complex industrial catalogue needs an architecture that reflects that complexity without becoming an unmaintainable monster.

The Problem

The WordPress we replaced had exactly the problems SOLID prevents. There was a catalogue plugin with a CatalogManager class that did everything: queried products, calculated prices, validated stock, generated PDFs, sent emails. 1,847 lines in a single file.

Every time the client asked for a change—"add the naval sector", "show maximum temperature on the product page"—meant diving into that file, praying nothing broke, and testing manually because unit tests were impossible.

• 1,847 lines in a single CatalogManager class
• 34 public methods doing everything
• 12 hardcoded dependencies (MySQL, mailer, logger...)
• 0 possible unit tests due to coupling
• Every change = regression risk

That's what happens when you don't apply SRP. And it drags along the other problems: you can't extend without modifying (violates OCP), you can't substitute components (violates LSP), you depend on concrete implementations (violates DIP).

SRP: Each class does one thing

We split the monolith into pieces with clear responsibilities

In ProSilicones64, product-series-sector-standard relationships are the core of the business. If a single class manages everything, any change to certifications affects the catalogue, the exporter, the technical sheets. We separated by responsibility: each class has a single reason to change.

<?php
class CatalogManager
{
    public function getProduct($id)
    {
        // Direct SQL query
        $product = $this->db->query('SELECT * FROM products WHERE id = ?', [$id]);
        // Calculate price with margin
        $product['price'] = $product['cost'] * 1.3;
        // Get applicable series
        $product['series'] = $this->db->query('SELECT * FROM series WHERE...');
        // Get certifications
        $product['certs'] = $this->db->query('SELECT * FROM certifications WHERE...');
        // Generate card HTML
        $product['html'] = $this->renderProductCard($product);
        // Log
        $this->logger->info('Product retrieved');
        return $product;
    }
    // ... 33 more methods
}

<?php
// Product queries only
class ProductRepository
{
    public function findById(int $id): ?Product
    {
        return $this->db->query(
            'SELECT * FROM products WHERE id = ?', 
            [$id]
        )->fetch(Product::class);
    }
}

// Series logic only
class SeriesService
{
    public function getForProduct(int $productId): array
    {
        return $this->seriesRepo->findByProduct($productId);
    }
}

// Certification validation only
class CertificationValidator
{
    public function validate(Product $p, Series $s, Sector $sec): bool
    {
        $required = $sec->getRequiredCertifications();
        $available = $s->getCertifications();
        return empty(array_diff($required, $available));
    }
}

// Orchestrates pieces, no logic
class ProductService
{
    public function __construct(
        private ProductRepository $products,
        private SeriesService $series,
        private CertificationValidator $validator
    ) {}

    public function getProductWithSeries(int $id): array
    {
        $product = $this->products->findById($id);
        $series = $this->series->getForProduct($id);
        return ['product' => $product, 'series' => $series];
    }
}

OCP: Add sectors without modifying code

Open for extension, closed for modification

When the client said "we're adding the naval sector", we didn't have to touch any existing class. Each sector has its requirements class implementing a common interface. Adding a sector = create class + insert data in DB.

<?php
class SectorValidator
{
    public function getRequirements(string $sector): array
    {
        switch ($sector) {
            case 'railway':
                return ['EN45545-2-HL2', 'EN45545-2-HL3'];
            case 'food':
                return ['FDA-21CFR177', 'EU-1935-2004'];
            case 'medical':
                return ['ISO-10993', 'USP-CLASS-VI'];
            // Each new sector = modify this switch
        }
    }
}

<?php
interface SectorRequirements
{
    public function getCertifications(): array;
    public function validateSeries(Series $series): bool;
}

class RailwaySectorRequirements implements SectorRequirements
{
    public function getCertifications(): array
    {
        return ['EN45545-2-HL2', 'EN45545-2-HL3'];
    }

    public function validateSeries(Series $series): bool
    {
        return $series->maxTemperature >= 150;
    }
}

// Adding naval sector = create this class. Nothing else.
class NavalSectorRequirements implements SectorRequirements
{
    public function getCertifications(): array
    {
        return ['DNV-GL', 'USCG-164'];
    }

    public function validateSeries(Series $series): bool
    {
        return $series->saltWaterResistant === true;
    }
}

LSP: All exporters are interchangeable

Subclasses substitute their parents without breaking anything

ProSilicones64 exports technical sheets in PDF, data for ERPs in CSV, and catalogues in XML. All exporters implement the same interface: receive a Product, return a string. The controller doesn't know or care what format it's generating.

<?php
class PdfExporter
{
    public function export($product)
    {
        return $this->pdf->generate($product); // Binary
    }
}

class CsvExporter
{
    public function export($product)
    {
        return [$product['name'], $product['sku']]; // Array
    }
}

class XmlExporter
{
    public function export($product)
    {
        echo '<product>' . $product['name'] . '</product>'; // Prints
    }
}

<?php
interface ProductExporter
{
    public function export(Product $product): string;
    public function getContentType(): string;
}

class PdfExporter implements ProductExporter
{
    public function export(Product $product): string
    {
        $html = $this->template->render('technical-sheet', $product);
        return $this->pdfEngine->fromHtml($html);
    }

    public function getContentType(): string { return 'application/pdf'; }
}

// Generic controller works with any exporter
class ExportController
{
    public function download(int $id, string $format): Response
    {
        $product = $this->products->findById($id);
        $exporter = $this->factory->create($format);

        return new Response(
            $exporter->export($product),
            ['Content-Type' => $exporter->getContentType()]
        );
    }
}

ISP: Small, specific interfaces

Nobody depends on methods they don't use

Public catalogue views only read products. Admin panel reads and writes. Search system only filters. Instead of one giant interface everyone implements, we separate by use case.

<?php
interface ProductRepositoryInterface
{
    public function findById(int $id): ?Product;
    public function findBySlug(string $slug): ?Product;
    public function findAll(): array;
    public function save(Product $product): void;
    public function delete(int $id): void;
    public function search(string $query): array;
    public function export(string $format): string;
    public function import(string $data): void;
    // 12 methods total
}

// Public catalogue implements this but leaves 6 methods empty

<?php
interface ReadableProducts
{
    public function findById(int $id): ?Product;
    public function findBySlug(string $slug): ?Product;
}

interface WritableProducts
{
    public function save(Product $product): void;
    public function delete(int $id): void;
}

interface SearchableProducts
{
    public function search(string $query): array;
}

// Public catalogue only needs reading
class PublicCatalogController
{
    public function __construct(private ReadableProducts $products) {}
}

// Admin needs read and write
class AdminController
{
    public function __construct(
        private ReadableProducts $reader,
        private WritableProducts $writer
    ) {}
}

DIP: Logic doesn't know infrastructure

Depend on abstractions, not implementations

SeriesService doesn't know if the cache is Redis, JSON files, or memory. It only knows it has something implementing CacheInterface. Changing cache system means changing one line in the dependency container.

<?php
class ProductService
{
    public function __construct()
    {
        // Concrete dependencies, impossible to change
        $this->cache = new RedisCache('localhost:6379');
        $this->db = new MySQLConnection('host=db user=root');
    }
}

<?php
interface CacheInterface
{
    public function get(string $key): mixed;
    public function set(string $key, mixed $value, int $ttl): void;
}

class ProductService
{
    public function __construct(
        private CacheInterface $cache,
        private ProductRepository $repository
    ) {}
}

// In production
$service = new ProductService(new FileCache('/var/cache'), $repo);

// In tests
$service = new ProductService(new ArrayCache(), $mockRepo);

Conclusion

At Portocarrero we don't apply SOLID because it looks good on a CV. We apply it because an industrial catalogue with complex relationships needs an architecture that can grow. If you cram everything into one giant file, it'll work today and be hell tomorrow.

The five principles boil down to one idea: each piece does one thing, pieces connect through clear contracts, and adding functionality means adding new pieces, not modifying existing ones.

ProSilicones64 has been in production for six months. It's grown with three new sectors, two export formats, ERP integration, and a dynamic technical sheet system. The code from day one still works unchanged. That's what SOLID enables.