Understanding SOLID Principles, UML Relationships, and Common Design Patterns

1. Single Responsibility Principle

A class should have only one reason to change; multiple responsibilities lead to tight coupling and fragile designs.

2. Open-Closed Principle

Software entities should be open for extension but closed for modification, enabling maintainability and flexibility.

3. Liskov Substitution Principle

Subtypes must be substitutable for their base types, allowing modules that use base types to work without modification.

4. Dependency Inversion Principle

High‑level modules should not depend on low‑level modules; both should depend on abstractions, and abstractions should not depend on details.

5. Law of Demeter (Least Knowledge Principle)

Classes should only communicate with immediate friends; indirect interactions should be mediated through a third party to reduce coupling.

6. Composite/Aggregate Reuse Principle

Prefer composition or aggregation over class inheritance to keep each class focused on a single responsibility.

7. UML Example Diagram

‘+’ denotes public, ‘-’ private, ‘#’ protected; interfaces are shown at the top with «interface».

UML Relationship Types

1. Generalization

Inheritance relationship indicating a “is‑a” hierarchy (e.g., Tiger is a kind of Animal).

2. Realization

Class implements an interface, representing a contract between them.

3. Association

Bidirectional or unidirectional relationship where one class knows another’s attributes and methods (e.g., Teacher ↔ Student).

4. Aggregation

Weak “has‑a” relationship where the part can exist independently of the whole (e.g., Car and Tire).

5. Composition

Strong “has‑a” relationship where the part’s lifecycle is bound to the whole (e.g., Company and Department).

6. Dependency

Usage relationship where one class depends on another for its implementation (e.g., method parameters, static calls).

Design Patterns Overview

1. Factory Method

Intent: Define an interface for creating objects, letting subclasses decide which class to instantiate.

Applicability: When a class does not know the concrete product it must create, or when creation should be delegated to subclasses.

2. Abstract Factory

Intent: Provide an interface for creating families of related objects without specifying their concrete classes.

Applicability: When a system must be independent of how its products are created, composed, and represented.

3. Builder

Intent: Separate the construction of a complex object from its representation, allowing the same construction process to create different representations.

Applicability: When the algorithm for creating a complex object should be independent of its parts and assembly.

4. Prototype

Intent: Specify the kinds of objects to create using a prototypical instance and clone it to produce new objects.

Applicability: When instances are created at runtime based on dynamic loading or when cloning is more efficient than instantiation.

5. Singleton

Intent: Ensure a class has only one instance and provide a global access point to it.

Applicability: When exactly one instance is needed and it must be accessible throughout the application.

6. Adapter (Class/Object)

Intent: Convert the interface of a class into another interface clients expect.

Applicability: When you need to use an existing class whose interface does not match the required one.

7. Bridge

Intent: Decouple an abstraction from its implementation so that the two can vary independently.

Applicability: When you want to avoid a permanent binding between abstraction and implementation, allowing them to evolve separately.

8. Composite

Intent: Compose objects into tree structures to represent part‑whole hierarchies, allowing clients to treat individual objects and compositions uniformly.

Applicability: When you need to represent hierarchical structures and want uniform treatment of leaves and composites.

9. Decorator

Intent: Dynamically add responsibilities to objects without affecting other objects.

Applicability: When you want to extend functionality transparently and avoid subclass explosion.

10. Facade

Intent: Provide a unified interface to a set of interfaces in a subsystem, making it easier to use.

Applicability: When a complex subsystem needs a simple entry point for most clients.

11. Flyweight

Intent: Use sharing to support large numbers of fine‑grained objects efficiently.

Applicability: When an application uses many objects that share common intrinsic state.

12. Proxy

Intent: Provide a surrogate or placeholder for another object to control access.

Applicability: When you need a more general or complex object pointer, remote access, lazy loading, or access protection.

13. Interpreter

Intent: Define a representation for a grammar and an interpreter that uses the representation to interpret sentences.

Applicability: When a language needs to be interpreted and can be represented as an abstract syntax tree.

14. Template Method

Intent: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.

Applicability: When you want to implement invariant parts of an algorithm once and allow subclasses to customize behavior.

15. Chain of Responsibility

Intent: Give more than one object a chance to handle a request, avoiding coupling the sender to a specific receiver.

Applicability: When multiple objects can handle a request and the handler should be selected at runtime.

16. Command

Intent: Encapsulate a request as an object, allowing parameterization, queuing, logging, and undoable operations.

Applicability: When you need to decouple objects that produce commands from those that execute them.

17. Iterator

Intent: Provide a way to access elements of an aggregate object sequentially without exposing its underlying representation.

Applicability: When you need to traverse a collection without exposing its internal structure.

18. Mediator

Intent: Define an object that encapsulates how a set of objects interact, promoting loose coupling.

Applicability: When a set of objects communicate in complex ways, making the dependencies hard to understand.

19. Memento

Intent: Capture and externalize an object’s internal state so it can be restored later without violating encapsulation.

Applicability: When you need to restore an object to a previous state.

20. Observer

Intent: Define a one‑to‑many dependency so that when one object changes state, all its dependents are notified and updated automatically.

Applicability: When a change to one object requires notifying and updating many other objects.

21. State

Intent: Allow an object to alter its behavior when its internal state changes.

Applicability: When an object’s behavior depends on its state and must change at runtime.

22. Strategy

Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable.

Applicability: When you need to select an algorithm’s variant at runtime or avoid exposing complex algorithmic details.

23. Visitor

Intent: Represent an operation to be performed on elements of an object structure without changing the classes of the elements.

Applicability: When you need to define new operations on a set of objects without modifying their classes.