class PaymentProcessor {
   public void processPayment(String type) {
       if (type.equals("CreditCard")) {
           System.out.println("Processing credit card payment...");
       } else if (type.equals("PayPal")) {
           System.out.println("Processing PayPal payment...");
       }
   }
}

Refactored Code (With OCP):

interface Payment {
   void pay();
}
class CreditCardPayment implements Payment {
   public void pay() {
       System.out.println("Processing credit card payment...");
   }
}
class PayPalPayment implements Payment {
   public void pay() {
       System.out.println("Processing PayPal payment...");
   }
}
class PaymentProcessor {
   public void processPayment(Payment payment) {
       payment.pay();
   }
}

3. Liskov Substitution Principle (LSP)

Meaning:

Derived classes should be substitutable for their base classes without affecting the correctness of the program.

Key Points:

• Avoids using subclasses that break the functionality of a base class.
• Helps ensure the "is-a" relationship is maintained.

Use Case:

A shape drawing application that works for both circles and squares.

Real-Time Complex Example:

A class hierarchy where a subclass doesn't override behavior that contradicts the base class.

Code Example (Violation of LSP):

class Rectangle {
   int width, height;
   public void setWidth(int width) {
       this.width = width;
   }
   public void setHeight(int height) {
       this.height = height;
   }
   public int getArea() {
       return width * height;
   }
}
class Square extends Rectangle {
   @Override
   public void setWidth(int width) {
       super.setWidth(width);
       super.setHeight(width);
   }
   @Override
   public void setHeight(int height) {
       super.setHeight(height);
       super.setWidth(height);
   }
}

Refactored Code (With LSP):

interface Shape {
   int getArea();
}
class Rectangle implements Shape {
   int width, height;
   public Rectangle(int width, int height) {
       this.width = width;
       this.height = height;
   }
   public int getArea() {
       return width * height;
   }
}
class Square implements Shape {
   int side;
   public Square(int side) {
       this.side = side;
   }
   public int getArea() {
       return side * side;
   }
}

4. Interface Segregation Principle (ISP)

Meaning:

A class should not be forced to implement interfaces it does not use.

Key Points:

• Split large interfaces into smaller, specific ones.
• Ensures only relevant methods are implemented.

Use Case:

A printer interface that segregates basic printing and advanced faxing/scanning functionalities.

Real-Time Complex Example:

A multifunctional printer (MFP) where some models don't support scanning or faxing.

Code Example (Without ISP):

interface Printer {
   void print();
   void scan();
   void fax();
}
class BasicPrinter implements Printer {
   public void print() {
       System.out.println("Printing...");
   }
   public void scan() {
       throw new UnsupportedOperationException("Scan not supported");
   }
   public void fax() {
       throw new UnsupportedOperationException("Fax not supported");
   }
}

Refactored Code (With ISP):

interface Print {
   void print();
}
interface Scan {
   void scan();
}
interface Fax {
   void fax();
}
class BasicPrinter implements Print {
   public void print() {
       System.out.println("Printing...");
   }
}
class MultiFunctionPrinter implements Print, Scan, Fax {
   public void print() {
       System.out.println("Printing...");
   }
   public void scan() {
       System.out.println("Scanning...");
   }
   public void fax() {
       System.out.println("Faxing...");
   }
}

5. Dependency Inversion Principle (DIP)

Meaning:

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Key Points:

• Increases modularity and flexibility.
• Dependency injection is a common implementation.

Use Case:

A notification system where the high-level module doesn't depend on specific email or SMS classes.

Real-Time Complex Example:

Switching from email notifications to SMS notifications without changing the core business logic.

Code Example (Without DIP):

class EmailService {
   public void sendEmail(String message) {
       System.out.println("Sending email: " + message);
   }
}
class NotificationManager {
   private EmailService emailService;
   public NotificationManager() {
       this.emailService = new EmailService();
   }
   public void notify(String message) {
       emailService.sendEmail(message);
   }
}

Refactored Code (With DIP):

interface NotificationService {
   void notify(String message);
}
class EmailService implements NotificationService {
   public void notify(String message) {
       System.out.println("Sending email: " + message);
   }
}
class SMSService implements NotificationService {
   public void notify(String message) {
       System.out.println("Sending SMS: " + message);
   }
}
class NotificationManager {
   private NotificationService notificationService;
   public NotificationManager(NotificationService notificationService) {
       this.notificationService = notificationService;
   }
   public void notify(String message) {
       notificationService.notify(message);
   }
}

1. Single Responsibility Principle (SRP)

Each class or module in the game should do only one thing.

Examples:

1. PlayerManager: Handles player stats like health, score, and inventory.
2. EnemySpawner: Handles spawning enemies at specific intervals or locations.
3. SoundManager: Plays background music or sound effects.
4. CollisionHandler: Manages collision detection between game objects (e.g., player and enemy).

2. Open-Closed Principle (OCP)

The game should be easy to expand without modifying existing code.

Examples:

1. Adding new weapons: Add a new weapon class (e.g., LaserGun) without changing the base Weapon code.
2. Adding new enemy types: Introduce a new enemy (e.g., FlyingEnemy) by extending a base Enemy class.
3. Adding new power-ups: Add a new power-up (e.g., ShieldPowerUp) without touching existing power-ups.
4. Adding new levels: Create a new Level class with unique features without altering the LevelManager.

3. Liskov Substitution Principle (LSP)

You should be able to replace one class with its subclass without breaking the game.

Examples:

1. A FlyingEnemy should behave like a regular Enemy when added to the enemy list.
2. A BossEnemy should fit anywhere a normal Enemy is expected but with advanced behaviors.
3. A PlayerControlledCar should behave like a Vehicle in a racing game.
4. A MagicBullet should work like a Bullet but with added effects (e.g., area damage).

4. Interface Segregation Principle (ISP)

Game objects should only implement methods they actually use.

Examples:

1. A PlayerCharacter implements Move() and Attack(), but not Fly() if the player can’t fly.
2. A FlyingEnemy implements Fly() but not Swim() since it never swims.
3. A NPCVendor implements Talk() and Trade(), but not Attack().
4. A StaticObstacle (e.g., a wall) doesn’t need Move() or Attack(), only Collide().

5. Dependency Inversion Principle (DIP)

High-level game systems should rely on abstractions, not specific implementations.

Examples:

1. WeaponSystem depends on a generic Weapon interface, so it works with Sword, Gun, or Bow.
2. EnemyAI depends on an MovementStrategy interface, allowing different movement behaviors (e.g., Zigzag, Random).
3. GameNotification depends on a NotificationService interface, so it can use EmailService, InGamePopup, or PushNotification.
4. SoundManager uses an AudioOutput interface, so it works with headphones, speakers, or virtual sound systems.

Thank You for Your Support! 🙏

Your encouragement keeps us going!

If you find value in our content, please consider supporting us.

💡 Even a small contribution can make a big difference in helping us build better educational resources.

Donate Now