Forem: Parth Kamal

System design terms

Parth Kamal — Mon, 17 Nov 2025 09:40:26 +0000

scalibility → Ability of the system to handle increased load by adding resources (horizontal/vertical scaling).
stability → Predictable behavior under fluctuating or sudden load; avoids meltdown and cascading failures.
availability → Percentage of time a system is up and reachable (uptime metric).
durability → Guarantees that once data is written, it will never be lost—even during failures.
fault tolerance → Ability of the system to continue operating even when components fail. → Fault tolerance improves availability but is not equal to availability.
reliability → Ability of the system to operate correctly and failure-free over time. → Measured by MTBF (Mean Time Between Failures). → Reliability ≠ availability metric.
consistency → Every read returns the most recent write (for strong consistency). → Or follows the defined consistency model (eventual, causal, etc.).
latency → Time taken for the system to respond to a request.
performance → Performance = how fast the system processes work (latency + throughput + resource usage).
efficiency → How optimally the system uses CPU, memory, network, storage.
maintainability → How easy it is to update, debug, refactor, and extend the system.
observability → Ability to understand the internal state of a system from its external outputs (logs, metrics, traces). Not just logging
security → Protecting the system against unauthorized access, misuse, attacks, and data breaches.

Understanding the `$` Symbol in Bash Scripting

Parth Kamal — Fri, 14 Nov 2025 21:26:57 +0000

In Bash, the $ symbol appears everywhere — and for good reason.
Whether you’re working with variables, command substitution, arithmetic, or script arguments, $ is the gateway that lets you access underlying values.
Once you understand how it behaves, the shell becomes significantly easier to navigate.

What `$` Actually Does

At the core, $ instructs Bash to:

“Expand this into its value.”

This applies consistently across variables, commands, expressions, and special parameters.
A single rule powering multiple forms of expansion.

Key Uses of `$` in Bash

1. Working with Variables

name="Parth"
echo "$name"

2. Quoting to Avoid Word Splitting

msg="Hello World"
echo $msg      # splits into separate words
echo "$msg"    # preserves the original string

3. Using `${var}` When Appending Text

file="log"
echo "${file}.txt"

4. Capturing Command Output

today=$(date)
count=$(ls -1 | wc -l)

echo "$today"
echo "$count"

5. Arithmetic Expansion

echo $((3 + 5))
n=4
echo $((n * 2))

6. Special Shell Parameters Every Script Uses

Exit code of the previous command

echo $?

PID of the current shell

echo $$

Script name

echo $0

Positional parameters (arguments passed to the script)

Running:

./script.sh apple banana cherry

Inside the script:

echo $1    # apple
echo $2    # banana
echo $3    # cherry
echo $#    # total arguments (3)
echo "$@"  # all arguments as separate values
echo "$*"  # all arguments as one combined string

7. Indirect and Meta Expansions

sleep 5 &
echo $!    # PID of the most recent background job

user_1="Alice"
user_2="Bob"
echo ${!user_*}   # prints variable names starting with 'user_'

8. A Common Beginner Error

result = $((1 + 2))    # incorrect — spaces make this invalid
result=$((1 + 2))      # valid form

The Underlying Principle

All these examples rely on one idea:

$ transforms a reference into the evaluated value behind it.

$name → gets a variable’s value
$(command) → gets command output
$(( )) → gets an arithmetic result
$0 → gets the script’s name
$1, $2, … → get argument values
$? → gets the previous command’s exit code

A single symbol enabling a wide spectrum of expansions.

Conclusion

Understanding the role of $ brings clarity to Bash scripting.
Once this expansion model clicks, the shell feels far more structured and logical.

Arithmetic Expansion in Bash: The Little Feature That Makes Your Scripts Cleaner

Parth Kamal — Fri, 14 Nov 2025 21:17:24 +0000

If you’ve written Bash for any amount of time, you’ve probably bumped into situations where you needed a quick calculation. Maybe it was a loop counter, maybe file-size math, or maybe you were just trying to add two numbers inside a shell script without summoning half the Unix toolchain.

Most of us start with expr, and then eventually escape into awk or bc when things get messy. It works… but it always feels heavier than it needs to be.

There’s a simpler tool, always sitting inside the shell, always ready: arithmetic expansion.

It’s one of those Bash features that quietly improves the quality of your scripts without making a big deal about it.

The Core Idea

Bash lets you evaluate math directly inside your script using the syntax:

$(( expression ))

It sounds small, but the convenience and readability it adds is real. You write what you mean, and Bash gives you back the evaluated result.

Example:

echo $(( 2 + 3 ))

That’s it. No external commands, no fuss.

Why This Matters More Than It Seems

People underestimate arithmetic expansion because it’s small. But in scripting, the small things add up.

It makes loops easier to read.
It removes awkward expr invocations.
It avoids unnecessary process spawning.
It keeps conditions compact.
It lets your script feel like code, not plumbing.

Once you start using it, you don’t go back.

A More Natural Way of Writing Math

Here’s a simple example that shows how natural it feels:

a=10
b=20
sum=$((a + b))
echo "$sum"

You don’t need quotes. You don’t need $ inside the expression. Bash understands what you want.

Even better, you’re not forced to follow awkward spacing rules. Both of these work:

$((a+b))
$(( a + b ))

Use whatever reads nicely in your script.

What You Can Actually Do With It

All the basic arithmetic operators work exactly the way you expect:

addition (+)
subtraction (-)
multiplication (*)
integer division (/)
modulo (%)
exponentiation (**)

A quick example:

echo $((5 * 3 ** 2))
# Outputs: 45

Bash also supports increment, decrement, and compound assignments — the stuff that makes loops and counters feel nice:

((i++))
((x += 10))

This is where arithmetic expansion starts to blend naturally into your scripting style.

Cleaner Conditions

One of the highest-impact uses of arithmetic expansion is inside if statements. It replaces the traditional test syntax (-gt, -lt, etc.) with something more readable:

x=5
if (( x > 3 )); then
  echo "x is greater than 3"
fi

Suddenly, your code looks like code again.

A Few Real-World Cases

Here are some examples where arithmetic expansion quietly reduces friction:

Loop counters:

for ((i=1; i<=5; i++)); do
  echo "Iteration: $i"
done

Calculating file sizes:

size=$(stat -c%s file.txt)
echo $((size / 1024))" KB"

Tiny inline math functions:

add() {
  echo $(( $1 + $2 ))
}

Working with counts:

count=$(ls -1 | wc -l)
echo $((count * 2))

These are the kinds of places where scripts usually fill up with tiny noisy utilities. Arithmetic expansion keeps things centered, simple, and local.

The Classic Mistake to Avoid

There’s one error everyone makes at least once:

result = $((1 + 2))   # ❌ Wrong

Bash interprets this as:
“run the command result with arguments = and 3.”

The fix is simple:

result=$((1 + 2))

No spaces around =.
Small rule, big habit.

Why It's Actually Faster

This part surprises people: $(( )) is not just cleaner — it’s faster.

Commands like expr, awk, and bc create new processes. Arithmetic expansion happens inside Bash itself. When you’re in a loop with thousands of iterations, the performance difference becomes noticeable.

This is one of the reasons DevOps engineers and shell power-users rely on it so heavily.

The Bottom Line

Arithmetic expansion is one of those hidden gems in Bash — small, elegant, and surprisingly powerful. You don’t need it to write shell scripts, but once you start using it, your scripts become more readable, more consistent, and a little bit more enjoyable to write.

It’s not flashy.
It’s not complicated.
But it makes your scripts feel like they were written intentionally.

And that’s the whole point.

Understanding the Prototype Design Pattern in Java

Parth Kamal — Fri, 07 Nov 2025 13:45:17 +0000

In real-world software development, creating new objects can often be costly or time-consuming — especially when they involve heavy initialization logic, database connections, or complex configurations. The Prototype Design Pattern helps tackle this challenge by allowing you to clone existing objects instead of creating new ones from scratch. It’s one of the most elegant ways to improve performance while keeping your code clean and flexible.

What is the Prototype Pattern?

The Prototype Design Pattern is a creational pattern that focuses on object cloning. Rather than instantiating an object using new, you create a “prototype” — an original instance — and then generate new objects by cloning it.

This pattern becomes extremely useful when object creation is expensive, or when you want to decouple the client code from specific class implementations. Essentially, it shifts the focus from constructing to copying.

Key Idea Behind Prototype

At the core of the pattern lies a clone() method that allows an object to produce its copy. This method is defined in a Prototype interface, and each class implementing it decides how deep the copy should be — shallow or deep.

This simple idea offers tremendous flexibility, especially when combined with a Prototype Registry, which acts as a centralized store for predefined prototypes that can be cloned anytime.

Example Implementation

Let’s look at a simple Java implementation to understand it better:

import java.util.HashMap;
import java.util.Map;

interface Prototype {
  public Prototype clone();
}

class Employee implements Prototype {
  private String name;
  private String department;

  Employee(String name, String department) {
    this.name = name;
    this.department = department;
  }

  public Employee clone() {
    return new Employee(name, department);
  }

  public String getName() { return this.name; }
  public String getDepartment() { return this.department; }
}

class PrototypeRegistry {
  private static Map<String, Prototype> registry = new HashMap<>();

  public static void register(String key, Prototype prototype) {
    registry.put(key, prototype);
  }

  public static Prototype getPrototype(String key) {
    return registry.get(key).clone();
  }
}

public class HelloWorld {
  public static void main(String[] args) {
    Employee employee = new Employee("parth", "me");
    PrototypeRegistry.register("emp", employee);
    Employee clonedEmployee = (Employee) PrototypeRegistry.getPrototype("emp");

    System.out.println(clonedEmployee.getName());
  }
}

How It Works

Here, the Prototype interface defines a single method clone(), which the Employee class implements. Instead of creating a new Employee object directly using new, we simply clone an existing prototype.

The PrototypeRegistry holds a collection of registered prototypes. When we call getPrototype(), it retrieves and clones the prototype, returning a fresh copy each time.

This structure helps maintain clean separation between the object creation logic and the client code, leading to more modular and scalable design.

Shallow Copy vs Deep Copy — The Core Difference

When it comes to cloning, not all copies are the same. The Prototype pattern can be implemented in two ways depending on how you copy the object’s internal data:

Shallow Copy – Copies only the object’s primitive fields and keeps references to the same inner objects.
If the cloned object modifies those inner objects, it affects the original too.
Deep Copy – Creates a completely independent clone, including copies of nested or referenced objects.
This ensures that changes in the clone don’t affect the original.

Here’s an example to make the difference clear:

class Department {
  String deptName;
  Department(String deptName) { this.deptName = deptName; }
}

class Employee implements Prototype {
  private String name;
  private Department department;

  Employee(String name, Department department) {
    this.name = name;
    this.department = department;
  }

  // Deep copy
  public Employee clone() {
    return new Employee(name, new Department(department.deptName));
  }

  public String getName() { return name; }
  public String getDepartment() { return department.deptName; }
}

In this version, the clone creates a new Department object instead of reusing the existing reference — this is a deep copy.
So if you modify the cloned object’s department, the original remains unaffected.

Why Deep Copy Matters

In real applications, most objects contain references to other objects — lists, maps, or nested entities. Using a shallow copy in such cases can lead to unexpected side effects where changes in one clone ripple back to the original.

That’s why understanding when to use deep vs shallow copy is crucial in applying the Prototype pattern correctly. Deep copy ensures true independence of clones, at the cost of slightly higher memory and CPU usage.

Advantages of Prototype Pattern

Faster Object Creation: Reduces the overhead of expensive initialization.
Decoupled Design: The client doesn’t need to know the exact class being cloned.
Runtime Flexibility: Prototypes can be added or modified dynamically.
Supports Deep Cloning: Makes it possible to produce fully independent copies.

Real-World Analogy

Think of the Prototype pattern like using document templates in Word or Google Docs. You set up one base document (prototype), and every new document you create from it is a copy. You don’t rebuild it from scratch each time. Similarly, in code, instead of reconstructing complex objects, you just clone the prototype and tweak what you need.

When to Use

You should consider using the Prototype pattern when:

Object creation is complex or resource-heavy.
You frequently need objects similar to existing ones.
You want to avoid tight coupling between client code and concrete classes.
You need to preserve initial states or configurations across multiple instances.

Final Thoughts

The Prototype Design Pattern is not just about copying objects — it’s about copying efficiently and safely. It shines in scenarios where object creation is expensive or repetitive, and offers the flexibility to choose between shallow and deep copies based on your needs.

By combining a Prototype Registry with custom cloning logic, you can build scalable, high-performance systems that reuse existing data without redundancy — keeping your code both efficient and elegant.

Builder Design Pattern in Java

Parth Kamal — Fri, 07 Nov 2025 12:54:30 +0000

The Builder Design Pattern is one of the most widely used creational patterns in Java. It helps in constructing complex objects step-by-step, especially when a class has many optional parameters or configurations. While the traditional builder pattern is enough for most use cases, there’s a useful variation that combines the Classic Builder approach with a Director, bringing more flexibility and structure to the object creation process.

Understanding the Need

Suppose you are building a Computer object with multiple fields like CPU, RAM, Storage, and GPU. Some computers might be gaming PCs, others might be office machines, and each of them has different configurations. If you try to use constructors for all these variations, you’ll end up with too many overloaded constructors, making your code confusing and error-prone. The Builder pattern helps you build these objects in a readable, step-by-step manner, and the Director helps you define reusable configurations for specific types of objects.

Classic Builder Implementation

Let’s start with the classic nested builder version of the Computer class.
Here, we define a static inner Builder class that provides setter methods for each field and a build() method that returns the constructed object.

class Computer {
  private String cpu;
  private String ram;
  private String storage;
  private String gpu;

  private Computer(Builder builder) {
    this.cpu = builder.cpu;
    this.ram = builder.ram;
    this.storage = builder.storage;
    this.gpu = builder.gpu;
  }

  public static class Builder {
    private String cpu;
    private String ram;
    private String storage;
    private String gpu;

    public Builder setCpu(String cpu) {
      this.cpu = cpu;
      return this;
    }

    public Builder setRam(String ram) {
      this.ram = ram;
      return this;
    }

    public Builder setStorage(String storage) {
      this.storage = storage;
      return this;
    }

    public Builder setGpu(String gpu) {
      this.gpu = gpu;
      return this;
    }

    public Computer build() {
      return new Computer(this);
    }
  }

  @Override
  public String toString() {
    return "Computer [CPU=" + cpu + ", RAM=" + ram + ", Storage=" + storage + ", GPU=" + gpu + "]";
  }
}

In this setup, you can create different computer objects by chaining method calls:

Computer gamingPC = new Computer.Builder()
    .setCpu("Intel i9")
    .setRam("32GB")
    .setStorage("1TB SSD")
    .setGpu("RTX 4090")
    .build();

This approach works well when each object configuration is manually built in client code.
But what if we need to create standard configurations repeatedly, like gaming PCs, office PCs, or budget laptops?
That’s where the Director comes in.

Introducing the Director

The Director is responsible for managing the construction process. It defines the sequence and configuration of the building steps, while the Builder handles the actual object creation.
In our example, the Director will provide ready-made build methods for different types of computers.

class ComputerDirector {

  public Computer buildGamingComputer() {
    return new Computer.Builder()
        .setCpu("Intel i9")
        .setRam("32GB")
        .setStorage("1TB SSD")
        .setGpu("RTX 4090")
        .build();
  }

  public Computer buildOfficeComputer() {
    return new Computer.Builder()
        .setCpu("Intel i5")
        .setRam("16GB")
        .setStorage("512GB SSD")
        .setGpu("Integrated Graphics")
        .build();
  }

  public Computer buildBudgetComputer() {
    return new Computer.Builder()
        .setCpu("Intel i3")
        .setRam("8GB")
        .setStorage("256GB SSD")
        .setGpu("Integrated Graphics")
        .build();
  }
}

Using the Director in the Client Code

Now, the client doesn’t need to remember configurations.
They just need to tell the Director what kind of computer they want, and the Director uses the Builder to create it.

public class Main {
  public static void main(String[] args) {
    ComputerDirector director = new ComputerDirector();

    Computer gamingPC = director.buildGamingComputer();
    Computer officePC = director.buildOfficeComputer();
    Computer budgetPC = director.buildBudgetComputer();

    System.out.println(gamingPC);
    System.out.println(officePC);
    System.out.println(budgetPC);
  }
}

Output:

Computer [CPU=Intel i9, RAM=32GB, Storage=1TB SSD, GPU=RTX 4090]
Computer [CPU=Intel i5, RAM=16GB, Storage=512GB SSD, GPU=Integrated Graphics]
Computer [CPU=Intel i3, RAM=8GB, Storage=256GB SSD, GPU=Integrated Graphics]

How the Director Complements the Builder

The combination of Director + Builder gives you the best of both worlds.
The Builder provides flexibility for creating custom objects, while the Director defines reusable construction recipes.
This makes your code more modular, reduces duplication, and separates how an object is built from what the final configuration is.

In large-scale systems, the Director can even take different builder implementations (for example, GamingBuilder, OfficeBuilder, ServerBuilder), allowing full polymorphism.
In simpler terms, the Director knows the process, while each Builder knows the details.

Key Takeaways

The Director with Classic Builder variation is a clean and structured approach when your application needs multiple standardized object configurations.
It maintains readability, improves code reuse, and follows the Single Responsibility Principle — the Builder builds, and the Director directs.

So the next time you’re creating different variants of complex objects, think beyond the simple builder — let the Director take control of the construction process, while your Builder focuses purely on object assembly.

Abstract Factory Pattern — Designing Consistent Object Families

Parth Kamal — Fri, 07 Nov 2025 11:47:59 +0000

In software design, one recurring problem is how to create related objects without exposing their concrete classes everywhere in the codebase. The Abstract Factory pattern solves this problem elegantly. It allows you to produce families of related or dependent objects while keeping the client code unaware of the specific implementations. In short, it gives you flexibility, consistency, and clean separation between object creation and usage.

🧠 The Core Idea

The Abstract Factory Pattern provides an interface for creating families of related objects without specifying their concrete classes. Think of it as a “factory of factories” — a higher-level factory that groups together multiple factories responsible for producing related components.

Imagine you’re building a cross-platform GUI library that should support both Windows and Mac environments. Each platform has its own style of buttons and checkboxes, and you want the same client code to work with both families of components seamlessly. You don’t want dozens of if-else checks like if (os == "Windows") new WindowsButton() scattered around. The Abstract Factory pattern makes that unnecessary.

🧱 Step-by-Step Example

Let’s break it down.

We first define the abstract products — interfaces that declare how our UI components behave.

interface Button {
    void paint();
}

interface Checkbox {
    void render();
}

Next, we define the concrete products, each belonging to a family. For example:

class WindowsButton implements Button {
    public void paint() {
        System.out.println("Rendering a Windows-style button");
    }
}

class MacButton implements Button {
    public void paint() {
        System.out.println("Rendering a Mac-style button");
    }
}

class WindowsCheckbox implements Checkbox {
    public void render() {
        System.out.println("Rendering a Windows-style checkbox");
    }
}

class MacCheckbox implements Checkbox {
    public void render() {
        System.out.println("Rendering a Mac-style checkbox");
    }
}

Now we define the abstract factory interface, which provides creation methods for the entire product family:

interface GUIFactory {
    Button createButton();
    Checkbox createCheckbox();
}

Each concrete factory implements this interface and produces its own family of components:

class WindowsFactory implements GUIFactory {
    public Button createButton() { return new WindowsButton(); }
    public Checkbox createCheckbox() { return new WindowsCheckbox(); }
}

class MacFactory implements GUIFactory {
    public Button createButton() { return new MacButton(); }
    public Checkbox createCheckbox() { return new MacCheckbox(); }
}

The client code depends only on the interfaces, not on the actual implementations:

class Application {
    private Button button;
    private Checkbox checkbox;

    public Application(GUIFactory factory) {
        button = factory.createButton();
        checkbox = factory.createCheckbox();
    }

    public void render() {
        button.paint();
        checkbox.render();
    }
}

public class Demo {
    public static void main(String[] args) {
        GUIFactory factory;
        String os = "Windows"; // could be read from config

        if (os.equalsIgnoreCase("Windows")) {
            factory = new WindowsFactory();
        } else {
            factory = new MacFactory();
        }

        Application app = new Application(factory);
        app.render();
    }
}

Output:

Rendering a Windows-style button
Rendering a Windows-style checkbox

🎯 Why This Pattern Matters

The client code never touches any concrete class like WindowsButton or MacCheckbox. It only knows the interfaces — Button, Checkbox, and GUIFactory. This is the essence of dependency inversion: the high-level code depends only on abstractions, not on details.

Notice that each concrete factory is tightly coupled to its product family — for example, WindowsFactory knows about WindowsButton and WindowsCheckbox. At first glance, this looks like a drawback, but it’s intentional and necessary. The tight coupling is localized inside the factory, so it doesn’t spread across your application. The rest of your system remains decoupled and flexible.

This design also ensures consistency among related products. Since both Button and Checkbox come from the same factory, you’ll never end up with a Windows button next to a Mac checkbox. The Abstract Factory enforces that consistency by design.

🧩 Comparing with Factory Method

The Factory Method pattern focuses on creating one type of product and uses inheritance — subclasses decide which class to instantiate.
The Abstract Factory, on the other hand, focuses on creating families of related products and uses composition — the factory contains multiple creation methods. In large systems, both patterns often coexist: each method inside the Abstract Factory might itself be implemented using the Factory Method.

To simplify:

Factory Method = one product, decided by subclass
Abstract Factory = multiple related products, grouped by family

🧠 When to Use Abstract Factory

Use it when you need to create a consistent set of related objects that should work together.
Typical cases include:

Building cross-platform UI components (Windows, Mac, Web, etc.)
Managing multiple themes (Light/Dark mode components)
Creating plugin systems where each plugin provides its own compatible product set

Avoid it when you only need to create one object type — the Factory Method pattern will be simpler.

🪶 Key Takeaways

The Abstract Factory pattern helps you encapsulate object creation, preserve consistency, and isolate dependencies. The tight coupling between a concrete factory and its products is deliberate — it keeps all creation logic contained, ensuring that clients remain independent of implementation details.

Whenever you’re designing a system where multiple objects must belong to the same family or theme, Abstract Factory is your go-to tool. It lets you switch entire object families without touching client code, keeping your design clean, extensible, and consistent across environments.

Would you like me to add a UML diagram-style ASCII illustration (showing factories and product families) right after the example section? It makes the relationships visually clear for readers.

Composition vs Inheritance — The Practical Guide Every Developer Should Know

Parth Kamal — Fri, 07 Nov 2025 08:59:40 +0000

Favor Composition Over Inheritance

Every developer hears this advice at some point: “Favor composition over inheritance.”
But very few really internalize when and why that matters. Inheritance and composition are both powerful tools in object-oriented design, but they serve different purposes. The key is knowing when to use each — and when not to.

Understanding the Core Idea

At its heart, the difference comes down to the kind of relationship you want to model.
Inheritance represents an “is-a” relationship — for example, a Car is a Vehicle. It means the subclass should conceptually be a specialized form of the parent.
Composition, on the other hand, models a “has-a” relationship — for example, a Car has an Engine. Here, one class simply contains or uses another to get its work done.

This distinction seems simple, but it changes how your code evolves over time.

When to Use Inheritance

Inheritance isn’t bad — it’s just easily abused. It’s the right choice when the relationship between classes truly reflects the idea of specialization. If the child class logically “is” the parent type, and you expect this relationship to remain stable, inheritance fits naturally.

For instance, a Car extending a Vehicle, or a Circle extending an abstract Shape class, makes sense. In both cases, the child shares a clear structure and purpose with the parent, while still providing its own implementation details.

Inheritance also shines when you need polymorphism — treating different subclasses under a single unified interface. A list of Shape objects, for example, can hold circles, rectangles, or triangles, all of which can respond to the same area() method.

Finally, inheritance is often used when frameworks or libraries enforce it, such as when extending HttpServlet or Activity in Java. In such cases, it’s part of the system’s design contract.

However, you should avoid inheritance when your goal is merely to reuse code, when the base class might change frequently, or when the relationship doesn’t make real-world sense. Extending a class just because you need a few of its methods leads to tight coupling and fragile hierarchies that are difficult to maintain.

When to Use Composition

Composition is the better choice when you want flexibility, loose coupling, and reusability. Instead of saying “X is a Y,” composition says “X uses Y.” That subtle change allows you to modify, replace, or combine behaviors without touching your core classes.

Let’s take a simple example. Instead of creating separate subclasses for PetrolCar, DieselCar, and ElectricCar, you can let the Car class hold an Engine object. By defining an Engine interface and implementing PetrolEngine, DieselEngine, and ElectricEngine, the Car can use any of them interchangeably. Even better, you can switch the engine type at runtime without changing the class structure.

This approach keeps your code modular and open to extension. You can add new types of engines later without modifying the Car class at all. Composition also helps encapsulate details — the Car doesn’t need to know how the engine starts; it just delegates that responsibility to the engine object.

The Example: Car and Engine

Here’s what that looks like in practice.

Using inheritance

class Car { 
    void start() {} 
}

class PetrolCar extends Car {
    void start() { 
        System.out.println("Starting petrol car"); 
    }
}

class DieselCar extends Car {
    void start() { 
        System.out.println("Starting diesel car"); 
    }
}

This works, but quickly becomes messy. Every new engine type requires a new subclass, and the code becomes rigid and repetitive.

Using composition

interface Engine { 
    void start(); 
}

class PetrolEngine implements Engine {
    public void start() { 
        System.out.println("Starting petrol engine..."); 
    }
}

class DieselEngine implements Engine {
    public void start() { 
        System.out.println("Starting diesel engine..."); 
    }
}

class Car {
    private Engine engine;

    Car(Engine engine) { 
        this.engine = engine; 
    }

    void start() { 
        engine.start(); 
    }

    void setEngine(Engine engine) { 
        this.engine = engine; 
    }
}

Now, the Car class doesn’t care what kind of engine it has — it just knows that whatever engine it holds can start. You can pass a PetrolEngine, change it to a DieselEngine later, or even introduce a new ElectricEngine class in the future without touching the Car implementation.

Choosing Between Them

Inheritance creates tight coupling between classes. Changes in the parent can easily ripple through to all children. It’s good for modeling stable “type” relationships but becomes a burden when behavior needs to evolve. Composition, by contrast, keeps classes independent. It’s easier to test, extend, and refactor. It’s the preferred choice for most cases where you want flexibility and code reuse rather than a rigid type hierarchy.

A simple way to remember it is this:
Use inheritance when you’re defining what something is.
Use composition when you’re defining what something does or has.

Final Takeaway

Both inheritance and composition have their place in good design. Inheritance gives you structure and identity, while composition gives you flexibility and adaptability. The most maintainable systems tend to combine both — using inheritance for stable abstractions and composition for dynamic behavior.

In short:

Use inheritance for identity. Use composition for flexibility.

Mindset while getting things done in software development

Parth Kamal — Sat, 27 Jul 2024 16:13:22 +0000

Absolutely, getting things done productively in software development is crucial for a fulfilling and stress-free life as a software engineer! Being able to execute tasks effortlessly, without any toll on your mental state, is key. Working productively will eliminate the possibility of stressful situations most of the time, and if they do come, you'll be better equipped to handle them.

Understanding the context, let's get back to the main content.

Iterative Development Methodology: Yeah, it may seem like a big complex term. Let's break it down. It simply means doing the simple small things. Obviously, they should be working. Just spend time on making an atomic function (let's say summing two numbers) which will be the building block of your overall goals/task/feature, etc.

Improve the quality of the code over time. Improve the quality of your code by continuous iteration of code refactoring.

Reusable Functions (Paradigm of Functional Programming): Now after creating an atomic function, we are heading into developing bigger blocks!
Complications of Overdesign: Never try to overdesign before doing anything! People fantasize about getting all the design and predicting all the cases in one hand (design the whole thing before developing one). It can never be perfect. Making a barebone design (working) solution and improving/modifying it through iterative development is the key.
DRY (Principle): Understanding the concepts and really applying them (through try and test) is crucial. What I mean by this is that developing the code really involves working in the present. You should be able to analyze the code continuously and observe the possibility of repetition. As soon as you see it, make it scalable (yeah, I mean the design/paradigm, like object-oriented, functional—whatever the case, depends on your choice). If nothing comes to mind, make a reusable function out of that.
Importance of Working Solution: Working code is ultimately praised. A simple, working code is always praised. :)

Directory Structure : Selenium Automation

Parth Kamal — Tue, 18 Jun 2024 03:47:11 +0000

if you are using selenium webdriver , to write automation tests for your javascript application , tracing the requirement , and writing functional tests for it , may end up getting a lot of tests, and each set of tests, may become very difficult to manage, because we have to write code for each ui interaction in each test.

soon you will find that managing test code is in itself a big task. soon you will start finding ways to modularize tests in selenium .

modularizing tests in selenium webdriver in javascript , involved organinizing your test code into reusable, maintainable and scalable components.

some of the common practices which are used to modularize are;

page object model - pom is a desing pattern that helsps to create an object repository for web ui elements.
test data management - keep your test data separate from your test scripts.
utility functions - for common actions across the whole ui lik , logging in , taking screenshots, or waiting for elements.
test suites - here we will write the code for tests.
configuration - config files to manage, the environment variables, global variables, and configuration, which are common across all the tests, for eg; base url.
logging and reporting - integrating loggign and reporting to keep track of test execution and results.

C++ Best Practices : Naming Conventions

Parth Kamal — Sun, 16 Jun 2024 19:17:23 +0000

There are various popular naming conventions which are common among various languages, the relevance of these conventions comes from , the legacy which they hold and other factors like readability, purpose, programming cababilities, for example , we most follow camelcase for java, for c++ which comes with great capabilities, we use lowercase with underscores, most of the time.

why important ?

there are two main advantage which comes with this,

consistency in the code base - especially you are contributing open source.
readability - with common coding style and following it becomes easy for you to understand the code.

C++ naming convention -

Variables - lowercase with underscores,
Functions - lower case with underscores,
Classes - Pascal case
Constants - uppercase with underscores.

In gist : following the best practices , and guidelines, make the job easier for everyone.