Principles and Patterns in Software Design

Single Responsibility Principle (SRP)

A class should have only one reason to change, meaning it should do one thing.

Importance of SRP for maintainability

It promotes loose coupling and high cohesion, making code easier to maintain, test, and extend.

Sign of SRP violation

A class or method doing multiple unrelated things or long methods with different job sections.

Open-Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

Achieving OCP in code

By using inheritance, interfaces, or patterns like Strategy to add new behavior without changing existing code.

Violation clue of OCP

Large switch or if/else statements growing with new cases.

Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types without altering the program's correctness.

Example of LSP violation

A subclass overrides a method to throw an error or changes its meaning.

Interface Segregation Principle (ISP)

No client should be forced to depend on interfaces it doesn't use.

Signal of ISP violation

Classes implementing unused or dummy methods from large interfaces.

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules; both should depend on abstractions.

Benefits of DIP

It makes code more modular, testable, and easier to maintain.

Creational Design Patterns

Object creation mechanisms that improve flexibility and reuse.

Singleton pattern

Ensures a class has only one instance.

Factory Method pattern

It creates objects without specifying the exact class.

Builder pattern

Constructs complex objects step by step to avoid telescoping constructors.

Structural Design Patterns

Organizing classes and objects to form larger structures.

Adapter pattern

Converts one interface to another.

Decorator pattern

Adds behavior to objects dynamically at runtime.

Facade pattern

Simplifies complex systems by providing a unified interface.

Behavioral Design Patterns

Object interaction and responsibility delegation.

Observer pattern

A subject notifies multiple listeners about events or state changes.

Strategy pattern

Swapping algorithms at runtime to support OCP.

Command pattern

Encapsulates a request as an object, useful for undo/redo operations.

Bounded Context

A semantic boundary where a domain model applies and terms are well-defined.

Ubiquitous Language

A shared language used by developers and domain experts to ensure accurate code representation.

Domain Model

A conceptual model of the domain focused on essential behavior and knowledge.

Entity

An object with a unique identity that persists over time.

Value Object

An object defined only by its attributes, immutable and replaceable.

Aggregate

A group of related objects treated as a unit with a single root to ensure data integrity.

Domain Service

A stateless operation that performs actions and doesn't belong to any one entity or value object.

Domain Event

A significant event in the domain that triggers other actions.

Repository

Provides access to aggregates and abstracts away database interactions.

Concurrency

Performing multiple tasks seemingly at the same time.

Asynchronicity

Initiating a task and continuing execution without waiting for it to finish.

UI Responsiveness

It prevents the UI from freezing during long-running tasks.

Concurrency model based on event loops

Async/await - efficient for I/O-bound tasks on a single thread.

Thread-based concurrency model

Each task runs in its own thread, suitable for CPU-bound operations.

Coroutines

Lightweight functions that can pause and resume, used for concurrent operations.

Locks in concurrent systems

To prevent race conditions and ensure data consistency.

Fine-grained locking

Locks only a specific resource to maximize concurrency.

Coarse-grained locking

Locks larger resource sets, reducing concurrency but simplifying logic.

Transactional consistency

Ensuring database operations adhere to ACID properties under concurrency.

Common Coupling

Modules share access to the same global data or resources.

Temporal Coupling

One service relies on the timely response of another.

Domain Coupling

A necessary dependency due to the business domain.

Pass-through Coupling

A service relays data without understanding it, just to connect others.

Database bottlenecks

Limited connections, transactional overhead, and locking under load.

Runtime Architecture vs Code Structure

Runtime Architecture deals with system behavior during execution; Code Structure is about module organization and dependencies.