DEV Community: Samarth Gambhir

Kubernetes Journey Part 1: Why Docker?

Samarth Gambhir — Mon, 22 Dec 2025 12:57:15 +0000

Welcome to the first post on learning Kubernetes! Before we dive into the complexities, we have to talk about the building block that made it all possible: Docker.

If you’ve ever worked in software development, you’ve likely encountered the phrase: "But it works on my machine!"

Why Docker?

Imagine you’ve just finished a new feature and your code is merged into the Version Control System (VCS), and the build pipeline created an artifact which is deployed to the server.

Dev Server: It works perfectly. ✅

Test Server: Working as expected. ✅

Production: You deploy, and the build fails. ❌

What happened?

There could be multiple reasons for this, but most frequent reason is "Environment Misconfiguration" or due to missing dependencies which were there in dev and test environment but missing from production.

Traditionally, you cannot ship the entire environment and dependencies with your code. You shipped the "artifact" to the servers. That's when containers come into picture.

How Docker Solved this?

With Docker, instead of shipping just your code, you package everything the code needs to run (libraries, dependencies, configurations, and even the base OS binaries) into one single unit. This makes chances of misconfigurations negligible.

What is a Container?

Container is an isolated lightweight sandbox environment with all the application code, libraries and runtime dependencies. Everything required to run the application irrespective of host operating system.

Key Distinction: Unlike a Virtual Machine (VM), a container does not package a full Operating System. It has bare minimum binaries and uses the host's OS kernel. This makes containers incredibly lightweight, fast and portable across any machine that has Docker installed.

Definition: Docker is the platform that allows you to build, ship, and run these containers anywhere.

How It Works: Dockerfile to Runtime

To containerize an application, we follow a specific workflow involving three main components: Dockerfiles, Images, and Containers.

The Dockerfile
A Dockerfile is a simple text document containing a list of instructions. When you run docker build, Docker reads these instructions to create an Image.
The Image
A Docker image is a snapshot of your application. It contains everything your app needs to run. However, we cannot ship images to servers. So we need docker image to be stored in some registry same as a VCS. All environments pull the image from the same registry using the docker pull command.
The Container
When you want to run your app, you use the docker run command which takes the image and turns it into a running instance. This instance is the container.

The Docker Architecture

Docker has majorly 3 components in its architecture:

The Client: This is where you code (like your laptop).

The Docker Daemon (dockerd): The "brain" of Docker that sits on the host machine. It listens for API requests from the client and manages images and containers.

The Registry: The remote storage where images are hosted.

The Lifecycle of a Docker Command:

docker build: The Client tells the Daemon to create an image based on a Dockerfile which is stored locally.

docker push: The Daemon pushes your local image to a remote Registry so it can be used on the server.

docker pull: command is used on the environment to deploy. It asks the Daemon to download a specific image from the Registry.

docker run: The Daemon instructs the Container Runtime to spin up a container using that pulled image.

Summary

By using Docker, we ensure that the environment in Dev is identical to the environment in Prod. If it works on your machine, it will work on the server, because you are shipping "your machine" (the container) along with the code.

Now that we understand why we need containers, the next step in our series is learning how to manage multiple containers at once. That is where Kubernetes enters the story.

Stay tuned for Part 2!

CAP Theorem in Distributed Systems : Beyond the ‘Pick Two’ Myth

Samarth Gambhir — Tue, 09 Sep 2025 11:29:57 +0000

When most of us first encounter the CAP theorem, it’s introduced with a catchy phrase: “Consistency, Availability, Partition Tolerance - pick two.”

It’s a neat way to remember it, but like most neat sayings, it oversimplifies the reality. In truth, CAP is about understanding trade offs in distributed systems, and appreciating its nuances makes you a better engineer.
In this post, we’ll go beyond the surface level explanation and see how it applies to the systems we work with, using a relatable example: Bank ATMs

The ATM Analogy

An ATM network is a real world example of a distributed system. Here:

The bank’s central server acts as the source of truth.
Each ATM machine is a node in the system.

Together, they form a distributed system where your account balance should remain consistent across all ATMs. Now, imagine you walk up to an ATM to deposit or withdraw cash.

In the ideal case, the ATM successfully communicates with the bank’s server.
Your transaction goes through, and the update is reflected across all ATMs in the network.

This is a scenario with no partition — the nodes (ATMs) are fully connected to the server, and both consistency and availability is naturally maintained.

What is CAP Theorem?

The CAP theorem is a fundamental principle in distributed systems that tells us about the trade offs we must make when our system is partitioned. To understand it properly, we need to start with the most important piece:

What is a Partition?

Imagine you have multiple servers that should stay in sync. If a network failure prevents one server from talking to another, the system is said to be "partitioned".

This is not a rare edge case because in large scale distributed systems, partitions are inevitable due to:

Network failures
Geographic distance
Latency spike

What it means in ATM terms?

A partition happens when an ATM loses connection to the bank’s central server.

The ATM can no longer verify your latest account balance in real time.
Any deposits or withdrawals made at this ATM won’t immediately sync with the rest of the system.

Effectively, this ATM is "cut off" from the rest of the distributed network.

Since partitions are unavoidable, we need our system to have "Partition Tolerance". So, the real world trade off is always between Consistency (C) and Availability (A).

Partition Tolerance means the system continues to operate despite partitioning due to network failures.

CP - Consistency & Partition Tolerance

In a CP system, the design choice is to guarantee Consistency and Partition Tolerance even if it means sacrificing Availability during a partition.

ATM Analogy for CP

Imagine you walk up to an ATM during a partition:

The ATM tries to connect to the central bank server, but connection fails (partition), the ATM will refuse your transaction. Here, the ATM deliberately compromises "Availability" for "Consistency."

Why? Because letting you withdraw without verifying your account risks double withdrawals or invalid balances.

AP - Availability & Partition Tolerance

In an AP system, the design guarantees Availability and Partition Tolerance even if that means sacrificing Consistency during a partition.

ATM Analogy for AP

Imagine you walk up to an ATM during a partition:

The ATM tries to connect to the central bank server but the connection fails (partition). Instead of refusing your transaction, the ATM still lets you withdraw cash. Here, the ATM deliberately compromises "Consistency" in order to preserve "Availability".

Why? Because the system chooses to stay operational, even if it means your withdrawal might not immediately reflect in your account balance risking temporary inconsistencies like negative balances.

Beyond the Simplistic “Pick Two” View

The CAP theorem is often oversimplified to guarantee only two out of "Consistency, Availability, and Partition Tolerance".

Real systems don’t just fall neatly into CP or AP categories. They often sit somewhere in between, offering "partial consistency" or "partial availability" depending on the situation.

What is Partial Consistency?

Consistency doesn’t always mean perfectly up to date or completely wrong. Many systems aim for eventual consistency, where data may be temporarily stale but eventually converges across nodes when partition is resolved.

What is Partial Availability?

Availability isn’t just about a system being fully online or completely offline. In many cases, systems aim for partial availability — they keep some features working while restricting others during a partition. This allows users to get at least something instead of facing a total outage.

Back to our ATM analogy:

Even if the ATM is partitioned, it might still allow deposits. After a deposit, your balance may look incorrect for a short while, but it eventually gets updated once the connection is restored. In this case, the ATM is partially available because it continues to provide some functionality. At the same time, it is also partially consistent because it deliberately restricts withdrawals to avoid issues like negative balances.

Conclusion

The CAP theorem isn’t about picking two properties and discarding the third. It’s about understanding how distributed systems behave under failure and making deliberate trade offs. In practice, systems rarely offer absolute consistency or availability. Instead, they operate in a combination of both — tolerating temporary inconsistency to preserve availability, while restricting risky operations during partitions to maintain safety.

From Microservices to Fan-Out: Evolving Cross-Service Communication in Modern Systems

Samarth Gambhir — Sun, 29 Jun 2025 16:45:21 +0000

In modern backend development, microservices are everywhere, and for good reason.

Instead of building a giant monolithic application, we break the system into smaller, focused services, each responsible for doing one thing well. This is the essence of microservice architecture:

One service = One responsibility
Each service = Independently deployable
Services talk to each other = System communication

For example, in an e-commerce platform:

| Service            | Responsibility                  |
| ------------------ | ------------------------------- |
| OrderService       | Accepts and creates new orders  |
| SMSService         | Sends SMS notifications         |
| EmailService       | Sends order confirmation emails |
| InventoryService   | Updates product stock           |

Each service:

Runs independently
Can be deployed separately
Owns its own data (DB)

But breaking a monolith into microservices is only the first step.

What follows is much harder:

“How do these small, independent services talk to each other reliably, at scale, and without bringing the system down?”

To understand this, let’s walk through a simple, relatable example:

A user places an order in an e-commerce application.

This one event will help us explore the evolution of communication patterns. When a user places an order, we want to:

Send an order confirmation SMS
Send an order confirmation Email

So, how can we make this happen?

🛜 The Naive Approach - HTTP Call

The first solution that comes to our mind is making a HTTP call from one service to another.

But what happens if:

SMS or Email service is down?
It’s slow to respond?
The network drops?

This is a synchronous way as our Order service is blocked or fails too. That’s too fragile. We can use a simple Message Queue for handling this.

📦 What is a Message Queue?

A message queue follows simple FIFO (First-In, First-Out) logic. It decouples events from consumers — meaning:

The producer service doesn’t care when or how the message is processed.
The consumer service pulls messages independently, processes them, and acknowledges success.

This model allows both services to scale, fail, and recover independently.

✅ The Asynchronous Solution – Message Queue

Message queues provide at-least-once delivery. That means a message might be processed more than once if retries happen. It’s the consumer's job to make message handling idempotent — i.e., safely repeatable. So, we introduce a Message Queue between our services:

Now:

Order service drops the message to queues and moves on.
The queue stores it until their respective service processes it.
If it fails, the message is pushed back to the queue for retry.

⚠️ Limitations

If we continue using a message queue, only one service will receive the message. Others will miss it.

We could try adding multiple separate queues, but that means the producer (OrderService) now needs to know all the consumers — tightly coupling everything again.

✅ The Solution - Pub/Sub Architecture

In Pub/Sub systems like Kafka, you can group consumers by concern — and each consumer group gets its own copy of the message. But delivery guarantees depend heavily on the implementation. So, we switch to a Pub/Sub system:

Now:

OrderService just publishes an event.
All interested services subscribe to it.
Everyone receives the same message, independently.

⚠️ Limitations

Message loss possible if a service is offline during event publication.
No per-service retries as the event can't be republished for retry.
Consumers may race each other if not isolated.

✅ Solution - Fan-Out Architecture

Fan-Out is a hybrid of Pub/Sub + Queues.

Instead of one message going to many services directly, we create a queue per subscriber, resulting in a fallback for retrying failed events.

Now, each service:

Gets its own durable message queue.
Can retry failures independently.
Is fully isolated from the others.

🧠 Key Takeaways

Message Queues are great for decoupling a task from its processor, but not ideal where multiple services are involved.
Pub/Sub lets you notify multiple systems from a single event, but do not provide a fallback.
Fan-Out adds durability, reliability and a fallback point to the pub/sub pattern.

A single event — like an order being placed — may seem small. But behind the scenes, it may trigger multiple workflows, handled by independent services, and needing different levels of reliability. Understanding when to use which pattern can make or break the scalability and resilience of your system.

Docker or Virtual Machines: Your First Step Into Modern Software

Samarth Gambhir — Thu, 12 Jun 2025 07:52:07 +0000

Have you ever heard developers talking about "Docker" or "containers" and felt completely lost? Don't worry - you're not alone! This guide will explain everything from scratch, assuming you know nothing about Docker or Virtual Machines.
By the end of this article, you'll understand what Docker is, why it's so popular, and how it compares to older technologies. Think of this as your starting point for learning Docker and modern software deployment.

What Problem Are We Trying to Solve?

Before we dive into Docker and Virtual Machines, let's understand the problem they solve. Imagine you're a developer who just built a website. It works perfectly on your computer, but when you try to run it on your friend's computer or on a server, it breaks. Why? Because your computer has different software versions, settings, or missing pieces that your website needs.
This is the classic "it works on my machine" problem that has frustrated developers for decades. Docker and Virtual Machines are two different solutions to this same problem.

Virtual Machines: Creating Multiple Computers

Virtual Machines solved this by creating fake computers inside your real computer. Think of it like having multiple laptops running inside one powerful desktop.

How do VMs Work?

A VM works like this: you have your physical server, then you install special software called a "hypervisor" (like VMware or VirtualBox). This hypervisor creates multiple virtual computers, each with its own operating system.
So on one physical server, you might have:

VM 1: Running Windows with your web application
VM 2: Running Linux with your database
VM 3: Running another Linux for testing

Each VM thinks it's running on its own dedicated computer, but they're actually sharing the same physical hardware.

VM Benefits

Complete separation between applications
Can run different operating systems
If one VM crashes, others keep running
Easy to backup and move around

VM Problems

Each VM needs its own operating system, which uses lots of memory and storage
Slow to start up (like booting a computer)
Wastes resources because each OS takes up space even when doing nothing

Docker: A Smarter Approach

Docker took a different approach. Instead of creating fake computers, Docker creates isolated "containers" that share the same operating system.

What are Docker Images?

A Docker image is like a blueprint or recipe that contains everything needed to run your application:

Your application code
The runtime environment (like Node.js or Python)
System libraries and dependencies
Configuration files

Think of it as a complete package that includes your app and everything it needs to run, but without a full operating system.

What are Docker Containers?

A container is what you get when you run an image. If an image is like a recipe, a container is the actual dish you cook from that recipe.
Key points about containers:

Multiple containers can run from the same image
Each container runs independently
All containers share the host operating system's kernel (the core part of the OS)
Containers have their own isolated space for processes and files

The Big Comparison - Docker VS Virtual Machine

Let's compare these technologies in simple terms:

Size and Speed

Virtual Machines: Heavy and slow

Takes 30+ seconds to start (full OS boot)
More overhead due to hardware simulation

Docker Containers: Light and Fast

Starts in seconds (just launching the application)
Near-native performance since no hardware simulation

How Many Can You Run?

Virtual Machines: Fewer

Maybe 10-20 VMs on one server
Each VM needs its own operating system

Docker Containers: Many more

Hundreds of containers on the same server
All containers share one operating system

Security

Virtual Machines: More Secure

Each VM has its own kernel and complete separation
Like having separate locked rooms

Docker Containers: Less secure but still good

Containers share the kernel but have separate processes
Like having separate apartments in the same building

When things go wrong

Virtual Machines: problems stay contained

VM failures remain isolated since each runs its own independent kernel
System crashes in one VM don't affect others running on the same host

Docker Containers: Usually contained, but...

Individual container failures typically don't impact other containers
Host operating system issues can potentially affect all running containers

When Should You Use Each?

Use Virtual Machines When:

You need to run different operating systems (Windows and Linux together)
Security is extremely important
You're working with older applications that need specific setups
You don't mind slower startup times

Use Docker when:

You want to deploy applications quickly
You're building modern web applications
You want to save money on server costs
You need to scale up and down rapidly
Your team needs consistent development environments

Real-World Example

Let's say you're running an online store:

With VMs: You might have one VM for your website, another for your database, and another for handling payments. Each VM runs its own operating system.

With Docker: You'd have containers for each service (website, database, payments) all sharing the same operating system but running independently.
The Docker approach uses less resources and starts faster, while the VM approach provides stronger security boundaries.

The Bottom Line

Both technologies solve the same core problem - making software run consistently everywhere - but in different ways:

Virtual Machines are like having multiple separate computers in one box
Docker Containers are like having multiple isolated applications sharing one computer

Abstract Thinking: Java’s Structure vs Go’s Simplicity

Samarth Gambhir — Wed, 21 May 2025 07:15:18 +0000

Introduction

Interfaces are a core part of many programming languages, providing a way to define behavior without locking in the exact implementation. They promote flexibility, code reuse, and a cleaner design. However, the way interfaces work in Go and Java is quite different. In this blog, we’ll explore these differences and why they matter to developers.

Interfaces in Java

Java interfaces are a key part of its object-oriented design. They define a contract that a class must fulfill, ensuring that certain methods are present. Java interfaces are implemented explicitly using the implements keyword, and the compiler checks that a class has provided all the required methods.

interface Printer {
    void printMessage(String message);
}

class ConsolePrinter implements Printer {
    @Override
    public void printMessage(String message) {
        System.out.println("Console: " + message);
    }
}

class FilePrinter implements Printer {
    @Override
    public void printMessage(String message) {
        System.out.println("File: " + message);
    }
}

public class Main {
    public static void main(String[] args) {
        Printer consolePrinter = new ConsolePrinter();
        consolePrinter.printMessage("Hello, World!");

        Printer filePrinter = new FilePrinter();
        filePrinter.printMessage("Hello, File!");
    }
}

In this example, both ConsolePrinter and FilePrinter explicitly declare that they implement the Printer interface, ensuring they both have the printMessage() method. This approach is typical in large, enterprise-grade systems where strict contracts are essential.

Interfaces in Go

Go takes a more relaxed approach to interfaces. It uses structural typing, which means a type satisfies an interface if it has the required methods, without any special keyword or declaration. This makes Go interfaces much simpler and more flexible.

package main

import "fmt"

type Printer interface {
    PrintMessage(message string)
}

type ConsolePrinter struct{}

type FilePrinter struct{}

func (cp ConsolePrinter) PrintMessage(message string) {
    fmt.Println("Console:", message)
}

func (fp FilePrinter) PrintMessage(message string) {
    fmt.Println("File:", message)
}

func main() {
    var printer Printer = ConsolePrinter{}
    printer.PrintMessage("Hello, World!")

    printer = FilePrinter{}
    printer.PrintMessage("Hello, File!")
}

Here, both ConsolePrinter and FilePrinter satisfy the Printer interface just by having the right methods. No need for explicit declarations, which keeps the code cleaner and more flexible.

Key Differences

Explicit vs Implicit Implementation:

Java: You must explicitly declare when a class implements an interface using the implements keyword. This creates a clear, enforced contract.
Go: Interfaces are satisfied implicitly. If a type has all the required methods, it automatically satisfies the interface. This reduces boilerplate but can make code relationships less obvious.

Structural vs Nominal Typing:

Java: Interfaces use nominal typing, meaning a class must explicitly declare which interfaces it implements. This adds clarity but requires more code.
Go: Interfaces use structural typing, where the relationship is determined by the presence of methods, not explicit declarations. This allows for more flexible, reusable code.

Interface Satisfaction:

Java: The compiler checks for exact matches at compile-time, ensuring that every implemented method is present and correctly typed.
Go: Satisfaction is automatic based on method names and signatures. If a type has the methods the interface expects, it satisfies the interface.

Multiple Inheritance and Composition:

Java: Uses interfaces to simulate multiple inheritance, allowing a class to implement multiple interfaces.
Go: Prefers composition, encouraging developers to build small, focused interfaces and combine them as needed.

When to Choose Which Approach

Choose Java Interfaces When:

You need clear, strict contracts with enforced method signatures.
You are building large, enterprise-grade systems where consistency and predictability are critical.
You want to use design patterns like Dependency Injection (DI) and Inversion of Control (IoC) that benefit from explicit interfaces.

Choose Go Interfaces When:

You want more flexibility and less boilerplate code.
You are building microservices, APIs, or simple, fast services.
You want to take advantage of Go’s simple concurrency model without the overhead of explicit type declarations.
You prefer composition over inheritance for code reuse and design simplicity.

Conclusion

Both Java and Go have powerful, but very different approaches to interfaces. Java’s explicit interfaces provide clarity and structure, making them ideal for large, complex projects. Go’s implicit approach keeps things simple and flexible, making it a great choice for rapid development and microservices. Understanding these differences can help you write better, more maintainable code, no matter which language you choose.

Inside Out, Outside In: Our Topsy-Turvy Tech World

Samarth Gambhir — Mon, 03 Mar 2025 07:08:23 +0000

This is a submission for the Future Writing Challenge: How Technology Is Changing Things.

Additional Prize Categories: Explain Like I'm Five

Dear friend,

It's like our world got turned upside-down and inside-out at the same time! Remember we used to put our pocket money in piggy banks and wallets stuffed with paper money? Those physical dollars have jumped inside our computers and phones! They've become invisible digital coins that zoom through the air like magic butterflies. Our money has become like the money we used to use in our video games! - except now grown-ups use it for real!

That's not it, while our money decided to stay behind the screens of our phones, the computer people were crawling OUT of our screens! The AI friends who used to live trapped behind glass are now having real bodies and walking around in our world! It's exactly like in my favorite movie when the cartoon characters step out of the TV and start dancing in the living room!

Isn't that just the silliest, most wonderful mix-up ever? The things we could touch (like quarters and dollar bills) turned into things we can only see (digital coins). And the things we could only see (like computer helpers) turned into things we can touch (like real robots)!

Love and gigantic rainbow robot hugs,
Sam

How to Upload Files to AWS S3 Using Java: A Step-by-Step Guide

Samarth Gambhir — Tue, 22 Oct 2024 11:57:10 +0000

Introduction

Amazon Simple Storage Service (S3) is a powerful and scalable object storage service providing a reliable and cost-effective solution to store and retrieve any amount of data from anywhere on the web. In this article, we will explore how to interact with AWS S3 to upload files using Java and Spring Boot.

Prerequisites

Before diving into the code, ensure you have the following:

An AWS Account: Sign up for an account on the AWS Website
Java Development Environment: Ensure you have Java installed on your machine along with a build tool like Maven or Gradle for dependency management.
Basic Knowledge of Java: Familiarity with Java syntax and programming concepts will be helpful.

Setting Up AWS SDK for Java

To interact with AWS S3 using Java, you'll need the AWS SDK for Java. Here's how to add it to your project:

For Maven: Add the following dependency to your pom.xml file:

<dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-java-sdk-s3</artifactId>
    <version>1.x.x</version> <!-- Replace with the latest version -->
</dependency>

For Gradle: Add the following line to your build.gradle file:

implementation 'com.amazonaws:aws-java-sdk-s3:1.x.x' // Replace with the latest version

Configuring AWS Credentials

To securely interact with AWS S3, you'll need to store your AWS credentials. In this tutorial, we'll use the application.properties file to manage credentials.

First, add the following lines to your application.properties file:

aws.accessKeyId=your-access-key-id
aws.secretKey=your-secret-access-key
aws.region=your-region

Next, in your Java application, you can load these properties and use them to configure the AWS S3 client:

import com.amazonaws.auth.AWSCredentials;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;

import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.AmazonS3ClientBuilder;

@Component
public class S3ClientConfig {

    @Value("${aws.accessKeyId}")
    private String accessKeyId;

    @Value("${aws.secretKey}")
    private String secretKey;

    @Value("${aws.region}")
    private String region;

    public AmazonS3 initializeS3() {
        AWSCredentials credentials = new BasicAWSCredentials(accessKeyId, secretKey);
        return AmazonS3ClientBuilder.standard()
                .withCredentials(new AWSStaticCredentialsProvider(credentials)).withRegion(region).build();
    }
}

Uploading Files to S3

Here is a sample method that demonstrates how to upload a file to AWS S3 using the AmazonS3 client.

import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.model.PutObjectRequest;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.io.File;

@Service
public class S3Service {

    private final AmazonS3 s3Client;

    @Autowired
    public S3Service(S3ClientConfig s3ClientConfig) {
        this.s3Client = s3ClientConfig.initializeS3();
    }

    public void uploadFile(String bucketName, String filePath) {
        File file = new File(filePath);
        if (file.exists()) {
            s3Client.putObject(new PutObjectRequest(bucketName, file.getName(), file));
            System.out.println("File uploaded successfully.");
        } else {
            System.out.println("File not found: " + filePath);
        }
    }
}

uploadFile() Method Breakdown:

Parameters:

bucketName: The name of the S3 bucket to upload the file to.
filePath: The local path to the file being uploaded.

File Creation & Existence Check:

A File object is created from the provided filePath
The method checks if the file exists using file.exists() If the file doesn't exist, it logs an error message.

Uploading the File:

If the file exists, it's uploaded to the S3 bucket using the putObject() method.
Logs a success message if the upload completes successfully.

Conclusion

In this article, we covered the process of uploading files to AWS S3 using Java. We explored how to configure AWS credentials, set up the S3 client using Spring Boot, and wrote a simple method to upload files to your S3 bucket. With this foundation, you can now integrate S3 file uploads into your Java applications seamlessly.

Why Java Doesn’t Support Multiple Inheritance: A Simplified Explanation

Samarth Gambhir — Fri, 27 Sep 2024 07:21:07 +0000

Understanding Multiple Inheritance and the Diamond Problem in Java

Multiple inheritance is a feature in Object Oriented Programming where a class can inherit attributes and methods from more than one parent class. It does sound beneficial but it can lead to ambiguity, especially when a method with same name and same signature is present in both the parent classes. In such cases, resolving which method to call can lead to errors and unintended behavior in the program. This ambiguity is termed as "The Diamond Problem".

In this diagram, Class A is the common ancestor with a speak() method. Class B and Class C both inherit from Class A and override the speak() method. Class D inherits from both Class B and Class C, inheriting two conflicting versions of the speak() method.

Why Java Avoids Multiple Inheritance

Java was designed with a focus on simplicity and ease of understanding. By eliminating multiple inheritance, the language avoids complexities that can confuse developers.
without multiple inheritance, the class hierarchy is easier to follow and maintain.

Interfaces: A Safer Alternative

A class can implement multiple interfaces, allowing it to inherit method signatures from various sources. Since interfaces only contain method declarations, any class implementing an interface must provide its own logic for the functions declared in that interface. Here's an example:

interface InterfaceA {
    void speak();
}

interface InterfaceB {
    void speak();
}

class MyClass implements InterfaceA, InterfaceB {

    // Single implementation for the speak method
    public void speak() {
        System.out.println("Hello World !");
    }
}

In this case, even if a class implements two interfaces that contain methods with the exact same name and signature, it only needs to define the method once, eliminating any ambiguity.

Conclusion

In conclusion, by avoiding multiple inheritance, Java does limit the developers to some extent but improves simplicity and reduces ambiguity. By utilizing interfaces, Java enables method reuse without the complications of conflicting methods, promoting cleaner and more maintainable code.