DEV Community: Kishan vyas

I Spent a Full Day Learning OOP in Python, Here's Everything, Explained Like You're 15

Kishan vyas — Thu, 26 Mar 2026 18:51:49 +0000

Okay real talk.

I used to see OOP code - with all its classes, self, super(), __dunder__ stuff - and immediately feel my brain shut down.

Today I finally sat down, refused to move until I understood it, and... it actually clicked.

So here's my attempt to explain everything I learned in the way I wish someone had explained it to me - with analogies, stories, and zero corporate jargon.

Grab a chai This is a long one. But I promise it's worth it.

What we're covering:

Encapsulation

Inheritance

Abstraction

Polymorphism

Descriptors (bonus brain-bender)

First, the 30 second version of "What even IS OOP?"

Imagine you're building a game. You have a Hero, a Dragon, a Sword.

You could write everything as a big list of instructions:

hero_name = "Arjun"
hero_health = 100
hero_attack = 25
dragon_health = 500
# ... 300 more variables later 😵

Or - you could bundle related data and behavior into objects:

hero = Hero(name="Arjun", health=100)
dragon = Dragon(health=500)
hero.attack(dragon)  # clean. readable. beautiful.

That's OOP. You model the world as things (objects) that have data (attributes) and can do stuff (methods).

Python has 4 pillars of OOP. Think of them as the 4 superpowers. Let's unlock them one by one.

Pillar 1: Encapsulation - "What happens in the class, stays in the class"

The analogy: Think of your phone. You tap icons and apps open. You don't need to know about the CPU, RAM allocation, or kernel calls happening underneath. The phone encapsulates all that complexity.

Encapsulation = bundling data + methods together, and controlling who can access what.

The Underscore Rules 🐍

Python doesn't have "hard" access control like Java. Instead, it uses a naming convention - think of it as a gentleman's agreement between developers:

class BankAccount:
    def __init__(self, owner, balance):
        self.owner = owner       # 🟢 PUBLIC - anyone can see/change this
        self._balance = balance  # 🟡 PROTECTED - "hey, please don't touch this from outside"
        self.__pin = 1234        # 🔴 PRIVATE - Python actually hides this one

Let's test what happens:

account = BankAccount("Arjun", 5000)

print(account.owner)       # "Arjun"
print(account._balance)    # Works... but you're breaking the rules
print(account.__pin)       # AttributeError! Where did it go??

# Python secretly renamed it 👀
print(account._BankAccount__pin)  # 1234 - name mangling revealed!

** Wait, why does Python bother hiding __pin if you can still access it with a longer name?**
Because it prevents accidental access and name collisions in subclasses - not to stop a determined hacker. Python trusts you to be an adult.

@property - The Pythonic Getter/Setter

In Java, you write getBalance() and setBalance(). In Python, we do it better:

class BankAccount:
    def __init__(self, balance):
        self._balance = balance

    @property
    def balance(self):             # called when you READ acc.balance
        return self._balance

    @balance.setter
    def balance(self, amount):     # called when you WRITE acc.balance = x
        if amount < 0:
            raise ValueError("Bro you can't have negative money 💀")
        self._balance = amount

acc = BankAccount(1000)
print(acc.balance)     # 1000  looks like attribute access, runs the getter
acc.balance = 2000     # looks like assignment, runs the setter
acc.balance = -500     # 💥 ValueError

It looks like you're accessing an attribute. You're secretly calling a method. That's elegant.

@classmethod vs @staticmethod - What's the difference?

This confuses everyone. Here's the mental model:

	Knows about...	Use when...
Regular method	`self` (instance)	Working with instance data
@classmethod	`cls` (the class itself)	Working with class-level data
@staticmethod	nothing	Utility function that belongs here logically

class Employee:
    company = "TechCorp"   # class variable - shared by ALL instances

    def __init__(self, name):
        self.name = name   # instance variable - unique per object

    @classmethod
    def change_company(cls, new_name):
        cls.company = new_name    # changes it for ALL employees!

    @staticmethod
    def is_valid_name(name):
        return isinstance(name, str) and len(name) > 0   # no self, no cls

Employee.change_company("NewCorp")
print(Employee.company)                   # "NewCorp" - affects everyone
print(Employee.is_valid_name("Riya"))     # True

slots - For when you need to go fast ⚡

By default, every object stores its attributes in a hidden dictionary (__dict__). That's flexible but uses memory.

__slots__ says: "I know exactly what attributes this object will have. Lock it down."

class Point:
    __slots__ = ['x', 'y']   # pre-declare allowed attributes

    def __init__(self, x, y):
        self.x = x
        self.y = y

p = Point(3, 4)
p.z = 5    # AttributeError - you said only x and y!

When to use it: when you're creating millions of small objects and memory is tight. Think game particles, simulation nodes, etc.

Pillar 2: Inheritance - "Why repeat yourself when you can just... inherit?"

The analogy: You inherited your dad's nose and your mom's stubbornness. You didn't write that code yourself - it came from your parents. But you also have your own traits that neither of them have.

Inheritance = a child class gets all the stuff from a parent class, plus adds its own.

The 5 Types (Yes, Five!)

# Single - the classic
class Animal:
    def breathe(self):
        return "inhale... exhale..."

class Dog(Animal):
    def speak(self):
        return "Woof!"

# Multilevel - grandparent → parent → child
class Puppy(Dog):
    def play(self):
        return "chasing tail..."

# Hierarchical - one parent, many children
class Cat(Animal):
    def speak(self):
        return "Meow!"

# Multiple - inheriting from TWO parents
class Pet:
    def cuddle(self):
        return "purrrr"

class DomesticCat(Cat, Pet):  # gets methods from BOTH
    pass

# Hybrid - combination of above (gets complex fast!)

💎 The Diamond Problem - Python's Trickiest Puzzle

What happens when D inherits from B and C, and B and C both inherit from A?

class A:
    def greet(self):
        return "Hello from A"

class B(A):
    def greet(self):
        return "Hello from B"

class C(A):
    def greet(self):
        return "Hello from C"

class D(B, C):
    pass

d = D()
print(d.greet())  # "Hello from B" - but WHY? 🤯

Python uses MRO (Method Resolution Order) to figure this out. Think of it as Python asking: "What's the search order when I look for a method?"

print(D.__mro__)
# D → B → C → A → object

Python walks left to right through the inheritance chain. It finds greet in B first, so that's what runs. The rule is called C3 linearization - it's a whole algorithm but the key insight is: Python always respects the order you wrote the parents.

Pro tip: Always use super() instead of calling ParentClass.method(self) directly. super() respects MRO. Hardcoding the parent name doesn't.

Pillar 3: Abstraction - "Tell me WHAT to do, not HOW"

The analogy: You plug a phone charger into any socket. You don't need to know the voltage regulation, wire resistance, or circuit breaker internals. The socket gives you an interface (two holes, specific voltage). How it delivers that is hidden.

Abstraction = define what a class must do, leave the how up to subclasses.

Python gives us the abc module (Abstract Base Classes) for this:

from abc import ABC, abstractmethod

class Shape(ABC):          # ABC = "I am an abstract class"

    @abstractmethod
    def area(self):        # Every Shape MUST implement this
        pass

    @abstractmethod
    def perimeter(self):   # And this
        pass

    def describe(self):    # This one is optional - already implemented
        return f"I am a shape with area {self.area():.2f}"

Now let's make some shapes:

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius

    def area(self):
        return 3.14159 * self.radius ** 2

    def perimeter(self):
        return 2 * 3.14159 * self.radius

class Rectangle(Shape):
    def __init__(self, w, h):
        self.w, self.h = w, h

    def area(self):
        return self.w * self.h

    def perimeter(self):
        return 2 * (self.w + self.h)

# shape = Shape()  TypeError - you can't instantiate an abstract class!
c = Circle(5)
r = Rectangle(4, 6)

print(c.describe())   # "I am a shape with area 78.54"
print(r.describe())   # "I am a shape with area 24.00"

Why is this useful in real projects?
Imagine you're building a payment system. You define an abstract PaymentGateway class with charge() and refund() methods. Now every developer adding a new gateway (Stripe, Razorpay, PayPal) is forced to implement both. No more "oops I forgot the refund method" bugs.

Pillar 4: Polymorphism - "Same name, totally different behavior"

The analogy: The word "run" means different things to a human (legs), a computer (execute), a river (flow), and your nose (drip when sick 🤧). Same word, different behavior depending on context.

Polymorphism = the same method name works differently on different objects.

Method Overriding

class Animal:
    def speak(self):
        return "..."

class Dog(Animal):
    def speak(self):
        return "Woof! 🐶"

class Cat(Animal):
    def speak(self):
        return "Meow! 🐱"

class Duck(Animal):
    def speak(self):
        return "Quack! 🦆"

# The MAGIC - you can treat them all the same!
zoo = [Dog(), Cat(), Duck(), Animal()]
for animal in zoo:
    print(animal.speak())

# Output:
# Woof! 🐶
# Meow! 🐱
# Quack! 🦆
# ...

You don't need to know what kind of animal you have. You just call .speak() and Python figures it out. This is polymorphism in action.

Operator Overloading - Making Python's `+` do YOUR bidding

Did you know + doesn't always mean "add numbers"? "hello" + " world" is string concat. [1,2] + [3,4] is list merge. Python lets YOU define what + means for your own classes using dunder methods (double underscore = "dunder"):

class Vector:
    def __init__(self, x, y):
        self.x = x
        self.y = y

    def __add__(self, other):          # what + does
        return Vector(self.x + other.x, self.y + other.y)

    def __mul__(self, scalar):         # what * does
        return Vector(self.x * scalar, self.y * scalar)

    def __eq__(self, other):           # what == does
        return self.x == other.x and self.y == other.y

    def __repr__(self):                # what print() shows
        return f"Vector({self.x}, {self.y})"

v1 = Vector(1, 2)
v2 = Vector(3, 4)

print(v1 + v2)      # Vector(4, 6) - our __add__ ran!
print(v1 * 3)       # Vector(3, 6) - our __mul__ ran!
print(v1 == v1)     # True - our __eq__ ran!

Here are the most useful dunder methods to know:

You write...	Dunder that runs
`a + b`	`__add__`
`a - b`	`__sub__`
`a * b`	`__mul__`
`a == b`	`__eq__`
`a < b`	`__lt__`
`len(a)`	`__len__`
`print(a)`	`__str__`
`repr(a)`	`__repr__`
`a[0]`	`__getitem__`

Bonus: Descriptors - "The magic behind the magic"

Okay, here's where it gets genuinely mind-bending.

Every time you use @property, you're using a descriptor. And every time Python accesses obj.attribute, there's a whole lookup protocol happening under the hood.

A descriptor is any class that implements __get__, __set__, or __delete__.

class Validator:
    """A reusable descriptor that validates integer attributes"""

    def __set_name__(self, owner, name):
        self.name = name         # Python tells us our attribute name automatically

    def __get__(self, obj, objtype=None):
        if obj is None:          # accessed on the class itself, not an instance
            return self
        return obj.__dict__.get(self.name)

    def __set__(self, obj, value):
        if not isinstance(value, int) or value < 0:
            raise ValueError(f"'{self.name}' must be a non-negative integer. Got: {value}")
        obj.__dict__[self.name] = value

class Product:
    price = Validator()       # ← descriptor instance as a CLASS attribute
    quantity = Validator()

    def __init__(self, price, quantity):
        self.price = price
        self.quantity = quantity

p = Product(100, 10)
print(p.price)       # 100
p.quantity = 5       # fine
p.price = -50        # ValueError: 'price' must be a non-negative integer. Got: -50

Why is this cool? One Validator class works for BOTH price and quantity. You write the validation logic once. @property would need two separate property definitions.

Mind-blowing fact: @property, @classmethod, @staticmethod - they're all descriptors themselves. Learning descriptors is learning how Python itself works at a fundamental level.

Quick Knowledge Check - Can you answer these?

Before you scroll away, try these in your head (or your REPL):

Q1: What's the difference between _name and __name?

Q2: Why would you use @classmethod over a regular method?

Q3: What does MRO stand for, and why does it exist?

Q4: What happens if a subclass doesn't implement an @abstractmethod?

Q5: What dunder method would you override to make len(your_object) work?

(Answers are in the code examples above - go find them! 🕵️)

🗺️ The Full Picture

Here's everything we covered, in one table:

Pillar	Core Idea	Key Python Tools
Encapsulation	Bundle data + control access	`_x`, `__x`, `@property`, `__slots__`
Inheritance	Reuse + extend parent code	`class Child(Parent)`, `super()`, MRO
Abstraction	Enforce interface, hide details	`ABC`, `@abstractmethod`
Polymorphism	Same name, different behavior	Method overriding, dunder methods
Descriptors	Customize attribute access itself	`__get__`, `__set__`, `__delete__`

💬 Let's Talk!

If you made it this far - you're a legend. Genuinely.

Drop a comment and tell me:

Which concept clicked the most for you?
Which one still feels fuzzy?
What should I write about next?

I'm documenting my learning journey here in public - every day I learn something new. Follow along if you want to learn together. 🙌

[Boost]

Kishan vyas — Thu, 22 May 2025 04:46:21 +0000

Kishan vyas

May 22 '25

Understanding 23 Design Patterns in Software Development

Comments

5 min read

Understanding 23 Design Patterns in Software Development

Kishan vyas — Thu, 22 May 2025 04:33:44 +0000

If you're diving deeper into software development and want to write cleaner, more scalable code — design patterns are your new best friends.

In this guide, I’ll walk you through the 23 most commonly used design patterns, grouped under Creational, Structural, and Behavioral patterns — all explained simply and with real-world examples in JavaScript.

Let’s go.........

📦 Creational Design Patterns

These deal with object creation mechanisms. The idea is to abstract the instantiation logic so that the system is not tightly coupled to the specific classes.

1. Singleton Pattern

Only one instance of a class is created and shared.

Use case: Logger, Config manager, DB connection.

class Singleton {
  constructor() {
    if (Singleton.instance) return Singleton.instance;
    Singleton.instance = this;
  }
}

const a = new Singleton();
const b = new Singleton();
console.log(a === b); // true

2. Factory Pattern

Creates objects without exposing the instantiation logic.

Use case: UI component factory, Notification sender (Email/SMS).

class Car {
  drive() {
    console.log("Driving a car");
  }
}

class Bike {
  drive() {
    console.log("Riding a bike");
  }
}

function VehicleFactory(type) {
  if (type === "car") return new Car();
  if (type === "bike") return new Bike();
}

const vehicle = VehicleFactory("bike");
vehicle.drive(); // Riding a bike

3. Abstract Factory Pattern

Factory of factories.

Use case: Theme factory for UI (DarkThemeFactory, LightThemeFactory)

function darkButton() {
  return { color: "black" };
}

function lightButton() {
  return { color: "white" };
}

function UIFactory(mode) {
  return {
    createButton: mode === "dark" ? darkButton : lightButton,
  };
}

const factory = UIFactory("dark");
console.log(factory.createButton()); // { color: "black" }

4. Builder Pattern

Step-by-step creation of a complex object.

Use case: Building complex HTML, query builder, or form builders.

class BurgerBuilder {
  constructor() {
    this.burger = {};
  }

  addCheese() {
    this.burger.cheese = true;
    return this;
  }

  addLettuce() {
    this.burger.lettuce = true;
    return this;
  }

  build() {
    return this.burger;
  }
}

const burger = new BurgerBuilder().addCheese().addLettuce().build();
console.log(burger); // { cheese: true, lettuce: true }

5. Prototype Pattern

Clone an existing object instead of creating a new one.

Use case: Performance optimization, default object templates.

const car = {
  wheels: 4,
  drive() {
    console.log("Driving...");
  },
};

const myCar = Object.create(car);
console.log(myCar.wheels); // 4

🧱 Structural Design Patterns

These are about class and object composition, focusing on how large structures are built from smaller pieces.

6. Adapter Pattern

Converts one interface to another.

Use case: Legacy APIs, payment gateway adapters.

class OldPrinter {
  oldPrint(msg) {
    console.log("Old Print:", msg);
  }
}

class Adapter {
  constructor() {
    this.oldPrinter = new OldPrinter();
  }

  print(msg) {
    this.oldPrinter.oldPrint(msg);
  }
}

const printer = new Adapter();
printer.print("Hello World");

7. Decorator Pattern

Add new functionality without modifying the original class.

Use case: Middleware, logging wrappers.

function coffee() {
  return "coffee";
}

function withMilk(coffeeFunc) {
  return () => coffeeFunc() + " + milk";
}

const fancyCoffee = withMilk(coffee);
console.log(fancyCoffee()); // coffee + milk

8. Facade Pattern

Simplifies a complex subsystem by exposing a high-level API.

Use case: Simplify media player libraries, SDKs.

class Engine {
  start() {
    console.log("Engine started");
  }
}

class Lights {
  on() {
    console.log("Lights on");
  }
}

class CarFacade {
  constructor() {
    this.engine = new Engine();
    this.lights = new Lights();
  }

  startCar() {
    this.engine.start();
    this.lights.on();
  }
}

const car = new CarFacade();
car.startCar();

9. Composite Pattern

Treat a group of objects the same way as a single object.

Use case: File system, nested UI elements.

class Leaf {
  constructor(name) {
    this.name = name;
  }

  show() {
    console.log(this.name);
  }
}

class Folder {
  constructor(name) {
    this.name = name;
    this.children = [];
  }

  add(child) {
    this.children.push(child);
  }

  show() {
    console.log(this.name);
    this.children.forEach(child => child.show());
  }
}

const file1 = new Leaf("file1.txt");
const file2 = new Leaf("file2.txt");

const folder = new Folder("MyFolder");
folder.add(file1);
folder.add(file2);

folder.show();

10. Bridge Pattern

Separate abstraction from implementation.

Use case: Theme-switching, rendering strategies.

class LightTheme {
  getColor() {
    return "Light color";
  }
}

class DarkTheme {
  getColor() {
    return "Dark color";
  }
}

class Page {
  constructor(theme) {
    this.theme = theme;
  }

  getContent() {
    return `Page with ${this.theme.getColor()}`;
  }
}

const darkPage = new Page(new DarkTheme());
console.log(darkPage.getContent()); // Page with Dark color

11. Proxy Pattern

A placeholder that controls access to another object.

Use case: Lazy loading, access control, logging.

class RealImage {
  display() {
    console.log("Displaying image");
  }
}

class ProxyImage {
  constructor() {
    this.realImage = null;
  }

  display() {
    if (!this.realImage) {
      this.realImage = new RealImage();
    }
    this.realImage.display();
  }
}

const img = new ProxyImage();
img.display();

🧠 Behavioral Design Patterns

These are all about how objects interact with each other.

12. Observer Pattern

Notify all subscribers when something changes.

Use case: Event listeners, Pub/Sub.

class Subject {
  constructor() {
    this.subscribers = [];
  }

  subscribe(fn) {
    this.subscribers.push(fn);
  }

  notify(data) {
    this.subscribers.forEach(fn => fn(data));
  }
}

const subject = new Subject();
subject.subscribe(console.log);
subject.notify("Hello!");

13. Strategy Pattern

Change the algorithm at runtime.

Use case: Sorting strategies, payment gateways.

function add(a, b) {
  return a + b;
}

function multiply(a, b) {
  return a * b;
}

function calculate(strategy, a, b) {
  return strategy(a, b);
}

console.log(calculate(add, 5, 3)); // 8
console.log(calculate(multiply, 5, 3)); // 15

14. Command Pattern

Encapsulate requests as objects.

Use case: Undo/Redo, menu actions.

class Light {
  turnOn() {
    console.log("Light on");
  }
}

class Command {
  constructor(device) {
    this.device = device;
  }

  execute() {
    this.device.turnOn();
  }
}

const light = new Light();
const cmd = new Command(light);
cmd.execute();

15. Chain of Responsibility Pattern

Pass requests down a chain until someone handles it.

Use case: Express middlewares, support ticket routing.

function handler1(req, next) {
  if (req.type === "log") console.log("Handler1 processed");
  else next();
}

function handler2(req) {
  console.log("Handler2 processed");
}

function processRequest(req) {
  handler1(req, () => handler2(req));
}

processRequest({ type: "data" }); // Handler2 processed

16. Template Method Pattern

Define the skeleton of an algorithm, but let subclasses fill in the steps.

Use case: Framework hooks.

class Game {
  start() {
    this.init();
    this.play();
    this.end();
  }

  init() {}
  play() {}
  end() {}
}

class Football extends Game {
  init() {
    console.log("Football Initialized");
  }

  play() {
    console.log("Playing Football");
  }

  end() {
    console.log("Football Ended");
  }
}

new Football().start();

17. State Pattern

Change behavior based on internal state.

Use case: Media players, form steps, UI modes.

class TrafficLight {
  constructor() {
    this.states = ["green", "yellow", "red"];
    this.current = 0;
  }

  change() {
    console.log("Light:", this.states[this.current]);
    this.current = (this.current + 1) % this.states.length;
  }
}

const light = new TrafficLight();
light.change(); // green
light.change(); // yellow

18. Mediator Pattern

Centralized communication between objects.

Use case: Chatrooms, component interactions.

class ChatRoom {
  showMessage(user, message) {
    console.log(`${user}: ${message}`);
  }
}

const room = new ChatRoom();
room.showMessage("Alice", "Hello Bob!");

19. Visitor Pattern

Add operations to objects without changing their classes.

Use case: Compilers, object structure traversal.

class Book {
  accept(visitor) {
    visitor.visitBook(this);
  }
}

class BookVisitor {
  visitBook(book) {
    console.log("Visiting book");
  }
}

const book = new Book();
book.accept(new BookVisitor());

20. Interpreter Pattern

Build a simple language interpreter.

Use case: Regex, Expression evaluators.

class Number {
  constructor(value) {
    this.value = value;
  }

  interpret() {
    return this.value;
  }
}

const one = new Number(1);
const two = new Number(2);
console.log(one.interpret() + two.interpret()); // 3

21. Memento Pattern

Capture and restore an object's state.

Use case: Undo features, save/restore.

class Editor {
  constructor() {
    this.content = "";
  }

  write(text) {
    this.content += text;
  }

  save() {
    return this.content;
  }

  restore(saved) {
    this.content = saved;
  }
}

22. Iterator Pattern

Access elements without exposing the structure.

Use case: Custom collections.

const arr = [1, 2, 3];
const iterator = arr[Symbol.iterator]();

console.log(iterator.next()); // { value: 1, done: false }

23. Null Object Pattern

Use an object that does nothing instead of null.

Use case: Avoid if (obj) checks.

class NullUser {
  getName() {
    return "Guest";
  }
}

function getUser(user) {
  return user || new NullUser();
}

console.log(getUser(null).getName()); // Guest

Happy Coding 👨‍💻🔥

Singleton Design Pattern: Explained Simply

Kishan vyas — Sun, 11 May 2025 12:36:05 +0000

The Singleton Design Pattern is a creational design pattern that ensures a class has only one instance and provides a global point of access to it. Think of it as a single, shared resource that everyone can use, but no one can duplicate.

Why Use the Singleton Pattern?

The Singleton pattern is ideal when:

You need exactly one instance of a class, such as for a database connection, configuration manager, or logging system.
You want to control access to this instance to avoid issues like inconsistent states caused by multiple instances.

How Does It Work?

The Singleton pattern relies on three core principles:

Private Constructor: The class restricts instantiation from outside by making its constructor private.
Static Instance: The class maintains a single, static instance of itself.
Static Access Method: A public static method (often called getInstance()) provides access to the single instance, creating it if it doesn’t exist.

Simple Code Example (Java)

Here’s a basic implementation of the Singleton pattern in Java:

public class Singleton {
    // Static variable to hold the single instance
    private static Singleton instance;

    // Private constructor to prevent instantiation
    private Singleton() {
    }

    // Public static method to access the instance
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}
// Using the Singleton
Singleton s1 = Singleton.getInstance();
Singleton s2 = Singleton.getInstance();
// s1 and s2 refer to the SAME instance

How It Ensures a Single Instance

When you use the Singleton pattern, multiple variables (like s1 and s2) requesting the instance will point to the same object, ensuring only one instance exists.

Real-World Analogy

Imagine a company CEO. There’s only one CEO for the entire company, and everyone accesses the same person for high-level decisions. You can’t have multiple CEOs, and the CEO’s office (the getInstance() method) is the way to reach them.

Key Considerations

Thread Safety: In multithreaded environments, synchronization is needed to prevent multiple instances. Options include using the synchronized keyword or double-checked locking.
Lazy Initialization: The instance is created only when first requested, saving resources.
Eager Initialization: Alternatively, you can create the instance when the class is loaded (e.g., private static Singleton instance = new Singleton();).

Pros of the Singleton Pattern

Guarantees a single instance of the class.
Provides global access to the instance.
Supports lazy initialization to optimize resource usage.

Cons of the Singleton Pattern

Can be tricky in multithreaded environments without proper synchronization.
May cause tight coupling, reducing code flexibility.
Complicates unit testing due to its global state.

When to Use It

The Singleton pattern shines when you need a single, shared resource, such as:

A logging system writing to a single file.
A configuration manager for application-wide settings.
A connection pool for database connections.

Conclusion

The Singleton Design Pattern is a straightforward yet powerful tool for ensuring a class has only one instance while providing global access to it. By leveraging a private constructor, a static instance, and a static access method, you can enforce this constraint effectively. Just be cautious of thread safety and design challenges when implementing it.

Whether you’re building a small app or a complex system, the Singleton pattern can help manage shared resources efficiently!

From Internship to Impact: How I Automated Deployment with Telegram Alerts

Kishan vyas — Mon, 05 May 2025 18:21:18 +0000

In the world of full-stack development, building features is just one part of the job. What really separates a developer from an engineer is how you handle deployments, automation, and monitoring.

As an intern working on a real-world Import Export management system, I recently faced a challenge:
How do I ensure seamless deployment with zero guesswork—especially when working alone or in a small team?

The Problem

Every time I updated the backend code:
I had to manually pull the code on the server.
Restart services and check for errors.
Pray that I didn’t miss something in the deployment process.

It wasn’t scalable. So I built a simple yet powerful CI/CD system with Telegram alerts.

What I Built

Here’s what the pipeline does:

GitHub Webhook triggers on push
Server pulls the latest code
Runs build + restart commands
Sends a Telegram message with the result: success or failure

Tech Stack

Node.js backend
Bash scripts on a Linux VPS
GitHub Webhooks
Telegram Bot API
Nginx for reverse proxy

Why Telegram?

Simple. Instant feedback without needing to check logs or dashboards.
If deployment fails, I know immediately. If it succeeds, I keep building confidently.

Code Snippet

#!/bin/bash
cd /home/udhyog/ImportExport/management-sheet
git pull origin main

if pm2 restart backend; then
  curl -s -X POST "https://api.telegram.org/bot<token>/sendMessage" \
  -d chat_id=<your_chat_id> \
  -d text="✅ Deployment succeeded!"
else
  curl -s -X POST "https://api.telegram.org/bot<token>/sendMessage" \
  -d chat_id=<your_chat_id> \
  -d text="❌ Deployment failed!"
fi

The Impact

Reduced downtime
Instant awareness of issues
Peace of mind as a solo/full-stack dev
Made the system production-ready

Final Thoughts

Small automations = huge productivity gains.
Whether you're an intern, solo dev, or working in a team, it's worth investing time into your deployment process.

Let your code deploy and talk to you.

A Deep Dive into Forward and Reverse Proxy with NGINX on Linux

Kishan vyas — Mon, 02 Sep 2024 01:25:51 +0000

Proxies play a critical role in modern web architecture, enabling secure, efficient, and manageable network communications. NGINX, a powerful and widely-used web server, excels in providing both forward and reverse proxy capabilities. In this blog, we'll dive into the concepts of forward and reverse proxies, how they work in NGINX, and provide code examples for setting them up on a Linux machine.

What is a Proxy?
Forward Proxy
- Definition
- Use Cases
- Setting up Forward Proxy with NGINX
Reverse Proxy
- Definition
- Use Cases
- Setting up Reverse Proxy with NGINX
Key Differences Between Forward and Reverse Proxy
Conclusion

1. What is a Proxy?

A proxy acts as an intermediary between a client and a server. It handles requests from clients, forwards them to the appropriate server, and then returns the server's response back to the client. This can be done for various purposes, such as improving security, load balancing, or accessing blocked resources.

2. Forward Proxy

Definition

A forward proxy sits between a client and the internet. It is used by clients to access resources on the internet that they might not be able to reach directly. This could be due to network restrictions, privacy concerns, or simply to cache content for quicker access.

Use Cases

Access Control: Allow or block access to certain websites or resources.
Privacy: Hide the client's IP address from the internet.
Content Filtering: Block specific types of content (e.g., ads or adult content).
Caching: Store copies of frequently accessed resources to speed up requests.

Setting up Forward Proxy with NGINX

Here's how you can set up a forward proxy server with NGINX on a Linux machine:

Install NGINX: Make sure NGINX is installed on your Linux machine. If not, install it using the package manager:

   sudo apt update
   sudo apt install nginx

Configure NGINX as a Forward Proxy: Edit the NGINX configuration file to set up the forward proxy.

Open the NGINX configuration file:

   sudo nano /etc/nginx/nginx.conf

Add the following configuration:

   events {}

   http {
       server {
           listen 8080; # The port on which the forward proxy will listen

           location / {
               proxy_pass $scheme://$host$request_uri;
               proxy_set_header Host $host;
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
               proxy_set_header X-Forwarded-Proto $scheme;
           }

           access_log /var/log/nginx/proxy-access.log;
           error_log /var/log/nginx/proxy-error.log;
       }
   }

This configuration tells NGINX to listen on port 8080 and forward all requests it receives to the destination server.

Restart NGINX:

After editing the configuration file, restart NGINX to apply the changes:

   sudo systemctl restart nginx

Test the Forward Proxy: You can test the forward proxy by configuring a web browser to use your Linux machine's IP address and port 8080 as a proxy server.

3. Reverse Proxy

Definition

A reverse proxy, on the other hand, sits between the internet and a server. It forwards client requests to one or more backend servers and returns the server's response to the client. The client interacts with the reverse proxy as if it were the actual server.

Use Cases

Load Balancing: Distribute incoming traffic across multiple servers.
SSL Termination: Handle SSL encryption/decryption on behalf of backend servers.
Security: Protect backend servers by hiding their IP addresses and managing access control.
Caching: Store responses from backend servers to reduce load and improve response times.

Setting up Reverse Proxy with NGINX

Here's how to configure NGINX as a reverse proxy on a Linux machine:

Install NGINX: Ensure NGINX is installed:

   sudo apt update
   sudo apt install nginx

Configure NGINX as a Reverse Proxy: Edit the NGINX configuration file to set up the reverse proxy.

Open the NGINX configuration file:

   sudo nano /etc/nginx/sites-available/default

Modify the server block to include the reverse proxy configuration:

   server {
       listen 80;

       server_name example.com; # Replace with your domain or IP address

       location / {
           proxy_pass http://backend_server_ip; # Replace with your backend server IP or domain
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }

       access_log /var/log/nginx/reverse-proxy-access.log;
       error_log /var/log/nginx/reverse-proxy-error.log;
   }

This configuration directs NGINX to forward all requests it receives on port 80 to the backend server specified by proxy_pass.

Restart NGINX:

After updating the configuration, restart NGINX:

   sudo systemctl restart nginx

Test the Reverse Proxy: You can test the reverse proxy by accessing your domain or IP address in a web browser. The requests should be forwarded to the backend server.

4. Key Differences Between Forward and Reverse Proxy

Direction of Proxying: A forward proxy handles requests from clients seeking resources from servers, while a reverse proxy handles requests from clients and forwards them to backend servers.
Client Awareness: In a forward proxy, the client knows it's using a proxy, whereas, in a reverse proxy, the client is unaware it's interacting with a proxy.
Common Uses: Forward proxies are commonly used for privacy, filtering, and access control, while reverse proxies are used for load balancing, SSL termination, and security.

5. Conclusion

NGINX is a versatile tool that can act as both a forward and reverse proxy, providing a variety of benefits including improved security, load balancing, and access control. Whether you need to set up a forward proxy to control client access to the internet or a reverse proxy to manage and secure backend server traffic, NGINX on Linux offers a robust solution.

By understanding and implementing these proxies, you can enhance your network architecture, making it more efficient and secure.

The Importance of Connection Pooling

Kishan vyas — Sat, 03 Aug 2024 18:29:55 +0000

Introduction

In the world of modern web applications, efficient database management is critical for performance and scalability. One key technique that ensures efficient database interaction is connection pooling. In this blog, we will explore the need for connection pooling, the consequences of not using it, and the benefits it brings when properly implemented, especially in the context of Prisma ORM and PostgreSQL.

Imagine this: every time a user visits your app, a brand new connection to the database is created. Sounds simple, right? But this can quickly lead to delays, especially when your app is handling multiple users at once. That's where connection pooling saves the day!

What is Connection Pooling?

Connection pooling is a method of managing database connections by maintaining a pool of reusable connections. Instead of creating a new connection for every request, the pool reuses existing connections, significantly reducing the overhead associated with establishing new connections.

Why is Connection Pooling Needed?

Resource Optimization:

Establishing a new database connection is resource-intensive and time-consuming. Connection pooling minimizes this overhead by reusing existing connections.

Scalability:

Modern applications often handle a high number of concurrent requests. Without connection pooling, each request would require a new connection, quickly overwhelming the database. Connection pooling helps manage and limit the number of active connections.

Performance:

Reusing connections reduces latency, leading to faster query execution and improved overall application performance.

What Happens Without Connection Pooling?

High Latency:

Every new request results in creating a new database connection, introducing significant latency due to the overhead of connection establishment.

Resource Exhaustion:

Databases have a limit on the number of concurrent connections they can handle. Without pooling, the application can easily exceed this limit, leading to connection failures and degraded performance.

Increased Costs:

In cloud environments, unnecessary creation and management of connections can lead to higher operational costs due to increased resource usage.

Unstable Applications:

Frequent connection creation and teardown can cause instability, leading to frequent crashes and unreliable application behavior.

What Happens With Connection Pooling?

Improved Performance:

Reusing existing connections minimizes latency, resulting in faster response times and a smoother user experience.

Efficient Resource Utilization:

Connection pooling ensures that database resources are used efficiently, reducing the risk of connection limits being exceeded and improving overall stability.

Scalability:

The application can handle a higher number of concurrent requests without overwhelming the database, making it more scalable.

Cost Efficiency:

Efficient connection management leads to optimized resource usage, potentially reducing operational costs in cloud environments.

Conclusion

Connection pooling is essential for any application interacting with a database, especially in serverless environments. It optimizes resource usage, enhances performance, ensures scalability, and reduces operational costs. By implementing connection pooling with Prisma ORM and PostgreSQL, you can significantly improve your application's efficiency and reliability.

DEV Community: Kishan vyas

I Spent a Full Day Learning OOP in Python, Here's Everything, Explained Like You're 15

First, the 30 second version of "What even IS OOP?"

Pillar 1: Encapsulation - "What happens in the class, stays in the class"

The Underscore Rules 🐍

@property - The Pythonic Getter/Setter

@classmethod vs @staticmethod - What's the difference?

slots - For when you need to go fast ⚡

Pillar 2: Inheritance - "Why repeat yourself when you can just... inherit?"

The 5 Types (Yes, Five!)

💎 The Diamond Problem - Python's Trickiest Puzzle

Pillar 3: Abstraction - "Tell me WHAT to do, not HOW"

Pillar 4: Polymorphism - "Same name, totally different behavior"

Method Overriding

Operator Overloading - Making Python's + do YOUR bidding

Bonus: Descriptors - "The magic behind the magic"

Quick Knowledge Check - Can you answer these?

🗺️ The Full Picture

💬 Let's Talk!

[Boost]

Understanding 23 Design Patterns in Software Development

Understanding 23 Design Patterns in Software Development

📦 Creational Design Patterns

1. Singleton Pattern

2. Factory Pattern

3. Abstract Factory Pattern

4. Builder Pattern

5. Prototype Pattern

🧱 Structural Design Patterns

6. Adapter Pattern

7. Decorator Pattern

8. Facade Pattern

9. Composite Pattern

10. Bridge Pattern

11. Proxy Pattern

🧠 Behavioral Design Patterns

12. Observer Pattern

13. Strategy Pattern

14. Command Pattern

15. Chain of Responsibility Pattern

16. Template Method Pattern

17. State Pattern

18. Mediator Pattern

19. Visitor Pattern

20. Interpreter Pattern

21. Memento Pattern

22. Iterator Pattern

23. Null Object Pattern

Singleton Design Pattern: Explained Simply

Why Use the Singleton Pattern?

How Does It Work?

Simple Code Example (Java)

How It Ensures a Single Instance

Real-World Analogy

Key Considerations

Pros of the Singleton Pattern

Cons of the Singleton Pattern

When to Use It

Conclusion

From Internship to Impact: How I Automated Deployment with Telegram Alerts

The Problem

What I Built

Tech Stack

Why Telegram?

Code Snippet

The Impact

Final Thoughts

A Deep Dive into Forward and Reverse Proxy with NGINX on Linux

Table of Contents

1. What is a Proxy?

2. Forward Proxy

Definition

Use Cases

Setting up Forward Proxy with NGINX

3. Reverse Proxy

Definition

Use Cases

Setting up Reverse Proxy with NGINX

4. Key Differences Between Forward and Reverse Proxy

5. Conclusion

Operator Overloading - Making Python's `+` do YOUR bidding