Articles – dev @mr

Introduction: Why SOLID Matters Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP) Summary & Key Takeaways Mastering SOLID Principles: The Foundation of Maintainable Architecture Author: Wiktor Gindorowicz | Technical Scrum Master & Software Engineer Published: October 2026 Writing code that merely compiles and passes tests is only half the battle. In modern enterprise software development, requirements change rapidly, systems scale, and technical debt accumulates if code is tightly coupled. The SOLID principles—introduced by Robert C. Martin (Uncle Bob)—represent five fundamental design principles for writing clean, understandable, and highly maintainable object-oriented software. In this article, we will break down each principle with practical Java implementations and architectural context. Introduction: Why SOLID Matters When applications grow, they often suffer from rigidity (hard to change), fragility (changes break unrelated features), and immobility (difficult to reuse code in other projects). SOLID provides a mental framework and structural guidelines to decouple components, making systems resilient to change. Single Responsibility Principle (SRP) Core Concept “A class should have one, and only one, reason to change.” SRP states that a software module or class should be responsible for a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. If a class handles database operations, business logic, and PDF generation simultaneously, any change in reporting format forces a modification to core business logic. Java Implementation (Correct Approach) Separating business logic from persistence and reporting:


// Business Logic Domain Model
public class Order {
    private final String orderId;
    private final BigDecimal totalAmount;
    public Order(String orderId, BigDecimal totalAmount) {
        this.orderId = orderId;
        this.totalAmount = totalAmount;
    }
    public BigDecimal getTotalAmount() { return totalAmount; }
    public String getOrderId() { return orderId; }
}
// Separate Responsibility: Database Persistence
public class OrderRepository {
    public void saveToDatabase(Order order) {
        System.out.println("Saving order " + order.getOrderId() + " to PostgreSQL database.");
    }
}
// Separate Responsibility: Invoice/Report Generation
public class InvoicePrinter {
    public void printPdf(Order order) {
        System.out.println("Generating PDF invoice for order: " + order.getOrderId());
    }
}

// Business Logic Domain Model

public class Order {

private final String orderId;

private final BigDecimal totalAmount;

public Order(String orderId, BigDecimal totalAmount) {

this.orderId = orderId;

this.totalAmount = totalAmount;

}

public BigDecimal getTotalAmount() { return totalAmount; }

public String getOrderId() { return orderId; }

}

// Separate Responsibility: Database Persistence

public class OrderRepository {

public void saveToDatabase(Order order) {

System.out.println("Saving order " + order.getOrderId() + " to PostgreSQL database.");

}

// Separate Responsibility: Invoice/Report Generation

public class InvoicePrinter {

public void printPdf(Order order) {

System.out.println("Generating PDF invoice for order: " + order.getOrderId());

}

Open/Closed Principle (OCP) Core Concept “Software entities should be open for extension, but closed for modification.” You should be able to extend the behavior of a class or component without altering its existing source code. This is typically achieved through polymorphism—using abstract classes or interfaces. Java Implementation Instead of using massive switch/case statements inside a service every time a new discount type arrives, we introduce a strategy-like interface:


import java.math.BigDecimal;
// Open for extension through new implementations
public interface DiscountStrategy {
    BigDecimal applyDiscount(BigDecimal amount);
}
public class VipDiscount implements DiscountStrategy {
    @Override
    public BigDecimal applyDiscount(BigDecimal amount) {
        return amount.multiply(BigDecimal.valueOf(0.85)); // 15% off
    }
}
public class SeasonalDiscount implements DiscountStrategy {
    @Override
    public BigDecimal applyDiscount(BigDecimal amount) {
        return amount.multiply(BigDecimal.valueOf(0.90)); // 10% off
    }
}
// Closed for modification (OrderService doesn't change when a new discount type is added)
public class CheckoutService {
    public BigDecimal calculateFinalPrice(BigDecimal baseAmount, DiscountStrategy strategy) {
        return strategy.applyDiscount(baseAmount);
    }
}

import java.math.BigDecimal;

// Open for extension through new implementations

public interface DiscountStrategy {

BigDecimal applyDiscount(BigDecimal amount);

}

public class VipDiscount implements DiscountStrategy {

@Override

public BigDecimal applyDiscount(BigDecimal amount) {

return amount.multiply(BigDecimal.valueOf(0.85)); // 15% off

}

public class SeasonalDiscount implements DiscountStrategy {

@Override

public BigDecimal applyDiscount(BigDecimal amount) {

return amount.multiply(BigDecimal.valueOf(0.90)); // 10% off

}

// Closed for modification (OrderService doesn't change when a new discount type is added)

public class CheckoutService {

public BigDecimal calculateFinalPrice(BigDecimal baseAmount, DiscountStrategy strategy) {

return strategy.applyDiscount(baseAmount);

}

Liskov Substitution Principle (LSP) Core Concept “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.” Subclasses must maintain the behavioral expectations of the base class. If a class overrides a method in a way that breaks functionality or throws unexpected unsupported operations, it violates LSP. Java Implementation A classic violation is the “Square-Rectangle” problem. A better approach is focusing on clean abstraction:


public interface Renderable {
    void render();
}
public class VectorGraphic implements Renderable {
    @Override
    public void render() {
        System.out.println("Rendering scalable vector graphic.");
    }
}
public class RasterImage implements Renderable {
    @Override
    public void render() {
        System.out.println("Rendering raster pixel image.");
    }
}
// Any Renderable can be safely substituted anywhere without breaking the caller
public class Canvas {
    public void drawElement(Renderable element) {
        element.render(); // Safe substitution
    }
}

public interface Renderable {

void render();

}

public class VectorGraphic implements Renderable {

@Override

public void render() {

System.out.println("Rendering scalable vector graphic.");

}

public class RasterImage implements Renderable {

@Override

public void render() {

System.out.println("Rendering raster pixel image.");

}

// Any Renderable can be safely substituted anywhere without breaking the caller

public class Canvas {

public void drawElement(Renderable element) {

element.render(); // Safe substitution

}

Interface Segregation Principle (ISP) Core Concept “Clients should not be forced to depend upon interfaces that they do not use.” Instead of creating massive, monolithic interfaces (fat interfaces), break them down into smaller, client-specific role interfaces. A class implementing an interface should not be forced to implement dummy methods it doesn’t need. Java Implementation


// Bad: Fat interface forcing implementation of unused methods
// interface Worker { void work(); void eat(); void code(); }
// Good: Segregated interfaces
public interface Workable {
    void work();
}
public interface Feedable {
    void eat();
}
public class HumanWorker implements Workable, Feedable {
    @Override
    public void work() { System.out.println("Human working on software architecture."); }
    @Override
    public void eat() { System.out.println("Human taking a lunch break."); }
}
public class RobotWorker implements Workable {
    @Override
    public void work() { System.out.println("Robot processing automated build tasks 24/7."); }
    // Robots don't need eat()! No forced empty implementation.
}

// Bad: Fat interface forcing implementation of unused methods

// interface Worker { void work(); void eat(); void code(); }

// Good: Segregated interfaces

public interface Workable {

void work();

}

public interface Feedable {

void eat();

}

public class HumanWorker implements Workable, Feedable {

@Override

public void work() { System.out.println("Human working on software architecture."); }

@Override

public void eat() { System.out.println("Human taking a lunch break."); }

}

public class RobotWorker implements Workable {

@Override

public void work() { System.out.println("Robot processing automated build tasks 24/7."); }

// Robots don't need eat()! No forced empty implementation.

}

Dependency Inversion Principle (DIP) Core Concept “A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.” DIP decouples high-level business logic from low-level infrastructure details (like specific databases, email gateways, or REST clients) by introducing interfaces. Java Implementation


// Abstraction
public interface NotificationSender {
    void sendNotification(String message);
}
// Low-level Detail
public class EmailNotificationSender implements NotificationSender {
    @Override
    public void sendNotification(String message) {
        System.out.println("Sending email alert: " + message);
    }
}
// High-level Module depending on Abstraction (injected via constructor)
public class UserService {
    private final NotificationSender notificationSender;
    public UserService(NotificationSender notificationSender) {
        this.notificationSender = notificationSender;
    }
    public void registerUser(String username) {
        System.out.println("User " + username + " registered successfully.");
        notificationSender.sendNotification("Welcome to the platform, " + username + "!");
    }
}

// Abstraction

public interface NotificationSender {

void sendNotification(String message);

}

// Low-level Detail

public class EmailNotificationSender implements NotificationSender {

@Override

public void sendNotification(String message) {

System.out.println("Sending email alert: " + message);

}

// High-level Module depending on Abstraction (injected via constructor)

public class UserService {

private final NotificationSender notificationSender;

public UserService(NotificationSender notificationSender) {

this.notificationSender = notificationSender;

}

public void registerUser(String username) {

System.out.println("User " + username + " registered successfully.");

notificationSender.sendNotification("Welcome to the platform, " + username + "!");

}

Summary & Key Takeaways Mastering SOLID transforms code from a fragile house of cards into a robust, scalable architecture: S – Keep classes focused on a single responsibility. O – Write code that accommodates new features via extension, not rewriting. L – Ensure subtypes strictly honor base-type behavior. I – Keep interfaces lean and tailored to specific clients. D – Depend on abstractions, not concrete implementations (Inversion of Control). Applying these principles elevates code from functional to enterprise-grade engineering standards.

Introduction: Why Design Patterns Matter Facade Pattern (Structural) Builder Pattern (Creational) Strategy Pattern (Behavioral) Comparative Matrix & Key Takeaways Mastering Object-Oriented Design: Facade, Builder, and Strategy Patterns Author: Wiktor Gindorowicz | Technical Scrum Master & Software Engineer Published: October 2026 Software development is rarely just about writing code that works; it is about writing code that remains maintainable, scalable, and adaptable over time. Object-Oriented Design Patterns represent proven, industry-tested solutions to common architectural challenges. Introduction: Why Design Patterns Matter In this article, we will break down three essential patterns—Facade, Builder, and Strategy—exploring their real-world analogies, structural mechanics, advantages, pseudocode, and Java implementations. Facade Pattern (Structural) Overview & Core Concept According to the principles of structural design, a system often grows complex as it scales, accumulating dozens of interconnected classes, subsystem initializations, and intricate execution flows. The Facade Pattern provides a simplified, high-level interface to a complex framework, library, or set of subsystem classes. Instead of forcing client code to manage dependencies and execute steps in a strict order, the Facade offers a single entry point that orchestrates the underlying complexity. Real-World Analogy Think of starting a modern car. As a driver (client), you don’t want to manually manage fuel valves, electrical pumps, and spark plugs. Instead, you use a single interface: the ignition button (CarFacade). When you call startCar(), the facade automatically coordinates the internal subsystems behind the scenes: it first turns on the ignition (ignition.turnOn()), primes the fuel pump (fuelPump.inject()), and finally fires up the engine (engine.start()). When to Apply When you need a limited, straightforward interface to a complex subsystem. When you want to structure a subsystem into layers (using Facades as entry points for each layer). Pros & Cons Pros: Isolates your code from the complexity of a subsystem; decouples client code from third-party frameworks. Cons: A Facade risks becoming a “God Object” coupled to all classes of an app if not kept focused.


// Subsystem Components
class Engine {
    public void start() { 
        System.out.println("Engine started successfully."); 
    }
}
class Ignition {
    public void turnOn() { 
        System.out.println("Ignition switched ON."); 
    }
}
class FuelPump {
    public void inject() { 
        System.out.println("Fuel pump pressurized and injected."); 
    }
}
// Facade Class
public class CarFacade {
    private final Engine engine = new Engine();
    private final Ignition ignition = new Ignition();
    private final FuelPump fuelPump = new FuelPump();
    public void startCar() {
        ignition.turnOn();
        fuelPump.inject();
        engine.start();
    }
}
// Execution
public class Main {
    public static void main(String[] args) {
        CarFacade car = new CarFacade();
        car.startCar(); // Single entry point call
    }
}

// Subsystem Components

class Engine {

public void start() {

System.out.println("Engine started successfully.");

}

class Ignition {

public void turnOn() {

System.out.println("Ignition switched ON.");

}

class FuelPump {

public void inject() {

System.out.println("Fuel pump pressurized and injected.");

}

// Facade Class

public class CarFacade {

private final Engine engine = new Engine();

private final Ignition ignition = new Ignition();

private final FuelPump fuelPump = new FuelPump();

public void startCar() {

ignition.turnOn();

fuelPump.inject();

engine.start();

}

// Execution

public class Main {

public static void main(String[] args) {

CarFacade car = new CarFacade();

car.startCar(); // Single entry point call

}

// UML Diagram // Pseudocode class Engine:method start(): print “Engine running” class Ignition:method turnOn(): print “Ignition ON” class FuelPump:method inject(): print “Fuel injected” class CarFacade:private engine = new Engine()private ignition = new Ignition()private fuelPump = new FuelPump() method startCar():ignition.turnOn()fuelPump.inject()engine.start() Builder Pattern (Creational) Overview & Core Concept The Builder Pattern is a creational pattern designed to separate the construction of a complex object from its representation. When a class constructor requires five, six, or more parameters—many of which are optional—you face the “Telescoping Constructor” anti-pattern (constructors calling constructors with varying parameters). The Builder pattern allows you to construct complex objects step-by-step using a readable, fluent interface. Real-World Analogy Think of custom-building a gravel bicycle in a specialized workshop. Instead of dealing with a massive constructor cluttered with parameters or modifying parts on a finished bike, you use a dedicated configurator (Builder). Step by step, you specify the required frame and optional handlebars using a fluent interface (return this). Before the bike leaves the workshop, a final quality check in build() ensures the mandatory frame is present. Once completed, you receive a fully assembled, immutable Bicycle whose specs cannot be altered anymore. When to Apply To get rid of a “telescoping constructor” with too many optional parameters. When you want your code to create different representations of some product (e.g., carbon gravel bike vs. aluminum road bike). Pros & Cons Pros: Allows step-by-step object creation; defers execution steps; enforces the Single Responsibility Principle by separating construction from business logic. Cons: Increases overall code complexity by requiring multiple new classes.


public final class Bicycle {
    private final String frame;
    private final String handlebars;
    private Bicycle(Builder builder) {
        this.frame = builder.frame;
        this.handlebars = builder.handlebars;
    }
    public void displayInfo() {
        System.out.println("Bicycle Specs -> Frame: " + frame + " | Handlebars: " + handlebars);
    }
    public static class Builder {
        private String frame;
        private String handlebars;
        public Builder frame(String frame) {
            this.frame = frame;
            return this;
        }
        public Builder handlebars(String handlebars) {
            this.handlebars = handlebars;
            return this;
        }
        public Bicycle build() {
            if (frame == null || frame.isBlank()) {
                throw new IllegalStateException("Frame is required to build a bicycle.");
            }
            return new Bicycle(this);
        }
    }
}

public final class Bicycle {

private final String frame;

private final String handlebars;

private Bicycle(Builder builder) {

this.frame = builder.frame;

this.handlebars = builder.handlebars;

}

public void displayInfo() {

System.out.println("Bicycle Specs -> Frame: " + frame + " | Handlebars: " + handlebars);

}

public static class Builder {

private String frame;

private String handlebars;

public Builder frame(String frame) {

this.frame = frame;

return this;

}

public Builder handlebars(String handlebars) {

this.handlebars = handlebars;

return this;

}

public Bicycle build() {

if (frame == null || frame.isBlank()) {

throw new IllegalStateException("Frame is required to build a bicycle.");

}

return new Bicycle(this);

}

// UML Diagram // Pseudocode class Bicycle:field frame: Stringfield handlebars: Stringconstructor(builder):this.frame = builder.framethis.handlebars = builder.handlebars class Builder:field frame: Stringfield handlebars: String method frame(value):this.frame = valuereturn this method build():if frame is null: error “Frame is mandatory”return new Bicycle(this) Strategy Pattern (Behavioral) Overview & Core Concept The Strategy Pattern is a behavioral pattern that defines a family of algorithms, encapsulates each one into a separate class, and makes their objects interchangeable. Instead of embedding multiple algorithms directly into a class using monolithic conditional statements (if/else or switch), Strategy extracts the algorithms into separate classes (strategies) that adhere to a common interface. Real-World Analogy Imagine checking out in an e-commerce cart (ShoppingCart). At the final step, the system needs to charge a specific BigDecimal amount, but it doesn’t care whether you pay via BLIK or a Credit Card. The cart acts as a context holding a general PaymentStrategy. At runtime, you inject a specific implementation (e.g., BLIKPayment via setPaymentStrategy()). When checkout() is triggered, the cart simply delegates the payment to the chosen strategy without knowing its internal processing details. When to Apply When you want to use different variants of an algorithm within an object and switch from one algorithm to another during runtime. When you have a lot of similar classes that only differ in the way they execute some behavior. To isolate the business logic of a class from the implementation details of algorithms. Pros & Cons Pros: You can swap algorithms used inside an object at runtime; adheres to the Open/Closed Principle (add new strategies without modifying context code); eliminates bulky conditional logic. Cons: Clients must be aware of the differences between strategies to select the right one.


import java.math.BigDecimal;
// Strategy Interface
interface PaymentStrategy {
    void pay(BigDecimal amount);
}
// Concrete Strategy: BLIK
class BLIKPayment implements PaymentStrategy {
    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Processing " + amount + " PLN payment via BLIK code.");
    }
}
// Concrete Strategy: Credit Card
class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Processing " + amount + " PLN payment via Credit Card.");
    }
}
// Context Class
public class ShoppingCart {
    private PaymentStrategy paymentStrategy;
    public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }
    public void checkout(BigDecimal amount) {
        if (paymentStrategy == null) {
            throw new IllegalStateException("Payment strategy cannot be null. Please select a method.");
        }
        paymentStrategy.pay(amount);
    }
}

import java.math.BigDecimal;

// Strategy Interface

interface PaymentStrategy {

void pay(BigDecimal amount);

}

// Concrete Strategy: BLIK

class BLIKPayment implements PaymentStrategy {

@Override

public void pay(BigDecimal amount) {

System.out.println("Processing " + amount + " PLN payment via BLIK code.");

}

// Concrete Strategy: Credit Card

class CreditCardPayment implements PaymentStrategy {

@Override

public void pay(BigDecimal amount) {

System.out.println("Processing " + amount + " PLN payment via Credit Card.");

}

// Context Class

public class ShoppingCart {

private PaymentStrategy paymentStrategy;

public void setPaymentStrategy(PaymentStrategy paymentStrategy) {

this.paymentStrategy = paymentStrategy;

}

public void checkout(BigDecimal amount) {

if (paymentStrategy == null) {

throw new IllegalStateException("Payment strategy cannot be null. Please select a method.");

}

paymentStrategy.pay(amount);

}

// UML Diagram // Pseudocode interface PaymentStrategy:method pay(amount) class BLIKPayment implements PaymentStrategy:method pay(amount): print “Paid via BLIK: ” + amount class ShoppingCart:private strategy: PaymentStrategy method setPaymentStrategy(newStrategy):this.strategy = newStrategy method checkout(amount):strategy.pay(amount) Comparative Matrix & Key Takeaways Pattern Category Primary Intent Key Benefit Real-World E-Commerce Example Facade Structural Provide a simplified interface to a complex set of classes. Hides subsystem complexity from the client. Single-click checkout triggering order, inventory, and shipping services. Builder Creational Construct complex objects step-by-step. Avoids telescoping constructors and separates construction logic. Building custom product bundles or tailored bicycles. Strategy Behavioral Encapsulate interchangeable algorithms behind a common interface. Swaps behavior at runtime and eliminates huge switch/if blocks. Selecting payment providers (BLIK, Credit Card, PayPal) or shipping methods. Summary & Key Takeaways Design patterns are tools, not silver bullets. Understanding when and why to apply them dictates clean architecture: Use

More Info

Looking for a professional who understands technology? Let's talk about how I can help your team deliver better products in an agile environment.

Quick Links

Services

About Me

Projects

Contact

Address

+48 660544777

wiktor.gindorowicz@gmail.com