Design Patterns - Gang of Four & SOLID Principles Flashcards

Question 1

What are Design Patterns in software engineering?

Accepted Answer

Design Patterns are reusable solutions to common problems encountered during software design. They are not finished designs that can be directly transformed into code, but rather templates or descriptions for how to solve a problem that can be used in many different situations.

Question 2

What are the three main categories of Gang of Four (GoF) Design Patterns?

Accepted Answer

The three main categories of GoF Design Patterns are:
*   **Creational Patterns:** Deal with object creation mechanisms, trying to create objects in a manner suitable for the situation.
*   **Structural Patterns:** Deal with the composition of classes and objects, forming larger structures.
*   **Behavioral Patterns:** Deal with algorithms and the assignment of responsibilities between objects.

Question 3

Explain the **Singleton Pattern** and provide a common use case.

Accepted Answer

The `Singleton` pattern ensures that a class has only one instance and provides a global point of access to that instance.
**Use Case:** A logging utility, a configuration manager, or a database connection pool where only one instance is needed to manage a shared resource.
```java
public class Singleton {
    private static Singleton instance;
    private Singleton() {} // Private constructor
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
    public void showMessage() {
        System.out.println("Hello from Singleton!");
    }
}
```

Question 4

Describe the **Factory Method Pattern** and its purpose.

Accepted Answer

The `Factory Method` pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. It defers instantiation of an object to its subclasses.
**Purpose:** To create objects without specifying the exact class of object that will be created. This promotes loose coupling.
**Use Case:** A document editor that can create different types of documents (e.g., `WordDocument`, `PdfDocument`) based on user input, where each document type has its own factory.

Question 5

What is the **Abstract Factory Pattern**?

Accepted Answer

The `Abstract Factory` pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. It's a "factory of factories."
**Use Case:** A GUI toolkit that needs to create different sets of UI components (e.g., `Button`, `Checkbox`) for different operating systems (e.g., `WindowsFactory` creates `WindowsButton`, `MacOSFactory` creates `MacOSButton`).

Question 6

Explain the **Decorator Pattern** and give an example.

Accepted Answer

The `Decorator` pattern allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class. It wraps an object to provide new responsibilities.
**Example:** Adding logging, encryption, or compression functionality to a data stream (`FileInputStream` decorated with `BufferedInputStream` and `GZIPInputStream`).
```java
// Basic Coffee interface
interface Coffee {
    String getDescription();
    double getCost();
}
// Concrete Coffee
class SimpleCoffee implements Coffee {
    public String getDescription() { return "Simple Coffee"; }
    public double getCost() { return 2.0; }
}
// Decorator base
abstract class CoffeeDecorator implements Coffee {
    protected Coffee decoratedCoffee;
    public CoffeeDecorator(Coffee coffee) { this.decoratedCoffee = coffee; }
    public String getDescription() { return decoratedCoffee.getDescription(); }
    public double getCost() { return decoratedCoffee.getCost(); }
}
// Concrete Decorator
class MilkDecorator extends CoffeeDecorator {
    public MilkDecorator(Coffee coffee) { super(coffee); }
    public String getDescription() { return super.getDescription() + ", Milk"; }
    public double getCost() { return super.getCost() + 0.5; }
}
```

Question 7

What is the purpose of the **Adapter Pattern**?

Accepted Answer

The `Adapter` pattern allows objects with incompatible interfaces to collaborate. It acts as a wrapper between two objects, catching calls for one object and transforming them into a format recognizable by the second object.
**Use Case:** Integrating a new third-party library with an existing system that expects a different interface. For example, an old `SquarePeg` system needs to work with a new `RoundHole` system, so a `SquarePegAdapter` is created.

Question 8

Describe the **Composite Pattern** and its application.

Accepted Answer

The `Composite` pattern composes objects into tree structures to represent part-whole hierarchies. It allows clients to treat individual objects and compositions of objects uniformly.
**Application:** Representing file systems (files and directories), UI components (individual widgets and panels containing widgets), or organizational charts.
**Example:** A `Graphic` interface with `draw()` method. `Circle` and `Rectangle` implement `Graphic`. `CompositeGraphic` also implements `Graphic` and holds a collection of `Graphic` objects, allowing drawing of a group of shapes.

Question 9

Explain the **Observer Pattern** and its key components.

Accepted Answer

The `Observer` pattern defines a one-to-many dependency between objects so that when one object (the `Subject` or `Observable`) changes state, all its dependents (the `Observers`) are notified and updated automatically.
**Key Components:**
*   **Subject (Observable):** Maintains a list of observers, provides methods to attach/detach observers, and notifies them of state changes.
*   **Observer:** Defines an updating interface for objects that should be notified of changes in a subject.
**Use Case:** Event handling systems, stock market monitoring, MVC architecture (Model is Subject, View is Observer).

Question 10

What is the **Strategy Pattern** and when would you use it?

Accepted Answer

The `Strategy` pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It lets the algorithm vary independently from clients that use it.
**Use Case:** When you have multiple algorithms for a specific task and want to switch between them at runtime. Examples include different sorting algorithms, payment processing methods, or validation rules.
```java
interface PaymentStrategy {
    void pay(int amount);
}
class CreditCardPayment implements PaymentStrategy {
    public void pay(int amount) { /* ... */ }
}
class PayPalPayment implements PaymentStrategy {
    public void pay(int amount) { /* ... */ }
}
class ShoppingCart {
    private PaymentStrategy paymentMethod;
    public void setPaymentStrategy(PaymentStrategy strategy) { this.paymentMethod = strategy; }
    public void checkout(int amount) { paymentMethod.pay(amount); }
}
```

Question 11

What are the **SOLID Principles** in object-oriented design?

Accepted Answer

SOLID is an acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. They were promoted by Robert C. Martin (Uncle Bob).
*   **S**ingle Responsibility Principle
*   **O**pen/Closed Principle
*   **L**iskov Substitution Principle
*   **I**nterface Segregation Principle
*   **D**ependency Inversion Principle

Question 12

Explain the **Single Responsibility Principle (SRP)**.

Accepted Answer

The `Single Responsibility Principle` states that a class should have only one reason to change, meaning it should have only one job or responsibility.
**Example:** Instead of a `User` class handling user data, authentication, and logging, separate these concerns into `User`, `Authenticator`, and `Logger` classes.
```java
// Bad example: User class handles multiple responsibilities
class User {
    public void saveUser() { /* ... */ }
    public void sendEmail() { /* ... */ }
    public void generateReport() { /* ... */ }
}
// Good example: Separate responsibilities
class UserRepository {
    public void saveUser() { /* ... */ }
}
class EmailService {
    public void sendEmail() { /* ... */ }
}
class ReportGenerator {
    public void generateReport() { /* ... */ }
}
```

Question 13

Describe the **Open/Closed Principle (OCP)**.

Accepted Answer

The `Open/Closed Principle` states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. This means you should be able to add new functionality without changing existing, working code.
**Example:** Using interfaces or abstract classes. If you have a `Shape` interface and `Circle`, `Rectangle` classes, you can add a new `Triangle` class without modifying the existing `AreaCalculator` if it operates on the `Shape` interface.
```java
interface Shape {
    double area();
}
class Circle implements Shape { /* ... */ }
class Rectangle implements Shape { /* ... */ }
// AreaCalculator is closed for modification, open for extension (new shapes)
class AreaCalculator {
    public double calculateArea(Shape shape) {
        return shape.area();
    }
}
```

Question 14

What is the **Liskov Substitution Principle (LSP)**?

Accepted Answer

The `Liskov Substitution Principle` states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application. Subtypes must be substitutable for their base types.
**Example:** If you have a `Bird` class with a `fly()` method, and a `Penguin` subclass, the `Penguin` should not override `fly()` to do nothing or throw an error, as this violates the expectation of a `Bird` being able to fly. A better design might be an `IFlyable` interface.
```java
// Bad example (violates LSP if Penguin cannot fly)
class Bird {
    public void fly() { /* ... */ }
}
class Penguin extends Bird {
    @Override
    public void fly() { /* Penguins can't fly, this breaks expectation */ }
}
// Good example (using interfaces)
interface Flyable {
    void fly();
}
class Eagle implements Flyable {
    public void fly() { /* ... */ }
}
class PenguinBird { // No fly method, or a swim method
    public void swim() { /* ... */ }
}
```

Question 15

Explain the **Interface Segregation Principle (ISP)**.

Accepted Answer

The `Interface Segregation Principle` states that clients should not be forced to depend on interfaces they do not use. Rather than one large interface, many smaller, client-specific interfaces are better.
**Example:** Instead of a single `Worker` interface with `work()` and `eat()` methods, create `Workable` and `Eatable` interfaces. A `Robot` might implement only `Workable`, while a `HumanWorker` implements both.
```java
// Bad example: Fat interface
interface Worker {
    void work();
    void eat();
}
class HumanWorker implements Worker { /* ... */ }
class Robot implements Worker {
    public void work() { /* ... */ }
    public void eat() { /* Not applicable, forced to implement */ }
}
// Good example: Segregated interfaces
interface Workable {
    void work();
}
interface Eatable {
    void eat();
}
class HumanWorker implements Workable, Eatable { /* ... */ }
class Robot implements Workable {
    public void work() { /* ... */ }
}
```

Question 16

Describe the **Dependency Inversion Principle (DIP)**.

Accepted Answer

The `Dependency Inversion Principle` states that:
1.  High-level modules should not depend on low-level modules. Both should depend on abstractions.
2.  Abstractions should not depend on details. Details should depend on abstractions.
This means depending on interfaces or abstract classes rather than concrete implementations.
**Example:** A `Car` should depend on an `Engine` interface, not a concrete `PetrolEngine` class. This allows swapping engines (e.g., `ElectricEngine`) without modifying the `Car` class.
```java
// Bad example: High-level Car depends on low-level PetrolEngine
class PetrolEngine {
    public void start() { /* ... */ }
}
class Car {
    private PetrolEngine engine;
    public Car() {
        this.engine = new PetrolEngine(); // Direct dependency
    }
    public void start() { engine.start(); }
}
// Good example: Both depend on abstraction (Engine interface)
interface Engine {
    void start();
}
class PetrolEngine implements Engine { /* ... */ }
class ElectricEngine implements Engine { /* ... */ }
class Car {
    private Engine engine; // Depends on abstraction
    public Car(Engine engine) { // Dependency injected
        this.engine = engine;
    }
    public void start() { engine.start(); }
}
```

Question 17

What are the benefits of applying SOLID principles?

Accepted Answer

Applying SOLID principles leads to:
*   **Increased Maintainability:** Easier to understand, debug, and fix issues.
*   **Improved Flexibility & Extensibility:** Easier to add new features or change existing ones without breaking the system.
*   **Reduced Coupling:** Components are less dependent on each other, making them more independent and reusable.
*   **Enhanced Testability:** Loosely coupled components are easier to test in isolation.
*   **Better Code Readability:** Well-structured code that adheres to these principles is generally easier to read and comprehend.

Question 18

When should you consider using the **Strategy Pattern** over a series of `if-else` statements?

Accepted Answer

Use the `Strategy Pattern` when:
*   You have multiple related algorithms or behaviors that can be encapsulated into separate classes.
*   You want to switch between these algorithms at runtime.
*   You want to avoid large conditional statements (`if-else` or `switch-case`) that make code harder to maintain and extend (violates OCP).
*   You want to isolate the algorithm's implementation from the client code that uses it.

Question 19

How does the **Decorator Pattern** differ from inheritance?

Accepted Answer

*   **Decorator:** Adds responsibilities to objects dynamically at runtime. It uses composition (wraps the original object) and adheres to the Open/Closed Principle. It's flexible for adding multiple, independent behaviors.
*   **Inheritance:** Adds responsibilities to classes statically at compile time. It's a "is-a" relationship. While it can extend functionality, it can lead to a rigid class hierarchy, "class explosion" if many combinations of features are needed, and violates OCP if base class needs modification for new features.

Question 20

What is the primary goal of Creational Design Patterns?

Accepted Answer

The primary goal of Creational Design Patterns is to provide flexible and efficient ways to create objects. They abstract the instantiation process, making the system independent of how its objects are created, composed, and represented. This helps in managing object creation complexity and promoting loose coupling.

Question 21

What is the primary goal of Structural Design Patterns?

Accepted Answer

The primary goal of Structural Design Patterns is to simplify the structure of a system by identifying a simple way to realize relationships between entities. They deal with the composition of classes and objects, forming larger structures while maintaining flexibility and efficiency.

Question 22

What is the primary goal of Behavioral Design Patterns?

Accepted Answer

The primary goal of Behavioral Design Patterns is to identify common communication patterns between objects and realize these patterns. They are concerned with algorithms and the assignment of responsibilities between objects, making interactions more flexible and reusable.

Design Patterns - Gang of Four & SOLID Principles

Cards in this deck

Related Flashcard Sets

TypeScript - Advanced Type Systems, Generics & Design Patterns

Harvard ECON1011 - Intermediate Microeconomics: Game Theory & Market Structures

MIT 18.03 - Differential Equations: Ordinary Differential Equations, Laplace & Fourier

CPA Exam FAR - Financial Accounting & Reporting: US GAAP & Revenue Recognition