Architectural Styles, SOLID Principles, and Design Patterns

Posted on Jul 2, 2025 in Computer Engineering in Systems and Information Technologies

Architectural Styles

Architectural Styles are reusable design solutions for common problems. They are defined by element types, connectors, topological layout, and semantic constraints. Each style addresses certain quality attributes but has tradeoffs, which are compensated with tactics (e.g., adding resources, intermediaries).

Common Architectural Styles

  • Layered: Layers use only downward communication, good for modularity and reuse, but can incur a performance hit. Often associated with the Module pattern.
  • Broker: Clients and servers communicate via a broker. Decouples components, enables dynamic binding, but adds latency, creates a Single Point of Failure (SPOF), can reduce security, and is harder to test. A Component & Connector pattern.
  • MVC (Model-View-Controller): Separates Model, View, and Controller. Handles user interface concerns well, but can be overkill for simple applications. A Component & Connector pattern.
  • Pipe & Filter: Filters in a series process data streams. Highly reusable and supports parallelism, but can be rigid. Filters act as producers, transformers, testers, and consumers. A Component & Connector pattern.
  • Client-Server: Clients request services; servers provide them. A classic pattern, but can lead to bottlenecks and makes altering logic difficult. A Component & Connector pattern.
  • P2P (Peer-to-Peer): Equal peers share resources. Scalable but can be complex regarding consistency and security. A Component & Connector pattern.
  • SOA (Service-Oriented Architecture): Distributed services communicate via SOAP/REST. Flexible but infrastructure-heavy with potential performance hits. A Component & Connector pattern.
  • Pub-Sub (Publish-Subscribe): Publishers send events to a message bus, and subscribers listen. Decoupled but adds delay, order is not guaranteed, and can be lossy. A Component & Connector pattern.
  • Shared Data: All components access a single data store. Centralizes data but can create bottlenecks and tight coupling. A Component & Connector pattern.
  • MapReduce: Designed for petabyte-scale data. Map filters data, Reduce aggregates it. Good for big data processing only. An Allocation style.
  • Multi-Tier: Logical tiers (e.g., UI, business logic, database) deployed on distinct machines. Modular but can have high setup costs. An Allocation style.

SOLID Principles for Software Design

Symptoms of Poor Software Design

  • Rigidity: Hard to change.
  • Fragility: Breaks easily with minor changes.
  • Immobility: Difficult to reuse in other projects.
  • Viscosity: Hard to do the right thing; easy to do the wrong thing.
  • Unnecessary Complexity: Over-design.
  • Repetition: Copy-paste hell.
  • Opacity: Code is tangled and hard to understand.

The SOLID Principles

  • S – Single Responsibility Principle (SRP): Each object or module should have only one reason to change.
  • O – Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
  • L – Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering the correctness of the program.
  • I – Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. Better to have many small, specific interfaces than one large, general-purpose interface.
  • D – Dependency Inversion Principle (DIP): Depend upon abstractions, not concretions. High-level modules should not depend on low-level modules; both should depend on abstractions.

The Goal of SOLID

To create software that is effective, clean, flexible, maintainable, and scalable. This is achieved through high cohesion (unity) and low coupling (independence).

Software Design Patterns

What are Design Patterns?

A description of interacting classes and objects, adapted to solve a recurring problem in a specific context. They are effective and reusable solutions.

Key Characteristics of Design Patterns

  • Solves a recurring problem.
  • Is a proven concept.
  • The solution is not obvious.
  • Describes a relationship: Patterns describe not only modules but also the internal structures and mechanisms of a system.
  • Has a significant human component: All software serves human comfort or quality of life.

Gang of Four (GOF) Pattern Template

The Gang of Four (GOF) template typically includes:

  • Name
  • Classification (e.g., Creational, Structural, Behavioral)
  • Intent (What it does)
  • Motivation (Demonstrates how it solves a problem)
  • Applicability (When, how, and why to use it)
  • Structure (Graphical representation of classes)
  • Participants (Classes/objects and their responsibilities)
  • Collaborations (How participants interact)
  • Consequences (Trade-offs and impacts)
  • Implementation (Explanation of how to implement)
  • Example (Code snippet)
  • Known Uses
  • Related Patterns
  • Level (e.g., single class, component, architectural), Variants