General

Question 1

SOLID Principles

Answer 1

1. Single Responsibility Principle (SRP)
2. Open close principle
3. Liskov substitution
4. Interface segregation principle
5. Dependency Inversion Principle (DIP)

Question 2

Single Responsibility Principle (SRP)

Answer 2

A class should only have one reason to change. A class should not have too many responsibility. That way you can easily separate class.

A single class is responsible for one thing and has one reason to change

Question 3

Open close principle

Answer 3

Classes should be open for extension but closed for modification.

GOOD
abstract class Discount {
abstract calculate(price: number): number;
}

class NoDiscount extends Discount {
calculate(price: number): number {
return price;
}
}

BAD
function applyDiscount(price: number, discountType: string) {
if (discountType === “none”) {
return price;
} else if (discountType === “blackFriday”) {
return price * 0.8;
}
}

Question 4

Liskov substitution

Answer 4

Subtypes should be replaceable for their base types without altering the correctness.

GOOD
class Bird {
fly() {
console.log(“Flying…”);
}
}

class Sparrow extends Bird {}

function makeBirdFly(bird: Bird) {
bird.fly();
}

makeBirdFly(new Sparrow()); // ✅ Works fine

BAD
class Bird {
fly() {
console.log(“Flying…”);
}
}

class Penguin extends Bird {
fly() {
throw new Error(“Penguins can’t fly!”);
}
}

Question 5

Interface segregation principle

Answer 5

Clients should not be forced to depend on interfaces they do not use.

BAD
interface Machine {
print(): void;
scan(): void;
}

class BasicPrinter implements Machine {
print() {
console.log(“Printing…”);
}

scan() {
throw new Error(“This printer can’t scan!”);
}
}

GOOD
interface Printer {
print(): void;
}

interface Scanner {
scan(): void;
}

class AllInOnePrinter implements Printer, Scanner {
print() {
console.log(“Printing…”);
}

scan() {
console.log(“Scanning…”);
}
}

Question 6

Dependency Inversion Principle (DIP)

Answer 6

The Dependency Inversion Principle is one of the five SOLID principles of object-oriented design. It states that:

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
This principle helps reduce coupling between software components and makes code more maintainable, testable, and flexible.