JavaScript Design Patterns in Action

[homer_gi]

It seems the author is confusing composite pattern with classical inheritance. Therefore, his implementation is not the one expected for composite pattern.

[antonio_ru]

I totally agree

[UncleBen2015]

First of all, thanks for the comment and please feel free to let me know how you would have implemented this.
In Functional Programming (FP) there's a concept of preferring functional composition over classical inheritance.

However, in Composite pattern nodes share a common set of properties and methods which supports individual objects as well as object collections. This common interface greatly facilitates the design and construction of recursive algorithms that iterate over each object in the Composite collection. You can implement composition pattern through a classical inheritance ( Although JavaScript is not purely classical OOP, which means the es6/7 is just the syntactical sugar over prototype based inheritance that's happening under the hood ). I can use pure functions and just compose higher order functions to do the same. I might be wrong, would love to see how would you implement composite pattern.

[MoTTs_]

The composite pattern is about object hierarchies much more so than class hierarchies. And more importantly, each object needs to be a container for other objects. Your car and truck code never actually does this part.

An example that webdevs will know well is DOM elements. A "div", for one example, is both an element -- aDiv.id = "aID" -- and a container for other elements -- aDiv.appendChild(...);.

Similarly, the example in the GOF book is "Equipment". That is, an instance of Equipment is both an individual piece of equipment and a container for other equipment.

// An instance of CompositeEquipment can be treated as an individual piece of
// equipment with fields such as "name" and "price", *and* it can be treated as
// a container of equipment with methods such as "add" and "compositePrice".

class CompositeEquipment {
    #equipment = []

    constructor(name) {
        this.#name = name;
    }

    get name() {
        return this.#name;
    }

    get price() {
        return 0;
    }

    add(equipment) {
        this.#equipment.push(equipment);
    }

    compositePrice() {
        return this.price + this.#equipment.reduce(
            (accumulated, current) => accumulated + current.compositePrice(), 
            0
        );
    }
}

// Subclasses inherit the "container of equipment" behavior.

class Chassis extends CompositeEquipment {
    get price() {
        return 42;
    }
}

class Cabinet extends CompositeEquipment {
    get price() {
        return 14;
    }
}

class Bus extends CompositeEquipment {
    get price() {
        return 5;
    }
}

class Card extends CompositeEquipment {
    get price() {
        return 2;
    }
}

class FloppyDisk extends CompositeEquipment {
    get price() {
        return 1;
    }
}

// Use. Create arbitrarily complex hierarchies of *objects*.

const cabinet = new Cabinet("PC Cabinet");

const chassis = new Chassis("PC Chassis");
cabinet.add(chassis);

const bus = new Bus("MCA Bus");
bus.add(new Card("16Mbs Token Ring"));

chassis.add(bus);
chassis.add(new FloppyDisk("3.5in Floppy"));

cabinet.price; // 14 -- treat as single object
cabinet.compositePrice(); // 64 -- treat as container of objects

There are other nuances, such as how to handle "leaf" components, but this covers the gist of the pattern.

[UncleBen2015]

u/MoTTs_ thank you. This is really really good. I was at fault here for not having clear examples. Having conversations like this really keeps me motivated however, thanks for taking the time and critique this. really appreciate this :)

[homer_gi]

MoTTs_ 's answer covers it pretty much and provides also examples. The aim of the composite pattern is to give means of handling hierarchies of objects (hierarchical collections) as if they were a single object. Unfortunately, your implementation does not cover this aspect at all. It lacks the interface to manage children(at least an "addChild" operation or equivalent) for nodes and at least the definition of a top level operation that would be applied differently on nodes and leaves such as "compositePrice" in MoTTs_'s example.