DEV Community: Atharv Rawat

Check out my blog on when and why to choose composition over inheritance!

Atharv Rawat — Sun, 05 Jul 2026 11:12:48 +0000

Atharv Rawat

Jul 5

Composition over Inheritance

#cpp #oop #designpatterns #inheritance

8 min read

Composition over Inheritance

Atharv Rawat — Sun, 05 Jul 2026 11:11:43 +0000

C++ has a lot of double-edged swords. These features abstract the process of turning the sharp edge on yourself, so that you can destroy yourself with greater efficiency.

Well, I threw away one of those swords in time, and its name was Inheritance. It's a powerful tool, no doubt, but it was overkill ;) for my needs.

Inheritance showed up neatly as I was building my first proper C++ game. For now, my definition of proper is a console game with gravity, collision detection, and ASCII for those high quality textures. My game is simple - Balls fall, you catch, score up. With powerups and debuffs to spice things up.

Initially, OOP was my best friend. I effortlessly created a Fallable class that my balls and powerups would inherit. This class defined all the common properties and behaviours, like current x and y positions, collision detection logic, etc. My Ball and PowerUp classes inherited this. The reason inheritance attracted me was its intuitiveness. Examples like Mammal-is-Animal and Dog-is-Mammal sat right with me. Unfortunately, I forgot the significance of Car-has-Engine (hint).

Anyway, since the falling and catching logic was fairly straightforward (I owe this confidence to OneLoneCoder), I moved on to creating the actual powerups.

Before I proceed, it'd be best if you see some of the relevant code so that you know exactly what is going on -

The Fallable class:

class Fallable {
protected:
    float coordX;
    float coordY;
    float speedX;
    int speedY;
    bool inScene;
    short skin;

public:
    Fallable(int x, float y, int speedY, short skin)
        : coordX(x), coordY(y), speedX(0), speedY(speed), inScene(true), skin(skin) {}

    virtual void update(float elapsedTime) = 0;
    virtual void draw(wchar_t* screen, int nScreenWidth) = 0;

    // This function triggers something on collision. Effect upon activation.
    virtual void on_collision(GameManager& game, bool hitBar) = 0;

    bool is_collision_bar(int barX, int barLevel, int barWidth) {
        // crazy advanced logic here...

    bool is_in_scene() { 
        // damn bro let him cook..
        // actual code: return this->inScene; (lol)
    }  

    virtual ~Fallable() {}
};

on_collision() is virtual here because balls and powerups do different things when they collide with something. So the children will define the actual behaviour.

The PowerUp class that inherits Fallable:

class PowerUp : public Fallable {
protected:
    int duration;
    double elapsedTime;
    bool isActive;

public:
    PowerUp(int speed, short skin, int duration)
        : Fallable(randomNumGenerator(false, 1, nScreenWidth - 2), 
            0, speed, skin), duration(duration), isActive(false), elapsedTime(0) {

    }

    virtual void deactivate(GameManager& game) = 0;

    // More methods go here...
};

It looks quite rosy, right? PowerUp rightfully inherits Fallable while adding some relevant data and behaviour of its own, like duration, elapsedTime and state. Notice that PowerUp, just like Fallable is an abstract class, meaning that this blueprint cannot be applied directly, as there is data and behaviours that haven't been defined yet. PowerUp does nothing about Fallable's on_collision() virtual function because naturally, the effect-upon-collision is totally dependent on the kind of powerup.

It goes without saying, but I want you to understand that this design set up the need for another layer of inheritance. Since each powerup has different behaviours upon activation, I had to write another set of actual powerup classes that inherited PowerUp.

That is what I did here:

class PUdoubleBar : public PowerUp {
public:
    PUdoubleBar() : PowerUp(13, 0x002B, 7) {}

    void on_collision(GameManager& game, bool hitBar) {
        if (hitBar && game.bar.nWidth <= 20) {
            isActive = true; inScene = false; elapsedTime = 0;
            game.bar.transform(2);
        }
    }

    void deactivate(GameManager& game) {
        if (game.bar.nWidth > 10) game.bar.transform(0.5);
    }

    ~PUdoubleBar() {}
};

// and again
class PUdoublePoints : public PowerUp {
public:
    PUdoublePoints() : PowerUp(13, 0x0058, 10) {}

    void on_collision(GameManager& game, bool hitBar) {
        if (hitBar) {
            isActive = true; inScene = false; elapsedTime = 0;
            game.nScoreMultiplier = 2;
        }
    }

    void deactivate(GameManager& game) {
        if (game.nScoreMultiplier >= 2) game.nScoreMultiplier /= 2;
    }

    ~PUdoublePoints() {}
};

// aaaand againnn :(
class PUenhancedSpeed : public PowerUp {
public:
    PUenhancedSpeed() : PowerUp(13, 0x2192, 7) {}

    void on_collision(GameManager& game, bool hitBar) {
        if (hitBar) {
            isActive = true; inScene = false; elapsedTime = 0;
            game.bar.nSpeed *= 1.25;
        }
    }
    void deactivate(GameManager& game) {
        game.bar.nSpeed /= 1.25;
    }

    ~PUenhancedSpeed() {}
};

I can guarantee that you had one of these three reactions just now:

You either did not see anything wrong with this.
Or, you sensed something was wrong. There seems to be a bunch of repetition.
Orrrr, you just took your head in your hands and shed a tear or two.

Whatever reaction you just had, you are right. Think about which problems or better, which patterns you can spot here before proceeding.

Firstly, the constructors used in the final powerups add nothing to their data or functionality. I am just calling PowerUp's constructor. In fact, I am initializing different values for speed, skin and duration within the new classes. That's pretty bad, because that is exactly what the PowerUp constructor is meant to do.

Secondly, each powerup has exactly two methods that define custom behaviour - on_collision() (effect upon activation. I know the name sucks), and deactivate().

Finally, and perhaps most importantly, all of them change something within the GameManager class upon activation. And for our purpose, this detail is crucial: that is all they do.

All of these problem patterns point (a lil' alliteration) to the same solution. Let's see how they help us figure it out.

(1) The use of the exact same constructors is the first hint of redundancy. This already tells us that inheritance is not providing us with additional value. Maybe there is a way to use PowerUp directly?

(2) Each powerup having only two functions that define custom behaviour. If only there were a way to use the same class and yet have different behaviour? Wait, isn't that the point of using classes after all? Turns out, I took my PowerUp class for granted in order to apply a shiny concept and be able to claim that I wrote some complicated code.

So let's go back to what the basics taught us: If I create a triangle class, I should be able to create objects with different side dimensions. How will I achieve that? By taking the dimension data as arguments in the constructor.

Now, if I create a PowerUp class, I should be able to create objects with different behaviours. How will I achieve that? By passing behaviour data as arguments in the constructor!

I guess it helps to know (and it is probably time for me to remind you) that functions can also take other functions as arguments. Since we have only two functions (on_collision() and deactivate()) that need to be custom, we only need to pass those in the PowerUp constructor. This is an example of Composition over Inheritance - specifically, the Strategy Pattern, where behaviours are injected as callables instead of being defined in subclasses.

Composition over Inheritance is a software design principle which formally states that complex behaviours should be implemented by combining components rather than inheriting behaviour from the parent class. Informally, it is defined (by me) as Why have children when you can do the crying yourself?

Here is what I am doing in my new PowerUp class:

// #include <functional> is mandatory on top.

class PowerUp : public Fallable {
protected:
    int duration;
    double elapsedTime;
    bool isActive;
    std::function<void(GameManager&)> activateCallback;
    std::function<void(GameManager&)> deactivateCallback;

public:
    PowerUp(int speed, short skin, int duration,
        std::function<void(GameManager&)> onActivate,
        std::function<void(GameManager&)> onDeactivate)
        : Fallable(randomNumGenerator(false, 1, nScreenWidth - 2), 0, speed, skin), 
            duration(duration), isActive(false), elapsedTime(0),
            activateCallback(onActivate), deactivateCallback(onDeactivate) {}

    void on_collision(GameManager& game, bool hitBar) {
        if (hitBar) {
            isActive = true; elapsedTime = 0; inScene = false;
            if (activateCallback) activateCallback(game);
        }
    }

    void deactivate(GameManager& game) {
        if (deactivateCallback) deactivateCallback(game);
    }

    // unimportant methods...
};

Quick overview of what matters in this new class:

In order to be able to pass functions as arguments, we need the <functional> header which defines std::function.
Through the parameter std::function<void(GameManager&)> onActivate, I am telling the compiler to expect a callable (function, function pointer, or lambda) that takes a GameManager object as reference and returns nothing.
Since it is possible that a non-existent function is passed, we will first check if a proper function actually exists before running it. As evident in the lines if (activateCallback) activateCallback(game); and if (deactivateCallback) deactivateCallback(game);.
Finally, we can address point (3), which was that each powerup was only changing something within the GameManager class. While this can be attributed to good design, it also means that we are able to define our parameter for onActivate and onDeactivate to just be GameManager&. If a powerup needed access to something more than that, then the design wouldn't have worked without non-trivial refactoring.

That is it. This is what makes our PowerUp class customizable. Instead of having a child class which contains these key behaviours, we directly told the PowerUp class how to behave by handing the behaviour to it outright. It is still important to mention that using std::function is not the perfect solution as it brings its own overhead. But for the purpose of readability and maintainability, this works really well.

There are two common ways to pass the functions. We can either write a normal function like we did in the inheritance code. Or we can make use of lambdas. The approach depends on the rest of your code architecture. Since I used the factory pattern to create objects, it made sense to use lambdas instead (see full game code for a better idea if you're curious). (As I was writing this, I found out that plain function pointers would have been more performant here. Since my lambdas capture nothing, they implicitly convert to function pointers anyways. But I had to spiritually move on from the game.)

This leads to unbelievably succinct code when creating actual powerups:

// NOTE: this is an illustrative example and not exactly how I created objects in my game.

auto doubleBar = PowerUp(12, 0x002B, 7,
                [](GameManager& game) { if (game.bar.nWidth <= 20) game.bar.transform(2); },
                [](GameManager& game) { if (game.bar.nWidth > 10) game.bar.transform(0.5); }
                );

auto doublePoints = PowerUp(10, 0x0058, 10,
                [](GameManager& game) { game.nScoreMultiplier *= 2; },
                [](GameManager& game) { game.nScoreMultiplier /= 2; }
                );

auto enhancedSpeed = PowerUp(12, 0x2192, 7,
                [](GameManager& game) { game.bar.nSpeed *= 1.25; },
                [](GameManager& game) { game.bar.nSpeed /= 1.25; }
                );

Now, some readers may rightfully point to a little hypocrisy involved in the explanations: I claim that composition is better than inheritance, and it is being used anyways (PowerUp inherits Fallable). The point of this blog isn't to "never use inheritance", but to understand when it isn't the best option, and it often isn't. Using composition, I managed to remove an entire layer of inheritance. I gave it the necessary birth control before it spawned tens of powerups/debuffs (depending on the scale of the game), all for me to take care of. In case you didn't notice, each inherited powerup took about 20 lines of code. That is over 200 lines of redundancy and a maintainability nightmare.

And that is how I survived decapitation at the hands of Inheritance. Like always, I hope that you were able to inherit some new skills and ideas from this post. But then again, be careful of what you inherit :)

Here is the commit with the old approach if you are interested.
And this is the link to the latest game code. I plan to write about this game as a whole soon, so keep your eyes peeled for that.

My Introduction To Templates In Cpp

Atharv Rawat — Fri, 26 Jun 2026 18:40:46 +0000

A few days ago, on an impulse, I asked Gemini to provide me with a snippet of the source code underlying the std::cout function (which I now know is not a function at all). The implicit goal was to get a feel of the low-leveledness involved in writing foundation tools in C++. The explicit goal was procrastination :) Anyways, I got nothing out of the answer, which was fine with me. I did stumble across the notorious template as being one of the core concepts used.

Ever since I started learning C++, templates have been present in the back of my mind as the end game of proficiency in the language (not true of course). I remember seeing templates being used in random code I encountered and being intimidated by the capital T. Now I know that this fear was sustained entirely by ignorance, like most things in life.

This time, I decided to understand how it actually worked. What the need was. And it turned out to be so damn simple that I had to smile in shame when I realized. Templates are nothing but a tool to create functions and classes where you don't know what kind of specific data you are going to work with. Or you do know, but there are too many and you need to work with them all the same way.

The popular way to put it is that classes are to objects what templates are to classes. In other words, templates are blueprints for creating classes. More accurately, they can be used to create blueprints for functions too (as will be shown later), but we can base our understanding starting from this thought.

Let's consider the following helper function I wrote for testing an LC solution (No. 21):

struct ListNodeInt {
    int val;
    ListNodeInt* next;
    ListNodeInt(int val) : val(val), next(nullptr) {}
};

ListNodeInt* vector_to_LL(std::vector<int>& nums) {
    if (nums.empty()) return nullptr;
    ListNodeInt* START = nullptr, *q = nullptr;
    START = new ListNodeInt(nums[0]);
    q = START;
    for (int i = 1; i < nums.size(); i++) {
        q->next = new ListNodeInt(nums[i]);
        q = q->next;
    }
    return START;
}

If you are familiar with linked lists, this should feel like a walk in the park. I take a vector of integers, construct a singly non-circular linked list out of it, and return the head.

Now, a true programmer is probably already familiar with the DRY principle. So, I am not going to repeat what it means :) The problem with the given function is that it is hardcoded to work only with vectors containing integer values, as indicated by the single phrase std::vector<int>& nums. Naturally, this would mean that the compiler would throw a type mismatch error if I try to pass a vector of characters in this function. Not only that, but the ListNode definition itself strictly holds integer values in val.

Does this mean that I will have to write an entirely new function that specially accepts character vectors? While this approach is viable and even conceptualized as "function overloading", it is not scalable and affects code readability. Of course, because DRY, I don't want to copy paste 5 versions of the same function so that every supported data type is covered.

I mean, look at this piece of crap:

ListNodeInt* vector_to_LL(std::vector<int>& nums) {
    // 10 lines of code...
}

ListNodeFloat* vector_to_LL(std::vector<float>& nums) {
    // 10 lines of code...
}

ListNodeChar* vector_to_LL(std::vector<char>& chars) {
    // 10 lines of code...
}

ListNodeDouble* vector_to_LL(std::vector<double>& nums) {
    // 10 lines of code...
}

That is about 40 lines of code just because a single word is different in each function.

Well no shit, templates are the answer. They allow you to write a single function that works for any data type. Let's have a look:

Firstly, our new ListNode structure definition:

template <typename T>
struct ListNode {
    T val;
    ListNode* next;
    ListNode(T val) : val(val), next(nullptr) {}
};

Here, template <typename T> is the line that declares that the following class/function is a template, which means there are data type(s) within that are not known yet. Capital T is just the naming convention for that unknown datatype. You are telling the compiler that you are going to refer to this unknown datatype as T. In other words, this line tells that the following function is a template that wants to adapt to the datatype T. If you knew that the function was definitely supposed to accept some kind of container of values like vectors, lists, sets, etc., then it would be a better to use collection as placeholder instead of T (more on that later).

After that, it is just like how you normally define structs. All you do is that you use T wherever you don't know the datatype. In this case, val could hold an integer, a float, a character or anything else, but I don't know that for now, so I will just use the placeholder T. Nothing else unusual here.

Structs are just classes with public access members, so that is how we can write adaptive classes in C++ using templates. Note that such classes are actually called class templates, since they are only blueprints, remember?

Moving on to our function:

template <typename T>
auto vector_to_LL(vector<T>& collection) {

    if (collection.empty()) return (ListNode<T>*)nullptr;

    ListNode<T>* head = new ListNode<T>(collection[0]);
    ListNode<T>* current = head;

    for (int i = 1; i < collection.size(); i++) {
        current->next = new ListNode<T>(collection[i]);
        current = current->next;
    }

    return head;
}

Let's go through this a line at a time to bring it home.

Firstly, this is an example of a function template, and just like with the structure, we start with template <typename T> to indicate that the following function will adapt to the unknown datatype T. Then, we use T in the parameter like so - vector<T>& collection, indicating that we know a vector must be passed, but the datatype is unknown.

In the line ListNode<T>* head = new ListNode<T>(collection[0]); notice that we are clearly using the constructor defined in the structure definition. Wherever we would normally use a specific datatype like int, float or double, we use T instead.

If you look at this new function from a broader perspective, you may notice another problem. I hinted at it a couple hundred words ago: We managed to make the function adapt to the kind of data that the vectors store, but this function only works for vectors. What about any other container that is part of the standard library? Arrays? Lists? Deques?

A vector is technically also a datatype, so templates can definitely be applied to generalize this function further.

This is how it can be done:

// The ListNode structure remains the same as the last version

template <typename Container>
auto container_to_LL(Container& collection) {

    using DataType = typename Container::value_type;

    if (collection.empty()) return (ListNode<DataType>*)nullptr;

    auto it = collection.begin();

    ListNode<DataType>* head = new ListNode<DataType>(*it);
    ListNode<DataType>* current = head;

    for (++it; it != collection.end(); it++) {
        current->next = new ListNode<DataType>(*it);
        current = current->next;
    }

    return head;
}

Here, there are only three major changes that you need to pay attention to:

template <typename Container>
- When we are trying to adapt a function to an unknown container, the template declaration should indicate that. Which is why we use Container as opposed to T, which is normally used for primitive data types. Note that this is just a naming convention used for code readability. The name we use has no effect on execution.
using DataType = typename Container::value_type;
- Using (ha!) this line, we determine which type of data the container stores.
- The using keyword is just a way for setting an alternative name for a datatype (just like typedef if you are familiar), which becomes necessary here because we don't know the specific datatype. We still need a way to reference it.
- typename serves different purpose here compared to how it's used in the template declaration. First, let's show some empathy to the compiler. Not only will it have to deal with an unknown container, but it also doesn't know which datatype is stored within! That is a lot of ambiguity which we must help clear. If we had just used using DataType = Container::value_type; (notice that typename is missing), the compiler would have interpreted Container::value_type as a value, when it is actually a type! Thus, using typename is necessary to assure the compiler that Container::value_type returns a type.
- Now, since the container is definitely a class object in C++, it stores attributes about itself, like the type of data it holds. That is what we access using the phrase Container::value_type.
- To summarize, we want to use the name DataType (or any other name of your choice, even our beloved T) to reference the type of data stored inside the container.
Iteration
- Finally, notice the way the container is traversed. We don't use the index-based approach being used to specifically target vectors. This is because containers like list don't support index-based traversal. This means that we must use an approach that works for every container, so that our generalized function actually works generally.
- For this, we use iterators .begin() and .end(). These iterators are built into each sequence-based STL container, which allows us to traverse them all using a single approach.
- The premise is simple, container.begin() always points to the first element of the container. Notice the word 'points'. This iterator returns a pointer that must be dereferenced to access the actual value, as illustrated in the line new ListNode<DataType>(*it). We call the structure constructor by naturally passing the dereferenced pointer as the value.
- Similarly, container.end() points to the one past the last element of the container, which is why we loop while the current iterator is not equal to it.

Hopefully, this blog just handed you the blueprint to writing more readable and frankly, impressive-looking C++ code. Templates have truly changed the way I approach writing OOP code in C++.

In order to practice what I had learnt, I wrote some more generalized helper functions using templates. Here they are. Feel free to look through them.

// Traverse any container. 
template <typename Container>
void traverse_container(Container& collection) {
    using DataType = typename Container::value_type;

    if (collection.empty()) return;

    for (auto it = collection.begin(); it != collection.end(); it++) {
        std::cout << *it << " ";
    }
    std::cout << std::endl;
}

Try to see why this wouldn't work if the data stored inside the container is a structure or a class object.
Notice how damn general this function is. Any sequential STL container holding any primitive datatype can be passed.
We are using the exact principles discussed in the previous function. Only instead of building a linked list, we are doing something even simpler: sequential traversal.

// Traverse a linked list with any data type stored inside nodes. 
template <typename T>
void traverse_LL(ListNode<T>* head) {
    ListNode<T>* current = head;

    while (current != nullptr) {
        std::cout << current->val << " ";
        current = current->next;
    }

    std::cout << std::endl;
}

Nothing special here as well. The only thing we are adapting to is the datatype stored inside each ListNode.

// Delete the linked list and freeing memory
template <typename T>
void delete_LL(ListNode<T>*& START) {

    if (START == nullptr) return;

    while (START != nullptr) {
        ListNode<T>* q = START;
        START = START->next;
        delete q;
    }
}

Again, we are doing nothing unusual here. It looks just like a normal LL deletion function except for big T.

What to do when you have done nothing? Portfolio Challenge Entry

Atharv Rawat — Sun, 01 Feb 2026 20:01:11 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hi everyone! I am a 1st year CS student from India striving to pursue my passion of learn and create. A lot of bumps, twists and turns in the road led me to this amazing field, where now I feel at home. Apart from my focus on learning CS fundamentals, I love to play sports (table tennis and basketball are my favs) and make beats and compose scores on FL Studio.

This portfolio is a representation of a launchpad of an ambitious student. While I may not have much to show right now, you can be assured that there will be a lot of it in the near future.

“Even the greatest was once a beginner. Don’t be afraid to take that first step.” —Muhammad Ali

Portfolio

https://portfolio-service-862693525395.us-central1.run.app

How I Built It

As I try to make clear in my rather scant portfolio, my current focus has allowed me no resources to invest in skills necessary to build portfolio websites like this one, so AI was my best buddy in this journey. I used Google AI Studio for the scaffold and then moved on to Google Antigravity for more advanced development. I tried to use the best practices as a vibe-coder (spec sheet, AGENT.md, prompt design etc.) to make the most out of the incredible power that Antigravity offers.

Here is the technical implementation overview of my portfolio (AI-generated):

Framework: React 19 + TypeScript
Build Tool: Vite 6
Styling: Tailwind CSS 3.4
Animations: Framer Motion 12
Icons: Lucide React
Deployment: Google Cloud Run (containerized with Nginx)

What I'm Most Proud Of

I am not at the stage where I have a lot of technically impressive and impactful projects to showcase, so this portfolio was really about accentuating my personality, my driving force and my direction as an aspiring founder/researcher in the tech space. For a fairly rushed project, I am very proud of the message I was able to convey through the simple but focused design and the truly heartfelt content. I was also inspired by the insanely beautiful and elaborate loading screens of fellow participants and decided to add a loading screen visualizing a sorting algorithm (bubble and merge sort). I feel pure joy whenever I watch it in action. So much so that I added a reload button in the header bar just so I can see it whenever I want without completely reloading the page (useless perhaps, but idc :). It's a raw representation of my current struggles with grappling DSA and the quirks of C++.

Hope you like it! (My first dev.to post btw, so happy to be here!)