Unlocking Design Patterns: How Programming Paradigms Shape Your Code

1. Design Patterns and Programming Languages

Design patterns are reusable solutions to common software design problems, representing best practices for a class of issues.

Their core purpose is reuse and decoupling, making unstable depend on stable, concrete on abstract, thereby enhancing adaptability.

1.1 What Is a Design Pattern

A design pattern is a proven solution to a recurring problem in software development, summarised from extensive experience.

1.2 What Is a Programming Paradigm

Programming paradigms are viewpoints on how programs should be constructed and executed, a concept introduced by Robert Floyd in 1979.

The three mainstream paradigms are:

Structured programming – removes arbitrary goto jumps, enforcing one‑way control flow while keeping global data access.

Object‑oriented programming – groups data with its methods, limiting scope and using relationships for lookup.

Functional programming – treats data as immutable and composes functions to transform it, resulting in stateless pipelines.

Languages implement paradigms differently; for example, C follows structured programming, Java is primarily object‑oriented, and Java 8 added functional features.

1.3 Polymorphism

Object‑oriented languages provide three core features: encapsulation, inheritance, and polymorphism. Polymorphism lets a subclass replace its superclass, enabling flexible method calls and improving extensibility.

Python example:

class MyFile:
    def write(self):
        print('I write a message into file.')

class MyDB:
    def write(self):
        print('I write data into db.')

def doIt(writer):
    writer.write()

def demo():
    myFile = MyFile()
    myDB = MyDB()
    doIt(myFile)
    doIt(myDB)

2. Architecture Patterns

Architecture patterns provide reusable solutions to common structural problems in software systems, guiding module organization, communication interfaces, and overall topology.

The seminal GoF book introduced 23 design patterns, classified into creational, structural, and behavioral categories, as well as class‑level and object‑level patterns.

Typical architecture patterns include layered, microservices, and event‑driven architectures.

3. Practical Guide

Design patterns are not mandatory for every project; they become valuable when dealing with complex, tightly coupled problems.

Typical scenarios and case studies illustrate the use of factory, strategy, template method, builder, proxy, chain of responsibility, and command patterns through a temple water‑fetching story.

Factory Pattern

public interface Waterable {
    Water getWater();
}

public class TiaoShui implements Waterable {
    public Water getWater() {
        System.out.println("先到山下去！");
        return "水是挑上来的！";
    }
}

public class TaiShui implements Waterable {
    public Water getWater() {
        System.out.println("先到山下去！");
        return "水是抬上来的！";
    }
}

public class DengShui implements Waterable {
    public Water getWater() {
        System.out.println("就坐在原地！");
        return "水是等不来的！";
    }
}

public class Factory {
    public static Waterable getWaterable(Integer heShangNum) {
        switch (heShangNum) {
            case 1: return new TiaoShui();
            case 2: return new TaiShui();
            case 3: return new DengShui();
            default: throw new RuntimeException("庙小，装不下那么多和尚！");
        }
    }
}

Strategy Pattern

public void getWater(Integer heShangNum) {
    Waterable waterable = Factory.getWaterable(heShangNum);
    Water water = waterable.getWater(); // 取水
}

Template Method Pattern

public abstract class AbstractWaterable implements Waterable {
    @Override
    public Water getWater() {
        takeTool();
        toRiver();
        return moveWater();
    }
    protected abstract String takeTool();
    protected String toRiver() {
        System.out.println("走过去！");
        return "步行";
    }
    protected abstract Water moveWater();
}

Builder Pattern

public class ToolBox {
    private final String bianDan;
    private final String muTong;
    private final String muGun;
    private ToolBox(TiaoBuilder builder) { ... }
    private ToolBox(TaiBuilder builder) { ... }
    private ToolBox(DengBuilder builder) { ... }
    public static class TiaoBuilder { ... }
    public static class TaiBuilder { ... }
    public static class DengBuilder { ... }
}

Proxy Pattern

public class WaterableProxy implements Waterable {
    private Waterable waterable;
    public WaterableProxy(Waterable waterable) { this.waterable = waterable; }
    @Override
    public Water getWater() {
        Water water = waterable.getWater();
        if (!"无水".equals(water)) {
            System.out.println("我敲一下木鱼，打一次卡！");
        }
        return water;
    }
}

Chain of Responsibility Pattern

public interface SecureFilter { void filter(Map context); }

public class PetSecure implements SecureFilter { ... }
public class WearSecure implements SecureFilter { ... }
public class OtherSecure implements SecureFilter { ... }

public class SecureChain implements SecureFilter {
    private List<SecureFilter> secureFilterList;
    @Override
    public void filter(Map context) {
        for (SecureFilter f : secureFilterList) { f.filter(context); }
        System.out.println("佛祖保佑，安检通过！");
    }
}

Command Pattern

public class Command implements Serializable { private OrderTypeEnum order; private Integer direction; }
public interface OrderHandler { PipeResult execute(CallContext ctx); OrderTypeEnum getOrderType(); }
public interface PipelineCmd { Command getCommand(); PipeResult execute(PipeContext ctx); default boolean isReversible() { return true; } }
// Additional classes CmdFactory, CmdHandlerImpl, etc., illustrate command creation, execution, and rollback.

3.3 Insights

Design principles such as SRP, OCP, LSP, DIP, ISP, and LKP guide low coupling, high reuse, high cohesion, and easy extensibility. Design patterns operationalise these principles, often combining several of them.

Effective learning of design patterns requires practical application rather than rote memorisation, and avoiding over‑engineering simple problems.

Overall, the article analyses the relationship between design patterns, programming paradigms, and architecture patterns, and provides concrete guidance for applying them in real projects.