Software Engineering Principles & Patterns

1) What are principles and patterns?

They are established solutions to recurring software problems. They are not libraries you install, but organizational recipes: tested ways to structure code so it remains easy to read, test, change and reuse. There are three broad levels, from general to concrete:

• Principles (KISS, DRY, YAGNI, SOLID): rules of thumb that guide day-to-day decisions.
• Design patterns (Factory, Strategy, Observer): recurring solutions involving classes and objects.
• Architectural patterns (MVC, MVVM, Clean Architecture): ways to organize the whole system into responsibilities and layers.

2) Foundations: KISS, DRY and YAGNI

Before sophisticated patterns, three simple principles prevent much of the avoidable complexity in software:

• KISS (Keep It Simple, Stupid): prefer simple, readable solutions; unnecessary complexity raises defect and maintenance costs.
• DRY (Don't Repeat Yourself): eliminate duplication to reduce inconsistency and rework — each business rule should have one authoritative implementation.
• YAGNI (You Aren't Gonna Need It): implement what creates value now; avoid building hypothetical features that may never be used.

3) SOLID — the five object-oriented principles

SOLID is an acronym for five principles popularized by Robert C. Martin. Their purpose is to keep code flexible, decoupled and testable, making future change cheaper.

Example: Single Responsibility (SRP)

Before — the class calculates, persists and sends email:

class Order:
    def calculate_total(self): ...
    def save_to_database(self): ...   # persistence responsibility
    def send_email(self): ...         # notification responsibility

After — each class has one reason to change:

class Order:
    def calculate_total(self): ...

class OrderRepository:
    def save(self, order): ...

class Notifier:
    def send_email(self, order): ...

Example: Dependency Inversion (DIP)

High-level code depends on an abstraction, so replacing the delivery service does not require changing business logic:

class DeliveryChannel:
    def send(self, message): raise NotImplementedError

class Email(DeliveryChannel):
    def send(self, message): print("email:", message)

class SMS(DeliveryChannel):
    def send(self, message): print("sms:", message)

class Notifier:
    def __init__(self, channel: DeliveryChannel):
        self.channel = channel
    def notify(self, message):
        self.channel.send(message)

4) Design Patterns (Gang of Four)

The 23 classic patterns from Design Patterns (1994) fall into three families. You do not need to memorize them. Learn the common ones and apply them when the problem actually appears.

Creational — how objects are created

Factory MethodAbstract FactoryBuilderSingletonPrototype

Factory: centralizes object creation so callers do not need to know which concrete class is instantiated.

def create_transport(kind):
    factory = {"car": Car, "ship": Ship, "plane": Plane}
    if kind not in factory:
        raise ValueError("Invalid transport")
    return factory[kind]()

Structural — how objects are composed

AdapterDecoratorFacadeProxyComposite

Adapter makes incompatible interfaces work together. Decorator adds behavior to an object without altering its class.

Behavioral — how objects collaborate

StrategyObserverCommandStateIterator

Strategy allows an algorithm to change at runtime:

class Shipping:
    def __init__(self, strategy):
        self.strategy = strategy
    def calculate(self, weight):
        return self.strategy(weight)

standard = Shipping(lambda w: w * 2)
express = Shipping(lambda w: w * 5)

Observer automatically notifies subscribers when an object's state changes; it underpins event systems and reactive interfaces.

Layer patterns: Repository and Service

• Repository: isolates data access (SQL, ORM or external API) behind a simple interface.
• Service: concentrates business rules and orchestrates repositories and other services.

5) Architectural patterns: MVC, MVVM and Clean Architecture

Where design patterns organize object collaboration, architectural patterns organize the system as a whole.

MVC — Model, View, Controller

• Model: data and business rules.
• View: the user-facing interface.
• Controller: receives user actions, interacts with the Model and selects the View.

User → Controller → Model (read/update data)
             ↓
           View (render result)

MVC is used by frameworks such as Spring, Laravel, Ruby on Rails and ASP.NET.

MVVM — Model, View, ViewModel

A variation designed for reactive interfaces. The ViewModel exposes screen-ready data and keeps the View synchronized with the Model through data binding.

Clean / Hexagonal Architecture

The business rules stay at the center and do not know about the database, framework or UI. Dependencies point inward, keeping the core independently testable.

[ Frameworks / UI / Database ] → [ Adapters ] → [ Use cases ] → [ Entities ]
       replaceable outside                                  stable core

Layered Architecture

Organizes the application into horizontal layers — usually presentation, domain/business and persistence — with controlled dependency direction.

Microservices

Split a system into independently deployable services. This can improve scaling and team autonomy, but adds operational and distributed-systems complexity. Poorly controlled coupling merely replaces spaghetti code with distributed spaghetti architecture.

6) Comparison: when to use each

7) Practical impact

• Maintainability: modular, cohesive code lowers the cost of change.
• Reliability: clear design plus automated tests reduce regressions.
• Security: input validation, explicit error handling and smaller attack surfaces.
• Performance: simplicity makes real bottlenecks easier to identify without premature optimization.
• Cost: less rework and lower technical debt over the system's life.

8) Metrics for tracking quality

9) Quick review checklist

• Is the code simple, without unnecessary abstractions?
• Is there duplication that should become a reusable function or module?
• Does each class/module have one coherent responsibility?
• Do tests cover critical flows and error scenarios?
• Are inputs validated and exceptions handled correctly?
• Are injection, XSS and secret leakage addressed?
• Does CI/CD block merges when tests or quality gates fail?

10) Code examples: modularity and security

Python — modularity + error handling

def calculate_product(value):
    return value * 0.9

def process_order(kind, value):
    calculators = {"product": calculate_product, "service": lambda v: v}
    if kind not in calculators:
        raise ValueError("Invalid type")
    return calculators[kind](value)

Java — protection against SQL injection

PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE login = ?"
);
stmt.setString(1, user);
ResultSet rs = stmt.executeQuery();

11) Common pitfalls

• Overengineering: applying five patterns to a trivial CRUD. Too many patterns can be as harmful as too few.
• Pattern for its own sake: use a pattern because the problem requires it, not to look sophisticated.
• Premature abstraction: creating interfaces for a single implementation without a concrete need.
• Singleton as a disguised global: easy to abuse, hard to test and hides dependencies.
• Metric as target rather than guide: blindly pursuing 100% coverage or zero complexity creates distorted incentives.

12) Resources

• Refactoring Guru — Design Patterns
• Full GoF pattern catalog
• Martin Fowler — Software Architecture
• The Clean Architecture — Robert C. Martin
• OWASP Top 10
• SonarQube
• GitHub Actions
• pytest
• JUnit 5

Summary: master the principles first, measure quality with objective signals, recognize design patterns when the problem actually calls for them, and choose architecture in proportion to system size. Patterns are tools, not goals; the end state should be simple, modular, testable, secure and change-friendly code.