DEV Community: Ahad Ali

Master SOLID Principles Easily – The Only Guide You’ll Ever Need!

Ahad Ali — Tue, 06 May 2025 17:32:57 +0000

Before moving into the DRY principle, let's understand the goals of a good programmer:

Solving Problems
Writing Amazing Code
1. Maintainsability
2. Simplicity
3. Cleanliness
Optimization

🤔 Why write clean, simple, and maintainable code?

Because you're writing code for people — not just machines.

Your team members need to understand your code.
When you return to your own code months later, it should still make sense.

Clean code = Better teamwork + Fewer bugs + Easier updates

❓ Is there a standard way to write clean code?

Yes! Here are some principles:

DRY (Don't Repeat Yourself)
KISS (Keep It Simple, Stupid)
YAGNI (You Aren’t Gonna Need It)
SOLID (5 key principles for object-oriented programming)

🧱 What is SOLID?

SOLID is a set of five design principles that make your code:

Easy to read
Easy to maintain
Easy to scale and extend

These principles were introduced by Robert C. Martin (Uncle Bob) in the early 2000s, and have become a cornerstone of clean software architecture.

💁‍♂️ What Does SOLID Stand For?

S – Single Responsibility Principle
O – Open/Closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

We'll explore each of these with real-world examples and simple code.

Let’s get started! 🚀

S: Single Responsibility Principle (SRP)

A class should have only one reason to change.

This means every class should have only one responsibility or one job.

✅ Why is SRP Important?

When a class has just one task, it:

Becomes easier to understand
Is more maintainable
Contains fewer bugs
Can be updated or modified without affecting unrelated features

On the other hand, if a class has multiple responsibilities, it:

Becomes confusing
Is harder to debug
Increases risk when making changes

❌ Violating SRP (Bad Design)

Imagine a baker in a bakery.

If that one baker is responsible for:

Baking bread
Managing inventory
Cleaning the bakery

Then their focus is split, and none of the tasks are done with high quality.

class Baker {
public:
    void bakeBread() {
        cout << "Baking bread..." << endl;
    }

    void manageInventory() {
        cout << "Managing inventory..." << endl;
    }

    void cleanBakery() {
        cout << "Cleaning the bakery..." << endl;
    }
};

int main() {
    Baker baker;
    baker.bakeBread();
    baker.manageInventory();
    baker.cleanBakery();
}

Here, the Baker class has 3 responsibilities.
So if we want to change the cleaning process, the Baker class must be modified — even though it's not related to baking!

✅ Follows SRP (Good Design)

Imagine a baker in a bakery.

If that one baker is responsible for:

Baking bread

Then their focus is on a single task, and they will perform that task with high quality.

class BreadBaker {
public:
    void bakeBread() {
        cout << "Baking bread..." << endl;
    }
};

class InventoryManager {
public:
    void manageInventory() {
        cout << "Managing inventory..." << endl;
    }
};

class BakeryCleaner {
public:
    void cleanBakery() {
        cout << "Cleaning the bakery..." << endl;
    }
};

int main() {
    BreadBaker baker;
    baker.bakeBread();

    InventoryManager manager;
    manager.manageInventory();

    BakeryCleaner cleaner;
    cleaner.cleanBakery();
}

Now:

Each class now has a single responsibility:
- BreadBaker only bakes bread
- InventoryManager only manages inventory
- BakeryCleaner only cleans
If we want to change how inventory is managed, we only update the InventoryManager class.
The code is clean, modular, and easy to maintain.

O: Open/Closed Principle (OCP)

Software entities like classes, modules, and functions should be open for extension but closed for modification.

This means you can add new features by extending existing code, but you should not modify the already working code.

✅ Why is OCP Important?

Prevents breaking existing code
Encourages reusable components
Improves code maintainability

❌ Violating OCP (Bad Design)

Imagine we have a Shape class and we defined Circle and Rectangle. Now imagine if a new shape (like Triangle) is introduced — we will have to modify the existing class, which violates the Open/Closed Principle.

class Shape {
public:
    string type;

    double calculateArea() {
        if (type == "circle") {
            // calculate circle area
            return 3.14 * 5 * 5; // assume radius = 5
        }
        else if (type == "rectangle") {
            // calculate rectangle area
            return 10 * 20; // assume width = 10, height = 20
        }
    }
};

int main() {
    Shape shape;
    shape.type = "circle";
    cout << shape.calculateArea();
}

This class is not closed for modification — every time we add a new shape like triangle, we must edit the Shape class.
This makes the code fragile and harder to maintain.
It violates OCP, because the class is not extensible without changing existing code.

✅ Follows OCP (Good Design)

Let’s fix this using inheritance and polymorphism - we extend functionality without touching the base class.

class Shape {
public:
    virtual double calculateArea() = 0;
};

class Circle : public Shape {
public:
    double radius;
    Circle(double r) : radius(r) {}

    double calculateArea() override {
        return 3.14 * radius * radius;
    }
};

class Rectangle : public Shape {
public:
    double width, height;
    Rectangle(double w, double h) : width(w), height(h) {}

    double calculateArea() override {
        return width * height;
    }
};

int main() {
    Shape* shape1 = new Circle(5);
    cout << "Circle Area: " << shape1->calculateArea() << endl;

    Shape* shape2 = new Rectangle(10, 20);
    cout << "Rectangle Area: " << shape2->calculateArea() << endl;

    delete shape1;
    delete shape2;
}

Now the Shape class is closed for modification but open for extension.
We can add new shapes (like Triangle, Square, etc.) by just creating new classes that implement calculateArea().
This approach follows the Open/Closed Principle:
- Open for extension ✅
- Closed for modification ✅

L: Liskov Substitution Principle (LSP)

Introduced by Barbara Liskov in 1987

"Objects of a superclass should be replaceable with objects of its subclasses without breaking the application."

🧠 What it Means

If Class B is a subclass of Class A, then we should be able to use B wherever we use A without altering the correctness of the program.

✅ A subclass must respect the behavior of its parent.
❌ If a subclass breaks the behavior expected from the parent, it violates LSP.

✅ Why is LSP Important?

Ensures reliability when using polymorphism.
Avoids unexpected behaviors in subclass implementation.

❌ Violating LSP (Bad Design)

Imagine a base class Vehicle with a method startEngine(). Now we have two subclasses: Car and Bicycle.

class Vehicle {
public:
    virtual void startEngine() {
        cout << "Engine started!" << endl;
    }
};

class Car : public Vehicle {
public:
    void startEngine() override {
        cout << "Car engine started!" << endl;
    }
};

class Bicycle : public Vehicle {
public:
    void startEngine() override {
        // But bicycles don't have engines!
        // This leads to misleading behavior or unnecessary implementation
        throw logic_error("Bicycles don't have engines!");
    }
};

int main() {
    Vehicle* v1 = new Car();
    v1->startEngine(); // ✅ Fine

    Vehicle* v2 = new Bicycle();
    v2->startEngine(); // ❌ Throws error — Violates LSP

    delete v1;
    delete v2;
}

The Bicycle class inherits startEngine(), which it should not because bicycles don’t have engines.
This forces Bicycle to implement a method it logically doesn’t need.
Breaks LSP: Subclass Bicycle cannot fully substitute Vehicle.

✅ Follows LSP (Good Design)

Split responsibilities — create separate hierarchies for engine and non-engine vehicles.

class Vehicle {
public:
    virtual void move() = 0;
};

class EngineVehicle : public Vehicle {
public:
    virtual void startEngine() = 0;
};

class NonEngineVehicle : public Vehicle {
    // No startEngine() here
};

class Car : public EngineVehicle {
public:
    void startEngine() override {
        cout << "Car engine started!" << endl;
    }

    void move() override {
        cout << "Car is moving!" << endl;
    }
};

class Bicycle : public NonEngineVehicle {
public:
    void move() override {
        cout << "Bicycle is moving!" << endl;
    }
};

int main() {
    EngineVehicle* car = new Car();
    car->startEngine();  // ✅ Valid
    car->move();

    NonEngineVehicle* bicycle = new Bicycle();
    bicycle->move();     // ✅ No engine needed

    delete car;
    delete bicycle;
}

Now, no subclass is forced to implement irrelevant methods.
Each subclass respects the behavior expected from its parent.
LSP is satisfied — you can replace any parent type with its subclass without breaking the system.

I: Interface Segregation Principle (ISP)

Applicable to interfaces rather than classes.

Segregates interfaces based on functionality.

Do not force any client to implement an interface that is not relevant to them.

🧠 Why is ISP Important?

Reduces unnecessary dependencies.
Simplifies implementation for specific use cases.
Ensures that classes only implement the methods they actually need, leading to more efficient and maintainable code.

❌ Violating ISP (Bad Design)

Imagine a Machine interface that has three methods: print(), scan(), and fax(). Now, if we have a BasicPrinter class, it is forced to implement methods like scan() and fax(), even though they are not relevant to a basic printer.

interface Machine {
    void print();
    void scan();
    void fax();
}

class AllInOnePrinter : public Machine {
public:
    void print() override {
        // Implement printing
    }
    void scan() override {
        // Implement scanning
    }
    void fax() override {
        // Implement faxing
    }
};

class BasicPrinter : public Machine {
public:
    void print() override {
        // Implement printing
    }

    void scan() override {
        // Can't scan, so we throw an error or leave it empty
    }

    void fax() override {
        // Can't fax, so we throw an error or leave it empty
    }
};

The BasicPrinter class has to implement scan() and fax(), even though it doesn't need them.
This design flaw makes the code less flexible and harder to extend.
If new functionality is added to the Machine interface, every class that implements it needs to implement the new methods — even if they don't need them.

✅ Adhering to ISP (Good Design)

To follow the Interface Segregation Principle, we split the Machine interface into smaller, more focused interfaces, so classes only implement the methods they need.

interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

interface FaxMachine {
    void fax();
}

class BasicPrinter : public Printer {
public:
    void print() override {
        // Implement printing
    }
};

class AllInOnePrinter : public Printer, public Scanner, public FaxMachine {
public:
    void print() override {
        // Implement printing
    }
    void scan() override {
        // Implement scanning
    }
    void fax() override {
        // Implement faxing
    }
};

This design follows the principle of "interface cohesion": Each interface has a specific responsibility, which leads to better cohesion and separation of concerns.
Now, the BasicPrinter only implements Printer, and the AllInOnePrinter implements Printer, Scanner, and FaxMachine — only the relevant methods.
The result is a more robust, flexible, and maintainable system.

D: Dependency Inversion Principle (DIP)

Depend on abstractions, not on concrete classes.

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

Both should depend on abstractions (e.g., interfaces or abstract classes).

Abstractions should not depend on details.

Details should depend on abstractions.

🧠 What DIP Means

Classes should depend on abstractions, not on concrete classes.

❌ Bad: High-level modules directly use concrete implementations.
✅ Good: High-level modules use interfaces, and low-level modules implement those interfaces.

✅ Why is DIP Important?

Promotes decoupled architecture
Makes the system easier to test
Facilitates changes and scalability
Improves flexibility and maintainability

❌ Violating DIP (Bad Design)

Imagine an OrderService that directly creates and uses an EmailNotifier. This makes it tightly dependent on a specific notification method.

class EmailNotifier {
public:
    void sendEmail() {
        cout << "Sending Email\n";
    }
};

class OrderService {
    EmailNotifier notifier;

public:
    void placeOrder() {
        // Directly using concrete class
        notifier.sendEmail();
    }
};

int main() {
    OrderService order;
    order.placeOrder();  // ❌ Tightly coupled
}

OrderService is tightly coupled with EmailNotifier.
Cannot switch to SMS or other notifications easily.

✅ Following DIP (Good Design)

To fix this, we introduce a Notifier interface. Now OrderService depends on an abstraction, making it flexible and decoupled from concrete implementations.

// Abstraction
class Notifier {
public:
    virtual void send() = 0;
};

// Concrete implementations
class EmailNotifier : public Notifier {
public:
    void send() override {
        cout << "Sending Email\n";
    }
};

class SMSNotifier : public Notifier {
public:
    void send() override {
        cout << "Sending SMS\n";
    }
};

// Depends on abstraction
class OrderService {
    Notifier* notifier;

public:
    OrderService(Notifier* n) : notifier(n) {}

    void placeOrder() {
        notifier->send();  // ✅ Uses interface, not concrete class
    }
};

int main() {
    EmailNotifier email;
    OrderService order(&email);
    order.placeOrder();
}

OrderService works with any Notifier (Email, SMS, Push, etc.).
Loosely coupled and easy to test or extend.

💬 Thank you for reading!

If you found it valuable, hit a like ❤️ and share it with others!

Got questions or suggestions?

Drop a comment — I’d love to hear from you! 🙌

The YAGNI Principle

Ahad Ali — Tue, 29 Apr 2025 17:42:56 +0000

Before moving into the DRY principle, let's understand the goals of a good programmer:

Solving Problems
Writing Amazing Code
1. Maintainsability
2. Simplicity
3. Cleanliness
Optimization

Why write clean, simple, and maintainable code?

You're writing for humans.

Whether it's for a team.
When you revisit your code 6 months later, it must be understandable by you.

Is there a standard way to write clean code?

Yes! Here are some principles:

DRY
KISS
YAGNI
SOLID

We often want our code to handle every imaginable situation or future feature.

However, this mindset leads to bloated code, wasted time, and unnecessary complexity.

This is where YAGNI comes to the rescue.

Let's Deep Dive...

In this article, we will cover:

What is YAGNI?
Common Pitfalls of Ignoring it
Why is it Important?
How to Apply it?
When Not to Use it?
Disadvantages of YAGNI

What is YAGNI?

Only build something when you really need it - not just because you think you might need it later.

The YAGNI principle is a core concept in software development, especially within agile methodologies.

It simply means:

Focus on what’s needed right now.
Don’t waste time adding features you might need "someday" but aren't required today.

Example Codes: Non-DRY vs DRY

Non-YAGNI (Violating YAGNI)

class PaymentProcessor {
private:
    std::string paymentMethod;

public:
    PaymentProcessor(std::string method) : paymentMethod(method) {}

    void processPayment(double amount) {
        if (paymentMethod == "CreditCard") {
            std::cout << "Processing payment of $" << amount << " via Credit Card." << std::endl;
        } else if (paymentMethod == "DebitCard") {
            std::cout << "Processing payment of $" << amount << " via Debit Card." << std::endl;
        } else if (paymentMethod == "PayPal") {
            // Unnecessary feature
            std::cout << "Processing payment of $" << amount << " via PayPal." << std::endl;
        } else if (paymentMethod == "Crypto") {
            // Unnecessary feature
            std::cout << "Processing payment of $" << amount << " via Cryptocurrency." << std::endl;
        } else {
            std::cout << "Payment method not supported." << std::endl;
        }
    }
};

int main() {
    PaymentProcessor processor("CreditCard");
    processor.processPayment(100);

    PaymentProcessor invalidProcessor("PayPal");
    invalidProcessor.processPayment(58);
}

Adds unnecessary features (PayPal and Crypto) not requested.
Wastes development time on irrelevant features.
Increases complexity of the codebase.
Risk of disqualification in interviews by violating YAGN

🛑 Always implement functionality exactly as requested in interviews to avoid breaking YAGNI and risking disqualification!

YAGNI (Adhering to YAGNI)

class PaymentProcessor {
private:
    std::string paymentMethod;

public:
    PaymentProcessor(std::string method) : paymentMethod(method) {}

    void processPayment(double amount) {
        if (paymentMethod == "CreditCard") {
            std::cout << "Processing payment of $" << amount << " via Credit Card." << std::endl;
        } else if (paymentMethod == "DebitCard") {
            std::cout << "Processing payment of $" << amount << " via Debit Card." << std::endl;
        } else {
            std::cout << "Payment method not supported." << std::endl;
        }
    }
};

int main() {
    PaymentProcessor processor("CreditCard");
    processor.processPayment(100);
}

Meets the interviewer's requirements.
Keeps the code simple and focused.
Demonstrates good understanding of the YAGNI principle.

Common Pitfalls of Ignoring it

Excessive complexity: Code bloats with unused features.
Wasted time and resources: Building unnecessary functionality.
Harder maintenance: More bugs and difficulty understanding the codebase.

Why is it Important?

YAGNI prevents overengineering, keeping developers focused on what's truly needed.

Simplicity: A leaner and clearer codebase.
Faster development: Time isn't wasted building unneeded features.
Easier maintenance: Fewer features mean fewer places for bugs to hide.

YAGNI also:

Reduces project timelines.
Lowers technical debt.
Boosts team productivity.

How to Apply it?

Gather necessary requirements: Understand what is truly needed.
Communicate with your team: Stay aligned on project goals.
Plan simply: Solve only today's problem.
Reject unnecessary features: If not needed now, don't build it.
Track progress: Keep the solution lean throughout development.

Related Concepts

KISS Principle (Keep It Simple, Stupid): Encourages simplicity in design and code.
DRY Principle (Don't Repeat Yourself): Encourages reducing duplication in code and logic.

Both articles are available on my profile - feel free to check them out for detailed explanations!

Disadvantages of KISS

Limited Flexibility: Simplified designs may struggle to accommodate future changes or scalability.
Potential Oversimplification: Striving for simplicity can cause missing critical edge cases or important features.
Misinterpretation of Simplicity: Equating simplicity with fewer lines can compromise readability.
Resistance to Innovation: Excessive focus on simplicity may discourage using better frameworks or performance improvements.

The KISS Principle is a powerful guide to maintain simplicity in codebases.

By embracing the KISS principle, we ensure that our code remains readable, maintainable, and error-free.

Although it's essential to strike a balance between simplicity and functionality, adopting a simple approach generally leads to faster development cycles and more efficient problem-solving.

💬 Did you find this useful?

If this article helped you, feel free to like and share!

Have any questions or ideas?

Leave a comment below — I'd love to hear from you! 🙌

The KISS Principle

Ahad Ali — Tue, 29 Apr 2025 00:54:00 +0000

Before moving into the DRY principle, let's understand the goals of a good programmer:

Solving Problems
Writing Amazing Code
1. Maintainsability
2. Simplicity
3. Cleanliness
Optimization

Why write clean, simple, and maintainable code?

You're writing for humans.

Whether it's for a team.
When you revisit your code 6 months later, it must be understandable by you.

Is there a standard way to write clean code?

Yes! Here are some principles:

DRY
KISS
YAGNI
SOLID

As developers, we understand that complexity can often impede progress.

Simplicity is essential for effective development. Among the various principles developers follow, the KISS Principle stands out as a guide for maintaining simplicity in our code.

Let's Deep Dive...

In this article, we will cover:

What is KISS?
Why is it Important?
How to Apply it?
When Not to Use it?
Disadvantages of DRY

What is KISS?

KISS stands for Keep It Simple, Stupid. It emphasizes the importance of keeping things simple in design and implementation. The idea is to avoid unnecessary complexity and focus on creating solutions that are easy to understand, efficient, and easy to maintain.

The KISS principle is all about simplicity in software development. It encourages creating software that is:

Easy to understand
Simple to modify
Easy to extend

Rather than making things complicated, the goal is to make your code straightforward and easy to work with.

Example codes: Non-KISS vs KISS

Non-KISS

class FactorialCalculator {
public:
    int factorial(int n) {
        if (n == 0) return 1; // Base case
        int fact = 1;
        for (int i = 1; i < n; i++) {
            int temp = 1; // Temporary variable to store intermediate results
            for (int j = 1; j <= i; j++) {
                temp = j; // Multiplying repeatedly in nested loops
                fact = temp; // Reassigning fact unnecessarily
            }
        }
        return fact;
    }
};

This code violates the KISS principle by introducing unnecessary loops and a temporary variable.

KISS:

class FactorialCalculator {
public:
    static int factorial(int n) {
        int fact = 1;
        for (int i = 1; i <= n; i++) {
            fact *= i; // Directly calculating factorial in one loop
        }
        return fact;
    }

    static void main() {
        int result = factorial(5);
        cout << "Factorial: " << result << endl; // Output: Factorial: 120
    }
};

This code version simplifies the logic and improves readability by directly calculating the factorial in a single loop.

Why is it Important?

The KISS principle is important because it helps developers avoid the pitfalls of over-engineering and premature optimization.

Enhanced Readability: Simple code is easier for developers to read, understand, and review, even if they are new to the project.
Faster Debugging: Reducing complexity makes it easier to identify and resolve bugs or issues.
Improved Collaboration: A simpler codebase allows team members to work together more effectively.
Reduced Maintenance Costs: Simplified systems are easier to maintain, requiring less time and effort to implement changes or updates.
Quicker Development: With fewer moving parts and straightforward designs, development processes become more efficient.

How to Apply it?

Break Down Problems: Divide large problems into smaller, more manageable parts. This reduces complexity and makes individual components easier to understand.
Avoid Over-engineering: Don't add features or functionality that aren't currently required. Focus on solving the problem at hand.
Use Clear Naming Conventions: Choose meaningful names for variables, functions, and classes to make code self-explanatory.

Avoid

int x = 10;
int y = x * 10;

Better

int base_price = 10;
int total_price = base_price * 10;

Write Modular Code: Break code into small, single-purpose functions or modules. This adheres to the Single Responsibility Principle (SRP) and keeps each piece of functionality focused and simple.

Non-KISS

class OrderProcessor {
public:
    static double processOrder(Item order[], double taxRate) {
        double total = 0;
        for (Item item : order) {
            total += item.price * item.quantity;  // Calculate item totals
        }
        total *= taxRate;  // Add tax
        return total;
    }
};

Process order logic is combined into a single function

KISS

class OrderProcessor {
public:
    static double calculateSubtotal(Item order[]) {
        double subtotal = 0;
        for (Item item : order) {
            subtotal += item.price * item.quantity; // Calculate item totals
        }
        return subtotal;
    }

    static double calculateTotal(double subtotal, double taxRate) {
        return subtotal * taxRate; // Add tax to subtotal
    }
};

Split into different functions.

Disadvantages of KISS

Limited Flexibility: Simplified designs may struggle to accommodate future changes or scalability.
Potential Oversimplification: Striving for simplicity can lead to missing critical edge cases or ignoring necessary features.
Misinterpretation of Simplicity: Focusing on fewer lines of code can reduce clarity and readability.
Resistance to Innovation: Over-simplicity can prevent the adoption of advanced techniques or frameworks that optimize performance.

The KISS Principle serves as a valuable guide for developers to maintain clean, straightforward codebases.

By embracing the KISS principle, we ensure that our code remains remains readable, maintainable, and error-free. Although it's essential to strike a balance between simplicity and functionality, adopting a simple approach generally leads to faster development cycles and more efficient problem-solving.

💬 Did you find this useful?

If this article helped you, feel free to like and share!

Have any questions or ideas?

Leave a comment below — I'd love to hear from you! 🙌

The DRY Principle

Ahad Ali — Mon, 28 Apr 2025 14:37:01 +0000

Before moving into the DRY principle, let's understand the goals of a good programmer:

Solving Problems
Writing Amazing Code
1. Maintainsability
2. Simplicity
3. Cleanliness
Optimization

Why write clean, simple, and maintainable code?

You're writing for humans.

Whether it's for a team.
When you revisit your code 6 months later, it must be understandable by you.

Is there a standard way to write clean code?

Yes! Here are some principles:

DRY
KISS
YAGNI
SOLID

The DRY principle was introduced by Andy Hunt and Dave Thomas in their book "The Pragmatic Programmer".

Let's Deep Dive...

In this article, we will cover:

What is DRY?
Why is it Important?
How to Apply it?
When Not to Use it?
Disadvantages of DRY

What is DRY?

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

In simple terms, Don't Repeat Yourself (DRY) means we should avoid duplicating code, logic, or knowledge. Instead, put it in one place and reuse it!

The DRY principle encourages:

Modular code
Reusable code
Less repetitive code

Example Codes: Non-DRY vs DRY

Example 1: Avoiding Code Duplication (JavaScript)

Non-DRY:

function calculateElectronicTax(price) {
  return price * 0.18;
}

function calculateGroceryTax(price) {
  return price * 0.05;
}

function calculateClothingTax(price) {
  return price * 0.12;
}

We've written separate functions for each type of tax calculation, even though the logic is the same. Imagine doing this for 50 types - it gets messy!

DRY:

function calculateTax(price, taxRate) {
  return price * taxRate;
}

// Usage
const electronicsTax = calculateTax(1000, 0.18);
const groceryTax = calculateTax(500, 0.05);
const clothingTax = calculateTax(800, 0.12);

One reusable function - clean and scalable!

Example 2: Use Functions (C++)

Non-DRY:

void swapNumbersNonDry() {
    int a = 5, b = 10;
    int temp = a;
    a = b;
    b = temp;

    int x = 20, y = 30;
    temp = x;
    x = y;
    y = temp;
}

The swap logic is copied and pasted - not efficient!

DRY:

void swap(int &a, int &b) {
    int temp = a;
    a = b;
    b = temp;
}

int main() {
    int num1 = 5, num2 = 10;
    swap(num1, num2);
}

One reusable swap() function saves us time and effort.

Example 3: Object-Oriented Approach (C++)

Non-DRY:

#include <iostream>
using namespace std;

void submitButton() {
    cout << "Form submitted." << endl;
}

void cancelButton() {
    cout << "Action canceled." << endl;
}

int main() {
    submitButton();
    cancelButton();
}

Separate functions even though they perform similar tasks.

DRY (Using Classes):

#include <iostream>
using namespace std;

class Button {
public:
    virtual void onClick() = 0; // Abstract method
};

class SubmitButton : public Button {
public:
    void onClick() override {
        cout << "Form submitted." << endl;
    }
};

class CancelButton : public Button {
public:
    void onClick() override {
        cout << "Action canceled." << endl;
    }
};

int main() {
    SubmitButton submit;
    submit.onClick();

    CancelButton cancel;
    cancel.onClick();
}

The structure is reusable - adding new buttons becomes easier!

Example 4: Create Reusable Components (ReactJS)

Non-DRY:

function Header() {
  return <h1>My Website</h1>;
}

function Footer() {
  return <h1>My Website</h1>;
}

Same title repeated - not efficient.

DRY:

function Title({ text }) {
  return <h1>{text}</h1>;
}

function Header() {
  return <Title text="My Website" />;
}

function Footer() {
  return <Title text="My Website" />;
}

One reusable Title component - clean and flexible!

Example 5: Use Constants or Config Files

Non-DRY:

console.log("Connecting to http://example.com");

Imagine having to update this URL in 50 places — it becomes complicated!

DRY:

// .env file
BASE_URL=http://example.com

// usage
console.log(`Connecting to ${process.env.BASE_URL}`);

Change the URL once in the .env file instead of 50 places!

Why is it Important?

Efficiency: Reduces code size, saves time, and eliminates redundancy.
Maintainability: Updates and debugging are simpler with centralized changes.
Scalability: Modular code makes it easier to add new features.
Consistency: Ensures uniform behavior and reduces bugs.
Faster Development: Reusing code accelerates the development process.

How to Apply it?

Identify Repetitive Code: Look for patterns where the same logic appears again and again.
Extract Common Functionality: Move repeated code into functions, classes, or modules.
Use Inheritance and Composition: Create a hierarchy of classes or compose objects to avoid code duplication.
Leverage Libraries and Frameworks: Use libraries to save time, but avoid overuse.
Refactor Regularly: Keep reviewing and refactoring to remove duplication.

When Not to Use it?

Sometimes DRY is not the best choice:

Premature Abstraction: Don’t make things too reusable before you need them.
Performance-critical code: Duplication may improve performance in certain cases.
One-time usage: Abstracting code used once is unnecessary and time-consuming.
Readability issues: Over-abstracting can lead to confusing and harder-to-read code.
Legacy or Temporary code: Abstraction may not be worth it for code that is short-lived.
Debugging: Duplicated code can sometimes be easier to debug.

Disadvantages of DRY

Over-Abstraction: Making everything reusable too early can hurt readability and understanding.
Takes Time: Implementing DRY requires careful planning and time upfront.
Misuse: Incorrect application of DRY can create tightly coupled, hard-to-maintain code.
Hard Refactoring: DRY is difficult to apply in messy codebases and may complicate refactoring.

DRY (Don't Repeat Yourself) makes code readable, maintainable, and efficient.

However, use it wisely — too much abstraction is harmful. DRY works best when combined with good practices like SOLID principles.

By applying DRY thoughtfully, we create better, cleaner, and smarter software!

💬 Did you find this useful?

If this article helped you, feel free to like and share!

Have any questions or ideas?

Leave a comment below — I'd love to hear from you! 🙌

Basic Principles of Object-Oriented Programming (OOP)

Ahad Ali — Thu, 24 Apr 2025 10:16:57 +0000

OOP

Object-Oriented Programming (OOP) is a programming paradigm (way of writing code) that uses objects and classes to model real-world entities.

It’s widely adopted in modern software development due to its ability to create clean, reusable, and scalable code.

Learning OOP allows us to structure code in a way that mirrors real-world systems, making it easier to design and maintain complex applications.

Benefits of OOP

Modularity: Organizes code into self-contained units (objects) for easier understanding and maintenance.
Reusability: Once a class is written, it can be reused in different parts of the program or across projects.
Scalability: New features and objects can be easily added as the codebase grows.
Maintainability: Changes are easier to manage, and debugging becomes more efficient.
Real-world Modeling: Models real-world entities, making the code more intuitive and relatable.
Parallel Development: Enables team members to work on different objects or classes simultaneously.

In this article, I'll break down core OOP concepts with easy-to-understand code examples.

1. Classes & Objects

A class is like a blueprint or a recipe for creating objects. It defines what data and behavior the objects will have. An object is an instance of a class, created using the class definition.

🧠 Think of a class as a car design, and an object as an actual car made using that design.

Here's an example of a class definition in C++:

class Car {
public:
    string brand;
    int year;

    void displayInfo() {
        cout << "Brand: " << brand << ", Year: " << year << endl;
    }
};

In this example, Car is a class - a blueprint that defines the properties and behavior of the class.

The class itself doesn’t hold any real data. It just outlines what an object of this type will look like and how it will behave.

Car toyotaCar;
toyotaCar.brand = "Toyota";
toyotaCar.year = 2023;
toyotaCar.displayInfo();

Car hondaCar;
hondaCar.brand = "Honda";
hondaCar.year = 2022;
hondaCar.displayInfo();

Here, toyotaCar and hondaCar are objects or instances of the Car class. They hold specific data and can invoke the same behavior. This demonstrates how OOP allows for reusable, modular code.

An object turns the blueprint into something real - it holds actual data and can perform actions.

2. Encapsulation

Encapsulation is the process of bundling data and methods that operate on that data within a class, while restricting direct access to some of the object's components. It ensures that data is accessed only through defined interfaces, protecting it from external interference and misuse.

In simple terms, encapsulation allows us to hide the internal state of an object and expose only what is necessary for its operation.

In C++, we can achieve encapsulation using access specifiers.

class BankAccount {
private:
    double balance;

public:
    void deposit(double amount) {
        if (amount > 0) balance += amount;
    }

    void displayBalance() {
        cout << "Balance: $" << balance << endl;
    }
};

int main() {
    BankAccount account;
    account.deposit(500);
    account.displayBalance();
}

Here, the BankAccount class represents a bank account with a private data member balance. This means that the balance cannot be accessed or modified directly from outside the class.

We interact with the balance using public methods like deposit and displayBalance.

3. Inheritance

Inheritance allows one class (child class) to inherit features (methods and properties) from another class (parent class).

The class that inherits is called the child class (or derived class), and the class being inherited from is called the parent class.

The child class inherits all the fields and methods of the parent class and can also add new fields and methods or override the ones inherited from the parent class.

This enables code reuse, makes the codebase DRY (Don't Repeat Yourself), and supports hierarchical classification.

Let’s say we have a parent Animal class with a method named speak().

class Animal {
public:
    void speak() {
        cout << "Animal speaks" << endl;
    }
};

class Dog : public Animal {
public:
    void bark() {
        cout << "Dog barks" << endl;
    }
};

int main() {
    Dog myDog;
    myDog.speak();  // Inherited from Animal
    myDog.bark();   // Defined in Dog
}

Here, the Dog class inherits from the Animal class, which means it can access the speak() method or any other attribute or method defined publicly or protected in the Animal class. The Dog class also adds its own attributes and methods, such as bark().

This demonstrates inheritance, where a subclass inherits properties and behaviors from its parent class while adding its own unique functionality.

4. Polymorphism

Polymorphism refers to the ability of a single method to behave differently depending on the object that invokes it.

It allows you to write flexible and reusable code that can work with objects of different types, as long as they implement a shared interface.

This behavior is commonly achieved through method overriding in inheritance.

Method overriding occurs when a subclass provides its own implementation of a method that is already defined in its parent class.

For instance, let’s consider an interface Animal with a method sound().

class Animal {
public:
    virtual void sound() {
        cout << "Animal makes a sound" << endl;
    }
};

class Cat : public Animal {
public:
    void sound() override {
        cout << "Cat meows" << endl;
    }
};

int main() {
    Animal* animal = new Cat();
    animal->sound();  // Outputs "Cat meows" due to polymorphism
    delete animal;
}

Here, the Animal class defines a virtual function sound(), which can be overridden by derived classes. Each subclass (such as Cat) of Animal implements the sound method differently (method overriding), but the interface remains consistent, allowing iteration over both classes using a single pointer.

This demonstrates polymorphism, where the method called depends on the actual object type, not the pointer type, enabling dynamic method binding at runtime.

5. Abstraction

Abstraction is the concept of hiding unnecessary details and showing only the relevant information. It's an extension of encapsulation, focusing more on the interface and less on the implementation.

Abstraction helps to simplify complex systems and focus on the essential features.

In C++, we can implement abstraction using abstract classes and pure virtual functions.

Let’s say we have an abstract base class called Shape. The Shape class is marked as an abstract class by inheriting from the ABC class (Abstract Base Class).

Inside the Shape class, we define an abstract method called draw().

class Shape {
public:
    virtual void draw() = 0; // Pure virtual function (abstract method)
};

class Circle : public Shape {
public:
    void draw() override {
        cout << "Drawing a Circle" << endl;
    }
};

int main() {
    Shape* shape = new Circle();
    shape->draw();
    delete shape;
}

Here, the Circle class inherits from the Shape class.

It provides its own implementation of the draw() method specific to itself. Note that the implementation details are hidden from the outside world, and only the interface defined by the abstract class is exposed.

This demonstrates how Abstraction hides the implementation details (like how a circle is drawn) and only exposes the method draw() that can be called on any Shape object.

These are the fundamental principles of Object-Oriented Programming.

Implementing these concepts will help you write cleaner, reusable, and maintainable code.

💬 Did you find this useful?

If this article helped you, feel free to like and share!

Have any questions or ideas?

Leave a comment below — I'd love to hear from you! 🙌