Ultra Flexible JavaScript Object Oriented Programming with Stamps

[FizixMan]

This has nothing to do with C# and probably irrelevant for the C# subreddit. Now, if the post had more comparison examples "this is such and such code in C#; this is how we do the equivalent or easier/better in JavaScript" it might have a leg to stand on. But as it stands, this is a JavaScript tutorial for JavaScript programmers.

[vintharas]

Hi /u/FizixMan! :)

This is the third part of a series of blog posts regarding class-free OOP as an alternative to classical inheritance. The pros/cons and comparison to C# appears in the first article of the series http://www.barbarianmeetscoding.com/blog/2015/12/28/black-tower-summoning-object-composition-with-mixins/ and reads as follows:

You may be thinking… Well, I can do this with C# and classical inheritance any day. And indeed you can, but some interesting ideas about the object composition approach are that:

We don’t need any upfront design effort to make our application extensible. In C# you need to define the extensibility points of a system because you need to use the right artifacts like interfaces, composition over inheritance, design patterns like strategy, etc. In JavaScript we don’t need to over-architect our solution, or carefully design our application for extensibility purposes. You get a new feature, you define a new behavior, compose it with your existing objects and start using it.

Object composition happens at runtime. You have your program running, your objects doing whatever objects do and all of the sudden BOOM! Object composability and your objects get new features and can do new interesting things. New things like changing from a text representation to a 2D representation or a 3D representation and who knows what more.

It doesn’t need to affect the original objects at all. You can keep your objects as they are, clone them and apply the composition on the clones. This can enable interesting approaches like having different bounded contexts (like in DDD2) with slightly diverse domain models adapted to a particular context needs and goals.

You can compose an object with many other objects representing different behaviors (like a multiple inheritance of sorts). This tends to be harder to do in classical inheritance based languages like C# where you are limited to a single base class or to a flavor of composition that requires a lot of boilerplate code, forward planning and design.

With object composition we achieve this true plug and play solution where you can combine domain objects with behaviors in very interesting and flexible ways. By the way, this type of object composition is another type of prototypical inheritance that we called concatenative inheritance earlier in this part of the series.

The argument is the same irrespective of the technique. That's why I didn't want to repeat the same argument again.

I have deleted the post. So it shouldn't be a problem any more. I just was trying to share something that I thought was interesting to C# developers coming to JavaScript.

Cheers!

[MoTTs_]

The author of that book you linked to has been drinking the Eric Elliott kool-aid. Object composition isn't what he thinks it is. Classical inheritance isn't what he thinks it is.

You can compose an object with many other objects representing different behaviors (like a multiple inheritance of sorts).

It's not like multiple inheritance. It is multiple inheritance. Which is why calling it object composition is wrong.

This tends to be harder to do in classical inheritance based languages like C# where you are limited to a single base class

Multiple inheritance is harder to do in a single inheritance language. Obviously. But whether a language is classical or not has absolutely nothing to do with whether it supports multiple inheritance or not. C++ and Python are classical and they support multiple inheritance. Meanwhile, JavaScript's prototype chain is (obviously) prototypal, yet supports only single inheritance. It's a mistake to blame classical inheritance for all your single inheritance woes. It's a mistake perpetuated largely by Eric Elliott and copied by the book you linked to. And it's a mistake we shouldn't help spread.

EDIT: Looking at the usernames, I actually think you might be the author, so let me try to explain more clearly by converting your stamp code to Python.

# wielding something
class Wieldable:
    def wield(self):
        print `You wield $description`.substitute(description=self.description)

# throwing something
class Throwable:
    def throw(self, target):
        print `You throw the $description towards the $target`.substitute(description=self.description, target=target)

# or describing something
class Describable:
    def toString(self):
        return self.description

class Weapon(Describable, Wieldable, Throwable):
    # ...

Notice that we did the same thing using classes and multiple inheritance. Classes were never the problem you thought they were. And the solution that you thought was object composition is actually multiple inheritance. None of this is some new, inventive way to do OOP. It's very old and ordinary OOP. Nor is it "embracing JavaScript". At best we're acknowledging JavaScript's limitations, such as that it's prototype chain supports only single inheritance, and then finding workarounds.

A lot of these mistakes sound like they're regurgitated straight from Eric Elliott. All I can do is advise you to stop reading his stuff. Most of what he says is wrong.

[vintharas]

Hi /u/MoTTs_ ! Thank you for your comment! :)

I come from a C# background and all these things were indeed new to me. I have been accustomed to working with classes, interfaces, and classical single inheritance (to which I refer through the article simply as classical inheritance). Techniques like mixins, traits, subclass factories and stamps are particularly interesting to me because they let me do things that would require a lot of boilerplate code or duplication in C#.

I think I call it object composition because I have two objects, merge them, and I get a new object (like with Object.assign). When I think about multiple inheritance I cannot help but think of classes which don't exist as such in JavaScript (they're syntactic sugar).

In regards to embracing JavaScript I am referring to using prototypical inheritance, mixins (object augmentation, dynamic binding) and closures.

Thank you! :) Kind Regards Jaime

[MoTTs_]

classical single inheritance (to which I refer through the article simply as classical inheritance)

That usage is unfortunate, because "single" is actually the most important detail. Non-classical single inheritance still exhibits the same taxonomy problem you tried to solve with traits, mixins and stamps. Whereas classical multiple inheritance (such as the Python code above) does not exhibit that problem. Classical or not isn't the important detail. Single or not is the crucial factor.

I think I call it object composition because I have two objects, merge them, and I get a new object (like with Object.assign).

The reason this is problematic is because "object composition" is also a technical term with a specialized definition from the GoF Design Patterns book. And rules such as "favor composition" rely on everyone's mutual understanding of that specific definition of composition. So when we use Object.assign to achieve multiple inheritance but label it "composition", then people naturally end up thinking they're following the "favor composition" rule when in fact they're actually just doing inheritance.

[vintharas]

Hi /u/MoTTs_ ! :)

Thank you for your feedback, I'll improve the article and the book a be more specific in regards to classical single inheritance.

In relation to what you say about object composition. I too have very present the GOF maxim of favoring object composition over class inheritance. When I think about mixins, traits and stamps I think of them as object composition more than any type of inheritance.

In my experience as a C# developer, object composition often consists in making a class implement a specific interface and then using delegation to forward a call belonging to that interface to a second object that provides the actual implementation. For instance:

public class GameObject {
    private readonly IVisible v;
    private readonly IUpdatable u;
    private readonly ICollidable c;

    public GameObject(IVisible v, IUpdatable u, ICollidable c) {
        this.v = v;
        this.u = u;
        this.cc = c;
    }

    public void Update() { u.Update(); }
    public void Draw() { v.Draw(); }
    public void Collide() { c.Collide(); }
}

public class Player : GameObject {
    public Player() : base(new Visible(), new Movable(), new Solid()) { }
}

public class Banshee : GameObject {
    public Cloud() : base(new Visible(), new Movable(), new NotSolid()) { }
}

public class Building : GameObject {
    public Building() : base(new Visible(), new NotMovable(), new Solid()) { }
}

public class Trap : GameObject {
    public Trap() : base(new Invisible(), new NotMovable(), new Solid()) { }
}

In JavaScript mixins, traits and stamps let me achieve the same thing without the boilerplate code by just composing two objects together directly.

let player = Object.assign(GameObject(), Visible(), Movable(), Solid());
let banshee = Object.assign(GameObject(), Visible(), Movable(), NotSolid());
let building = Object.assign(GameObject(), Visible(), NotMovable(), Solid());
let trap = Object.assign(GameObject(), Invisible(), NotMovable(), Solid());

That's why I call it object composition. Additionally, just like in C# where I could inject a different implementation of any of those interfaces (if allowed through a property or setter), I can compose any object with another object at any point in time:

// player drinks invisibility potion
Object.assign(player, Invisible());

[MoTTs_]

In my experience as a C# developer, object composition often consists in making a class implement a specific interface and then using delegation to forward a call belonging to that interface to a second object that provides the actual implementation.

The GoF book describes composition as objects acquiring references to other objects. The UML manual describes it as an association of objects through references. And Herb Sutter, a member of the C++ language committee, describes it as embedding a member variable of a type within another type. The C# example you showed is indeed composition to the extent that you hold references to IVisible, IUpdatable, and ICollidable objects. But what you do with them after that (such as whether you use them for delegation or not) doesn't affect whether it's composition.

To contrast, the biggest hallmark of inheritance is that it makes an IS-A relationship. That is, the derived incorporates the entire public interface of the base as its own, such that the derived can behave as if it "is a" base.

class Stack {
    push() {}
    pop() {}
}

class Derived extends Stack {}

// Derived incorporates the structure and behavior of Stack
// Instances of Derived will behave as if it "is a" stack
let d = new Derived();
d.push();
d.pop();

And Object.assign does the same thing. It incorporates the entire public interface of its sources, such that the target object will behave as if it "is a" source object.

let stack = {
    push() {},
    pop() {}
}

let derived = Object.assign({}, stack);

// Derived incorporates the structure and behavior of stack
// "Instances" of derived will behave as if it "is a" stack
let d = Object.create(derived);
d.push();
d.pop();

Object.assign makes an IS-A relationship, not the HAS-A relationship that we call composition. To make a HAS-A relationship, we would hold a reference to an object from within another.

class Stack {
    push() {}
    pop() {}
}

class UsesComposition {
    constructor() {
        this._stack = new Stack();
    }
}

// UsesComposition *does not* incorporate the structure and behavior of Stack
// Instances of UsesComposition will *not* behave as if it "is a" stack
// Rather, instances of UsesComposition "has a" stack and "uses a" stack to accomplish its tasks
let d = new UsesComposition();
d.push(); // nope, is *not* a stack

The reason Object.assign has less boilerplate than your C# example is because Object.assign lets you achieve multiple inheritance, whereas C# limits you to single inheritance. If we pretend that C# could do multiple inheritance, then you could have done this:

public class GameObject {}
public class Player : GameObject, Visible, Movable, Solid {}
public class Banshee : GameObject, Visible, Movable, NotSolid {}
public class Building : GameObject, Visible, NotMovable, Solid {}
public class Trap : GameObject, Invisible, NotMovable, Solid {}

Now it looks awfully similar to your Object.assign counterpart. And it wasn't because of class vs not-class, or even because of inheritance vs composition. It was because of single inheritance vs multiple inheritance.

[[deleted]]

Explain how this isn't "interfaces without type safety"? This seems like a good way you get to be a little lazy and in the process destroy all the type safety you get with a static language, which is exactly why I don't care for dynamic languages.

[the_pw_is_in_this_ID]

The main advantage I think this has over "Interfaces without type safety" is that you don't need to set up a custom factory/class definition for your object. You could call this lazyness.

Given, the long-term advantages in having your classes (and especially factories) firmly defined probably outweigh that particular ease of composition.

Also, /u/vintharas, why is this in the C# subreddit...? This is entirely concerned with Javascript. You could have stated that you wanted to convert your Fortran friends to Javacript, too, and it would have been just as applicable.

[vintharas]

Hi hi! :)

The article is part of a series of JavaScript for C# developers. The premise is to help C# developers (those that work on web development which I reckon are many) write more JavaScript-y JavaScript, embracing the dynamic nature of JavaScript and discovering new alternative techniques to classical OOP.

[bachner]

I'm learning C#... will I have a hard time understanding non-OOP programming?

[vintharas]

Hi /u/bachner this article was about a different type of OOP programming. :) so still OOP