Jump to content
  • Advertisement
  • entries
    3
  • comments
    66
  • views
    5356

OOP is dead, long live OOP

Hodgman

67392 views

edit:

Seeing this has been linked outside of game-development circles: "ECS" (this wikipedia page is garbage, btw -- it conflates EC-frameworks and ECS-frameworks, which aren't the same...) is a faux-pattern circulated within game-dev communities, which is basically a version of the relational model, where "entities" are just ID's that represent a formless object, "components" are rows in specific tables that reference an ID, and "systems" are procedural code that can modify the components. This "pattern" is always posed as a solution to an over-use of inheritance, without mentioning that an over-use of inheritance is actually bad under OOP guidelines. Hence the rant. This isn't the "one true way" to write software. It's getting people to actually look at existing design guidelines.

Inspiration

This blog post is inspired by Aras Pranckevičius' recent publication of a talk aimed at junior programmers, designed to get them to come to terms with new "ECS" architectures. Aras follows the typical pattern (explained below), where he shows some terrible OOP code and then shows that the relational model is a great alternative solution (but calls it "ECS" instead of relational). This is not a swipe at Aras at all - I'm a fan of his work and commend him on the great presentation! The reason I'm picking on his presentation in particular instead of the hundred other ECS posts that have been made on the interwebs, is because he's gone through the effort of actually publishing a git repository to go along with his presentation, which contains a simple little "game" as a playground for demonstrating different architecture choices. This tiny project makes it easy for me to actually, concretely demonstrate my points, so, thanks Aras!

You can find Aras'  slides at http://aras-p.info/texts/files/2018Academy - ECS-DoD.pdf and the code at https://github.com/aras-p/dod-playground.

I'm not going to analyse the final ECS architecture from that talk (yet?), but I'm going to focus on the straw-man "bad OOP" code from the start. I'll show what it would look like if we actually fix all of the OOD rule violations.
Spoiler: fixing the OOD violations actually results in a similar performance improvement to Aras' ECS conversion, plus it actually uses less RAM and requires less lines of code than the ECS version!
TL;DR: Before you decide that OOP is shit and ECS is great, stop and learn OOD (to know how to use OOP properly) and learn relational (to know how to use ECS properly too).

I've been a long-time ranter in many "ECS" threads on the forum, partly because I don't think it deserves to exist as a term (spoiler: it's just a an ad-hoc version of the relational model), but because almost every single blog, presentation, or article that promotes the "ECS" pattern follows the same structure:

  1. Show some terrible OOP code, which has a terribly flawed design based on an over-use of inheritance (and incidentally, a design that breaks many OOD rules).
  2. Show that composition is a better solution than inheritance (and don't mention that OOD actually teaches this same lesson).
  3. Show that the relational model is a great fit for games (but call it "ECS").

This structure grinds my gears because:
(A) it's a straw-man argument.. it's apples to oranges (bad code vs good code)... which just feels dishonest, even if it's unintentional and not actually required to show that your new architecture is good,
but more importantly:
(B) it has the side effect of suppressing knowledge and unintentionally discouraging readers from interacting with half a century of existing research. The relational model was first written about in the 1960's. Through the 70's and 80's this model was refined extensively. There's common beginners questions like "which class should I put this data in?", which is often answered in vague terms like "you just need to gain experience and you'll know by feel"... but in the 70's this question was extensively pondered and solved in the general case in formal terms; it's called database normalization. By ignoring existing research and presenting ECS as a completely new and novel solution, you're hiding this knowledge from new programmers.

Object oriented programming dates back just as far, if not further (work in the 1950's began to explore the style)! However, it was in the 1990's that OO became a fad - hyped, viral and very quickly, the dominant programming paradigm. A slew of new OO languages exploded in popularity including Java and (the standardized version of) C++. However, because it was a hype-train, everyone needed to know this new buzzword to put on their resume, yet no one really groked it. These new languages had added a lot of OO features as keywords -- class, virtual, extends, implements -- and I would argue that it's at this point that OO split into two distinct entities with a life of their own.
I will refer to the use of these OO-inspired language features as "OOP", and the use of OO-inspired design/architecture techniques as "OOD". Everyone picked up OOP very quickly. Schools taught OO classes that were efficient at churning out new OOP programmers.... yet knowledge of OOD lagged behind.

I argue that code that uses OOP language features, but does not follow OOD design rules is not OO code. Most anti-OOP rants are eviscerating code that is not actually OO code.
OOP code has a very bad reputation, I assert in part due to the fact that, most OOP code does not follow OOD rules, thus isn't actually "true" OO code.

Background

As mentioned above, the 1990's was the peak of the "OO fad", and it's during this time that "bad OOP" was probably at its worst. If you studied OOP during this time, you probably learned "The 4 pillars of OOP":

  • Abstraction
  • Encapsulation
  • Polymorphism
  • Inheritance

I'd prefer to call these "4 tools of OOP" rather than 4 pillars. These are tools that you can use to solve problems. Simply learning how a tool works is not enough though, you need to know when you should be using them... It's irresponsible for educators to teach people a new tool without also teaching them when it's appropriate to use each of them.  In the early 2000's, there was a push-back against the rampant misuse of these tools, a kind of second-wave of OOD thought. Out of this came the SOLID mnemonic to use as a quick way to evaluate a design's strength. Note that most of these bits of advice were well actually widely circulated in the 90's, but didn't yet have the cool acronym to cement them as the five core rules...

  • Single responsibility principle. Every class should have one reason to change. If class "A" has two responsibilities, create a new class "B" and "C" to handle each of them in isolation, and then compose "A" out of "B" and "C".
  • Open/closed principle. Software changes over time (i.e. maintenance is important). Try to put the parts that are likely to change into implementations (i.e. concrete classes) and build interfaces around the parts that are unlikely to change (e.g. abstract base classes).
  • Liskov substitution principle. Every implementation of an interface needs to 100% comply the requirements of that interface. i.e. any algorithm that works on the interface, should continue to work for every implementation.
  • Interface segregation principle. Keep interfaces as small as possible, in order to ensure that each part of the code "knows about" the least amount of the code-base as possible. i.e. avoid unnecessary dependencies. This is also just good advice in C++ where compile times suck if you don't follow this advice :D 
  • Dependency inversion principle. Instead of having two concrete implementations communicate directly (and depend on each other), they can usually be decoupled by formalizing their communication interface as a third class that acts as an interface between them. This could be an abstract base class that defines the method calls used between them, or even just a POD struct that defines the data passed between them.
  • Not included in the SOLID acronym, but I would argue is just as important is the:
    Composite reuse principle. Composition is the right default™. Inheritance should be reserved for use when it's absolutely required.

This gives us SOLID-C(++) :) 

From now on, I'll refer to these by their three letter acronyms -- SRP, OCP, LSP, ISP, DIP, CRP...

A few other notes:

  • In OOD, interfaces and implementations are ideas that don't map to any specific OOP keywords. In C++, we often create interfaces with abstract base classes and virtual functions, and then implementations inherit from those base classes... but that is just one specific way to achieve the idea of an interface. In C++, we can also use PIMPL, opaque pointers, duck typing, typedefs, etc... You can create an OOD design and then implement it in C, where there aren't any OOP language keywords! So when I'm talking about interfaces here, I'm not necessarily talking about virtual functions -- I'm talking about the idea of implementation hiding. Interfaces can be polymorphic, but most often they are not! A good use for polymorphism is rare, but interfaces are fundamental to all software.
    • As hinted above, if you create a POD structure that simply stores some data to be passed from one class to another, then that struct is acting as an interface - it is a formal data definition.
    • Even if you just make a single class in isolation with a public and a private section, everything in the public section is the interface and everything in the private section is the implementation.
  • Inheritance actually has (at least) two types -- interface inheritance, and implementation inheritance.
    • In C++, interface inheritance includes abstract-base-classes with pure-virtual functions, PIMPL, conditional typedefs. In Java, interface inheritance is expressed with the implements keyword.
    • In C++, implementation inheritance occurs any time a base classes contains anything besides pure-virtual functions. In Java, implementation inheritance is expressed with the extends keyword.
    • OOD has a lot to say about interface-inheritance, but implementation-inheritance should usually be treated as a bit of a code smell!

And lastly I should probably give a few examples of terrible OOP education and how it results in bad code in the wild (and OOP's bad reputation).

  1. When you were learning about hierarchies / inheritance, you probably had a task something like:
    Let's say you have a university app that contains a directory of Students and Staff. We can make a Person base class, and then a Student class and a Staff class that inherit from Person!
    Nope, nope nope. Let me stop you there. The unspoken sub-text beneath the LSP is that class-hierarchies and the algorithms that operate on them are symbiotic. They're two halves of a whole program. OOP is an extension of procedural programming, and it's still mainly about those procedures. If we don't know what kinds of algorithms are going to be operating on Students and Staff (and which algorithms would be simplified by polymorphism) then it's downright irresponsible to dive in and start designing class hierarchies. You have to know the algorithms and the data first.
  2. When you were learning about hierarchies / inheritance, you probably had a task something like:
    Let's say you have a shape class. We could also have squares and rectangles as sub-classes. Should we have square is-a rectangle, or rectangle is-a square?
    This is actually a good one to demonstrate the difference between implementation-inheritance and interface-inheritance.
    • If you're using the implementation-inheritance mindset, then the LSP isn't on your mind at all and you're only thinking practically about trying to reuse code using inheritance as a tool.
      From this perspective, the following makes perfect sense:
      struct Square { int width; }; struct Rectangle : Square { int height; };
      A square just has width, while rectangle has a width + height, so extending the square with a height member gives us a rectangle!
      • As you might have guessed, OOD says that doing this is (probably) wrong. I say probably because you can argue over the implied specifications of the interface here... but whatever.
        A square always has the same height as its width, so from the square's interface, it's completely valid to assume that its area is "width * width".
        By inheriting from square, the rectangle class (according to the LSP) must obey the rules of square's interface. Any algorithm that works correctly with a square, must also work correctly with a rectangle.
      • Take the following algorithm: std::vector<Square*> shapes; int area = 0; for(auto s : shapes) area += s->width * s->width;
        This will work correctly for squares (producing the sum of their areas), but will not work for rectangles.
        Therefore, Rectangle violates the LSP rule.
    • If you're using the interface-inheritance mindset, then neither Square or Rectangle will inherit from each other. The interface for a square and rectangle are actually different, and one is not a super-set of the other.
    • So OOD actually discourages the use of implementation-inheritance. As mentioned before, if you want to re-use code, OOD says that composition is the right way to go!
      • For what it's worth though, the correct version of the above (bad) implementation-inheritance hierarchy code in C++ is:
        struct Shape { virtual int area() const = 0; };
        struct Square : public virtual Shape { virtual int area() const { return width * width; }; int width; };
        struct Rectangle : private Square, public virtual Shape { virtual int area() const { return width * height; }; int height; };
        • "public virtual" means "implements" in Java. For use when implementing an interface.
        • "private" allows you to extend a base class without also inheriting its interface -- in this case, Rectangle is-not-a Square, even though it's inherited from it.
      • I don't recommend writing this kind of code, but if you do like to use implementation-inheritance, this is the way that you're supposed to be doing it!

TL;DR - your OOP class told you what inheritance was. Your missing OOD class should have told you not to use it 99% of the time!

Entity / Component frameworks

With all that background out of the way, let's jump into Aras' starting point -- the so called "typical OOP" starting point.
Actually, one last gripe -- Aras calls this code "traditional OOP", which I object to. This code may be typical of OOP in the wild, but as above, it breaks all sorts of core OO rules, so it should not all all be considered traditional.

I'm going to start from the earliest commit before he starts fixing the design towards "ECS": "Make it work on Windows again" 3529f232510c95f53112bbfff87df6bbc6aa1fae

// -------------------------------------------------------------------------------------------------
// super simple "component system"

class GameObject;
class Component;

typedef std::vector<Component*> ComponentVector;
typedef std::vector<GameObject*> GameObjectVector;


// Component base class. Knows about the parent game object, and has some virtual methods.
class Component
{
public:
    Component() : m_GameObject(nullptr) {}
    virtual ~Component() {}
    
    virtual void Start() {}
    virtual void Update(double time, float deltaTime) {}

    const GameObject& GetGameObject() const { return *m_GameObject; }
    GameObject& GetGameObject() { return *m_GameObject; }
    void SetGameObject(GameObject& go) { m_GameObject = &go; }
    bool HasGameObject() const { return m_GameObject != nullptr; }

private:
    GameObject* m_GameObject;
};


// Game object class. Has an array of components.
class GameObject
{
public:
    GameObject(const std::string&& name) : m_Name(name) { }
    ~GameObject()
    {
        // game object owns the components; destroy them when deleting the game object
        for (auto c : m_Components) delete c;
    }

    // get a component of type T, or null if it does not exist on this game object
    template<typename T>
    T* GetComponent()
    {
        for (auto i : m_Components)
        {
            T* c = dynamic_cast<T*>(i);
            if (c != nullptr)
                return c;
        }
        return nullptr;
    }

    // add a new component to this game object
    void AddComponent(Component* c)
    {
        assert(!c->HasGameObject());
        c->SetGameObject(*this);
        m_Components.emplace_back(c);
    }
    
    void Start() { for (auto c : m_Components) c->Start(); }
    void Update(double time, float deltaTime) { for (auto c : m_Components) c->Update(time, deltaTime); }
    
private:
    std::string m_Name;
    ComponentVector m_Components;
};

// The "scene": array of game objects.
static GameObjectVector s_Objects;


// Finds all components of given type in the whole scene
template<typename T>
static ComponentVector FindAllComponentsOfType()
{
    ComponentVector res;
    for (auto go : s_Objects)
    {
        T* c = go->GetComponent<T>();
        if (c != nullptr)
            res.emplace_back(c);
    }
    return res;
}

// Find one component of given type in the scene (returns first found one)
template<typename T>
static T* FindOfType()
{
    for (auto go : s_Objects)
    {
        T* c = go->GetComponent<T>();
        if (c != nullptr)
            return c;
    }
    return nullptr;
}

Ok, 100 lines of code is a lot to dump at once, so let's work through what this is... Another bit of background is required -- it was popular for games in the 90's to use inheritance to solve all their code re-use problems. You'd have an Entity, extended by Character, extended by Player and Monster, etc... This is implementation-inheritance, as described earlier (a code smell), and it seems like a good idea to begin with, but eventually results in a very inflexible code-base. Hence that OOD has the "composition over inheritance" rule, above. So, in the 2000's the "composition over inheritance" rule became popular, and gamedevs started writing this kind of code instead.

What does this code do? Well, nothing good :D 

To put it in simple terms, this code is re-implementing the existing language feature of composition as a runtime library instead of a language feature. You can think of it as if this code is actually constructing a new meta-language on top of C++, and a VM to run that meta-language on. In Aras' demo game, this code is not required (we'll soon delete all of it!) and only serves to reduce the game's performance by about 10x.

What does it actually do though? This is an "Entity/Component" framework (sometimes confusingly called an "Entity/Component system") -- but completely different to an "Entity Component System" framework (which are never called "Entity Component System systems" for obvious reasons). It formalizes several "EC" rules:

  • the game will be built out of featureless "Entities" (called GameObjects in this example), which themselves are composed out of "Components".
  • GameObjects fulfill the service locator pattern -  they can be queried for a child component by type. 
  • Components know which GameObject they belong to - they can locate sibling componets by querying their parent GameObject.
  • Composition may only be one level deep (Components may not own child components, GameObjects may not own child GameObjects).
  • A GameObject may only have one component of each type (some frameworks enforced this, others did not).
  • Every component (probably) changes over time in some unspecified way - so the interface includes "virtual void Update".
  • GameObjects belong to a scene, which can perform queries over all GameObjects (and thus also over all Components).

This kind of framework was very popular in the 2000's, and though restrictive, proved flexible enough to power countless numbers of games from that time and still today.

However, it's not required. Your programming language already contains support for composition as a language feature - you don't need a bloated framework to access it... Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature. Worse than that though, it's not even the only way that you could implement runtime composition! For example, Unity is based on C# as a "scripting language", and many other games use alternatives such as Lua -- your designer-friendly tool can generate C#/Lua code to define new game-objects, without the need for this kind of bloated framework! We'll re-add this "feature" in a later follow-up post, in a way that doesn't cost us a 10x performance overhead...

Let's evaluate this code according to OOD:

  • GameObject::GetComponent uses dynamic_cast. Most people will tell you that dynamic_cast is a code smell - a strong hint that something is wrong. I would say that it indicates that you have an LSP violation on your hands -- you have some algorithm that's operating on the base interface, but it demands to know about different implementation details. That's the specific reason that it smells.
  • GameObject is kind of ok if you imagine that it's fulfilling the service locator pattern.... but going beyond OOD critique for a moment, this pattern creates implicit links between parts of the project, and I feel (without a wikipedia link to back me up with comp-sci knowledge) that implicit communication channels are an anti-pattern and explicit communication channels should be preferred. This same argument applies to bloated "event frameworks" that sometimes appear in games...
  • I would argue that Component is a SRP violation because its interface (virtual void Update(time)) is too broad. The use of "virtual void Update" is pervasive within game development, but I'd also say that it is an anti-pattern. Good software should allow you to easily reason about the flow of control, and the flow of data. Putting every single bit of gameplay code behind a "virtual void Update" call completely and utterly obfuscates both the flow of control and the flow of data. IMHO, invisible side effects, a.k.a. action at a distance, is the most common source of bugs, and "virtual void Update" ensures that almost everything is an invisible side-effect.
  • Even though the goal of the Component class is to enable composition, it's doing so via inheritance, which is a CRP violation.
  • The one good part is that the example game code is bending over backwards to fulfill the SRP and ISP rules -- it's split into a large number of simple components with very small responsibilities, which is great for code re-use.
    However, it's not great as DIP -- many of the components do have direct knowledge of each other.

So, all of the code that I've posted above, can actually just be deleted. That whole framework. Delete GameObject (aka Entity in other frameworks), delete Component, delete FindOfType. It's all part of a useless VM that's breaking OOD rules and making our game terribly slow.

Frameworkless composition (AKA using the features of the #*@!ing programming language)

If we delete our composition framework, and don't have a Component base class, how will our GameObjects manage to use composition and be built out of Components. As hinted in the heading, instead of writing that bloated VM and then writing our GameObjects on top of it in our weird meta-language, let's just write them in C++ because we're #*@!ing game programmers and that's literally our job.

Here's the commit where the Entity/Component framework is deleted: https://github.com/hodgman/dod-playground/commit/f42290d0217d700dea2ed002f2f3b1dc45e8c27c
Here's the original version of the source code: https://github.com/hodgman/dod-playground/blob/3529f232510c95f53112bbfff87df6bbc6aa1fae/source/game.cpp
Here's the modified version of the source code: https://github.com/hodgman/dod-playground/blob/f42290d0217d700dea2ed002f2f3b1dc45e8c27c/source/game.cpp

The gist of the changes is:

  • Removing ": public Component" from each component type.
  • I add a constructor to each component type.
    • OOD is about encapsulating the state of a class, but since these classes are so small/simple, there's not much to hide -- the interface is a data description. However, one of the main reasons that encapsulation is a core pillar is that it allows us to ensure that class invariants are always true... or in the event that an invariant is violated, you hopefully only need to inspect the encapsulated implementation code in order to find your bug. In this example code, it's worth us adding the constructors to enforce a simple invariant -- all values must be initialized.
  • I rename the overly generic "Update" methods to reflect what they actually do -- UpdatePosition for MoveComponent and ResolveCollisions for AvoidComponent.
  • I remove the three hard-coded blocks of code that resemble a template/prefab -- code that creates a GameObject containing specific Component types, and replace it with three C++ classes.
  • Fix the "virtual void Update" anti-pattern.
  • Instead of components finding each other via the service locator pattern, the game objects explicitly link them together during construction.

The objects

So, instead of this "VM" code:

    // create regular objects that move
    for (auto i = 0; i < kObjectCount; ++i)
    {
        GameObject* go = new GameObject("object");

        // position it within world bounds
        PositionComponent* pos = new PositionComponent();
        pos->x = RandomFloat(bounds->xMin, bounds->xMax);
        pos->y = RandomFloat(bounds->yMin, bounds->yMax);
        go->AddComponent(pos);

        // setup a sprite for it (random sprite index from first 5), and initial white color
        SpriteComponent* sprite = new SpriteComponent();
        sprite->colorR = 1.0f;
        sprite->colorG = 1.0f;
        sprite->colorB = 1.0f;
        sprite->spriteIndex = rand() % 5;
        sprite->scale = 1.0f;
        go->AddComponent(sprite);

        // make it move
        MoveComponent* move = new MoveComponent(0.5f, 0.7f);
        go->AddComponent(move);

        // make it avoid the bubble things
        AvoidComponent* avoid = new AvoidComponent();
        go->AddComponent(avoid);

        s_Objects.emplace_back(go);
    }

We now have this normal C++ code:

struct RegularObject
{
	PositionComponent pos;
	SpriteComponent sprite;
	MoveComponent move;
	AvoidComponent avoid;
	
    RegularObject(const WorldBoundsComponent& bounds)
		: move(0.5f, 0.7f)
		// position it within world bounds
		, pos(RandomFloat(bounds.xMin, bounds.xMax),
		      RandomFloat(bounds.yMin, bounds.yMax))
		// setup a sprite for it (random sprite index from first 5), and initial white color
		, sprite(1.0f,
		         1.0f,
		         1.0f,
		         rand() % 5,
		         1.0f)
	{
	}
};

...
  
// create regular objects that move
regularObject.reserve(kObjectCount);
for (auto i = 0; i < kObjectCount; ++i)
	regularObject.emplace_back(bounds);

The algorithms

Now the other big change is in the algorithms. Remember at the start when I said that interfaces and algorithms were symbiotic, and both should impact the design of the other? Well, the "virtual void Update" anti-pattern is also an enemy here. The original code has a main loop algorithm that consists of just:

    // go through all objects
    for (auto go : s_Objects)
    {
        // Update all their components
        go->Update(time, deltaTime);

You might argue that this is nice and simple, but IMHO it's so, so bad. It's completely obfuscating both the flow of control and the flow of data within the game. If we want to be able to understand our software, if we want to be able to maintain it, if we want to be able to bring on new staff, if we want to be able to optimise it, or if we want to be able to make it run efficiently on multiple CPU cores, we need to be able to understand both the flow of control and the flow of data. So "virtual void Update" can die in a fire.

Instead, we end up with a more explicit main loop that makes the flow of control much more easy to reason about (the flow of data is still obfuscated here, we'll get around to fixing that in later commits)

	// Update all positions
	for (auto& go : s_game->regularObject)
	{
		UpdatePosition(deltaTime, go, s_game->bounds.wb);
	}
	for (auto& go : s_game->avoidThis)
	{
		UpdatePosition(deltaTime, go, s_game->bounds.wb);
	}
	
	// Resolve all collisions
	for (auto& go : s_game->regularObject)
	{
		ResolveCollisions(deltaTime, go, s_game->avoidThis);
	}

The downside of this style is that for every single new object type that we add to the game, we have to add a few lines to our main loop. I'll address / solve this in a future blog in this series.

Performance

There's still a lot of outstanding OOD violations, some bad design choices, and lots of optimization opportunities remaining, but I'll get to them with the next blog in this series. As it stands at this point though, the "fixed OOD" version either almost matches or beats the final "ECS" code from the end of the presentation... And all we did was take the bad faux-OOP code and make it actually obey the rules of OOP (and delete 100 lines of code)!

dod-chart1.png.0c63b0194df0f816028ace719b898cd3.png

Next steps

There's much more ground that I'd like to cover here, including solving the remaining OOD issues, immutable objects (functional style programming) and the benefits it can bring to reasoning about data flows, message passing, applying some DOD reasoning to our OOD code, applying some relational wisdom to our OOD code, deleting those "entity" classes that we ended up with and having purely components-only, different styles of linking components together (pointers vs handles), real world component containers, catching up to the ECS version with more optimization, and then further optimization that wasn't also present in Aras' talk (such as threading / SIMD). No promises on the order that I'll get to these, or if, or when...

 



63 Comments


Recommended Comments



Maybe you're going to address this in the next part you mentioned, but languages could really use more neat tools to avoid all the boilerplate you have to write and read.

With methods like update and generic things like 'GameObject' you're tempted because you never have to touch that code again, and the codebase 'magically' accounts for everything when you add a new component type. And the 'main loop' that just calls the updates is never a real source of errors, as opposed to the specific style where you can (and this happens to me a ton) actually just forget to add the actual function call which may cost you a precious sanity on a bad day.

I guess a good metaprogramming language and a way to 'tag' functions/methods and variables/attributes (templates certainly aren't this) so you can look them up in the metaprogramming language later is all you'd need there, but C++ doesn't have it...

As you pointed out, the thing about 'static so a programmer has to change it' vs 'dynamic so designers can change it with a tool' is not really a thing considering the tool can theoretically spit out generated code in whatever language you need, but again the ecosystem bites you because actually doing that is a lot more complicated (if you want to be able to change stuff while the game/engine is running) than writing something data driven and loading/reloading a bunch of text files instead. 

Edited by agleed

Share this comment


Link to comment

I'd upvote this even more if I could. Thanks, Hodgman, you're a beautiful person for going above and beyond like this.

Share this comment


Link to comment

The trouble is that pretty much everyone I've talked to who learned OO in university learned the "bad" OO - and given that I've spoken to some fairly recent graduates, this is still ongoing. What do we need to do to remedy this? Do we need to get actual programmers applying to be "intro to OOD" guest lecturers?

Share this comment


Link to comment

Every "OO" codebase I've had the pleasure to work on in the last 6 years in the software industry has been a disaster of every form of "bad OO". And it hasn't been uncommon for me to be the only person on the project who has any recognition of that fact. Outside of GDNet I know... maybe 8-10 total software engineers who could name the issues with "java-style OO" that Hodgman lays out.

I'm not sure it's even feasible to tackle the university pipeline when so much of the software industry doesn't take this stuff as a given.

Share this comment


Link to comment

As a beginner, the only thing I can say is thank you for bringing this kind of content.

Share this comment


Link to comment
45 minutes ago, swiftcoder said:

Every "OO" codebase I've had the pleasure to work on in the last 6 years in the software industry has been a disaster of every form of "bad OO". And it hasn't been uncommon for me to be the only person on the project who has any recognition of that fact. Outside of GDNet I know... maybe 8-10 total software engineers who could name the issues with "java-style OO" that Hodgman lays out.

I'm not sure it's even feasible to tackle the university pipeline when so much of the software industry doesn't take this stuff as a given.

Maybe we just need a snappy new name. Natural languages being what they are, the meanings of words tend to evolve; if enough people agree that OO refers to what we're all calling "bad OO" in this thread, then that's what "OO" means, regardless of what we think of the matter. :(

Share this comment


Link to comment

Thank you for this very interesting article which points at a lot of valid concerns about poor OOP/OOD usage.

I understand it is still a work in progress but I am a bit concerned about cache utilization in the current proposed solution versus the ECS / relational model one.
I might have missed some details but from a quick glance at the code, it looks like game objects such as AvoidThis are laid out sequentially in memory.

 std::vector<AvoidThis> avoidThis;

and iterated to update positions like this:

for (auto& go : s_game->avoidThis)
{
    UpdatePosition(deltaTime, go, s_game->bounds.wb);
}

(and once again later to update the sprite data.)

With a definition like this:

struct AvoidThis
{
    AvoidThisComponent avoid; // 1 float = 4 bytes
    PositionComponent pos; // 2 floats = 8 bytes
    MoveComponent move; // 2 floats = 8 bytes
    SpriteComponent sprite; // 3 floats + 1 int + 1 float = 20 bytes
};

and with 64 bytes cache lines, we can fit less than 2 game objects per cache line.
To update the positions, we would only need the PositionComponent and the MoveComponent allowing 4 game objects per cache line.

Am I missing something? Is this something you intend to work on?

Another concern I have is about the disparition of the "Systems" (compared to ECS). By bringing the behavior closer to the data (i.e. by moving the update functions back into the components), you get further away from the "Where there is one, there are many." principle, making it more difficult to optimize with knowledge at a global level (e.g. use spatial partitioning for collision avoidance).

I am also a bit curious about the difference in memory size compared to ECS. Part of it lies in the extra entity sets (std::vector<EntityID>) maintained per system (which I think would also be needed in the OOD version if disjoint sets were not sufficient to solve the problem) but the OOD solution doesn't store a name per entity while the ECS one does. Doesn't this explain a good part of the difference?

Considering the amount of improvements you suggest at the end of the article, I am quite confident you are already aware of these issues and am eager to read the rest of the series.

Thanks again for a great article.

Edited by ozirus

Share this comment


Link to comment

A problem with your take on ECS-like in OOP:

Refering to this:

Quote

The implementation of an - let's call it - *entity*:

struct RegularObject
{
	PositionComponent pos;
	SpriteComponent sprite;
	MoveComponent move;
	AvoidComponent avoid;
	
    RegularObject(const WorldBoundsComponent& bounds)
		: move(0.5f, 0.7f)
		// position it within world bounds
		, pos(RandomFloat(bounds.xMin, bounds.xMax),
		      RandomFloat(bounds.yMin, bounds.yMax))
		// setup a sprite for it (random sprite index from first 5), and initial white color
		, sprite(1.0f,
		         1.0f,
		         1.0f,
		         rand() % 5,
		         1.0f)
	{
	}
};

The composition of the entity is fixed at compile time. Using pointers or booleans to invalidate a component, it is possible to enable and disable them at runtime.

However it is impossible to add or remove components other than those specified -> Runtime Composability is gone.

  • You have to add a member for every component you want your entity to ever have over the course of the game at compile-time - or you fall back on inheritance and add a Component class that every component needs to inherit, leaving you with run-time casts.
  • Some of these components might even only be used at one point under a certain circumstance, though, so that's wasted memory, even if you only use pointers.
  • Furthermore, if you end up implementing a new component later on, you have to revisit every Entity/Object/whatever that should have this component, and add it manually.

Some implementations of relational data/"ECS" rely on runtime composability, as they configure systems not by taking entities as input, or - worse - entities working on themselves, but by having e.g. a Storage-Vector (not necessarily a Vector, ... ). This Storage-Vector is coupled with a BitSet, holding all entity ID's that have this component, and when the system runs, it skims through the BitSets of the components it requests and finds those that belong to the same Entity, and ONLY picks them up if every component is present on this entity.

Edited by Iltis

Share this comment


Link to comment
51 minutes ago, Iltis said:
However it is impossible to add or remove components other than those specified -> Runtime Composability is gone.

I think this was specifically addressed in the article as a sort of downside - but then he made a point the c++ is not really meant to be an interpreted language like this and thats what scripting languages are for.

It would be cool to see (maybe in the next blog entry?) a way to do this where run time dynamic components are possible - maybe using lua or something

It certainly makes the code less confusing and is more commonsense to write it this way. Easier to debug and profile too. Lots of benefits - I guess you would have to decide if you want to give up the dynamic game object or not. It seems like it wouldn't be too difficult to implement that portion (for some kind of editor or tool) in a scripting language as he mentioned.

Share this comment


Link to comment
1 hour ago, Iltis said:

The composition of the entity is fixed at compile time.

You're presupposing that it shouldn't be.

I would say that having runtime composability as a default is overengineering as long as you're writing a game (not an engine). If you need runtime composability for something, you can introduce it in small, controlled amounts where it is appropriate to solve the problems at hand, and you can do it in better ways than "entities with pointers to components". An approach I've found works fairly well is to divide entities up into types based on which components I know they'll have at compile time, then use separate "services" (in ECS terminology, "component arrays" coupled with "systems") to decorate instances of those specific entity types with extra state they need at runtime. If taken to extremes, this can result in something that looks like ECS, but was designed with a different approach than "throw all the components for all the entities ever in their own arrays."

Edited by Oberon_Command

Share this comment


Link to comment
41 minutes ago, Oberon_Command said:

I would say that having runtime composability as a default is overengineering as long as you're writing a game (not an engine).

I was under the assumption that the code was meant to be reusable.

If you only want to write one game with it, then I agree, it is a bit much.

 

1 hour ago, EarthBanana said:

It would be cool to see (maybe in the next blog entry?) a way to do this where run time dynamic components are possible

Just to clarify: I meant adding and removing existing components at runtime, not creating completely new ones (although that might be interesting in some cases)

Edited by Iltis

Share this comment


Link to comment
2 hours ago, Iltis said:

I was under the assumption that the code was meant to be reusable.

If you only want to write one game with it, then I agree, it is a bit much.

Depends on your definition of "reusable." As a gameplay programmer, I find the important kind of reusability is being reusable in multiple situations in the same program, not reusable across projects. Concerns like rendering, audio, and  animation (ie. "engine code") are a different story. The reusable parts in the examples we're talking about would be the "components," in any case, not the entities. This would be true regardless of whether the composition was compile-time or run-time, or whether we were reusing them across parts of a game or across different games.

I would not expect games that aren't sequels, reskins, or mods to share a whole lot of gameplay code. Certainly not enough that reusing entity archetypes across projects would be of much interest to me, never mind a driving requirement of my gameplay architecture. Different gameplay begets different code.

Edited by Oberon_Command

Share this comment


Link to comment
7 hours ago, ozirus said:

Thank you for this very interesting article which points at a lot of valid concerns about poor OOP/OOD usage.

I understand it is still a work in progress but I am a bit concerned about cache utilization in the current proposed solution versus the ECS / relational model one.
I might have missed some details but from a quick glance at the code, it looks like game objects such as AvoidThis are laid out sequentially in memory.

I've already got more content in the Github waiting for blog text to accompany it. One of the first tasks is fixing the memory layouts, yes :)

Sourcing the components from a pool allocator results in pretty much the same memory layout as the ECS version. I'll also switch from using pointers to link components to integer handles at some point, as they're smaller and make the flow of control easier to reason about (important when we get to threading). 

7 hours ago, ozirus said:

Another concern I have is about the disparition of the "Systems" (compared to ECS). By bringing the behavior closer to the data (i.e. by moving the update functions back into the components), you get further away from the "Where there is one, there are many." principle, making it more difficult to optimize with knowledge at a global level (e.g. use spatial partitioning for collision avoidance).

Class static functions can be used to process many objects, while accessing private implementation details and preserving the public interface. This does have the downside that you can only peek into one class' internals at a time though... It's also good C++ advice to liberally use free-functions (in the style of systems!!) when possible. If it's possible to implement a procedure as a free-function instead of a member function (i.e. the algorithm only depends on the public interface), then you should use a free-function. Java and C# got this terribly wrong when they excluded free functions from their design and forced everything to be a member.
We'll get into this more as I try to catch up to Aras' "Update" perf numbers. 

7 hours ago, ozirus said:

the OOD solution doesn't store a name per entity while the ECS one does. Doesn't this explain a good part of the difference?

That's an honest mistake on my part. Because none of the game uses names at all, I didn't notice I'd culled that feature when deleting the EC framework... I'll recompile Aras' ECS code without support for names for make it an apple's to apples comparison. Thanks! 

5 hours ago, Iltis said:

The composition of the entity is fixed at compile time.  Runtime Composability is gone.

Yeah I mentioned this in the article but maybe didn't make a big deal about it enough. This game (and most games) don't need that kind of VM. I'll address this further in another blog. 

Note that even without this component VM, you can still get runtime composition if your language supports it. e.g. You could write your components in C and your entities in Lua! 

5 hours ago, Iltis said:

Furthermore, if you end up implementing a new component later on, you have to revisit every Entity/Object/whatever that should have this component, and add it manually.

That's the same no matter the language / VM that you're using. With a composition VM, you have to edit the JSON files or whatever you serialise your game object templates as... If you add a new feature, you have to plug it in.

4 hours ago, Oberon_Command said:

I would say that having runtime composability as a default is overengineering

^THIS^

If you're writing a magic buff system where you need to add N poison over time components, resistance to ice components, reflect damage components, bonus to fire damage components, skill boost aura components, etc, etc... Then fair enough - build a framework specifically for that situation. Don't use such a complex framework *by default* though -- that's just as bad as using inheritance by default. Write the specific code that you need. 

3 hours ago, Iltis said:

I was under the assumption that the code was meant to be reusable.

The fact that it's designed as many small components (i.e. Follows the SRP) means that the bulk of it is reusable. Whether you define game objects in C, Lua or JSON has no impact on whether it's reusable or not) assuming you have gameplay staff who are competent in C/Lua/JSON).

The SOLID-C rules are designed to encourage you to create code that's easily reusable.

Share this comment


Link to comment

From my experience, what data oriented design addresses is the optimizations of the high frequency codepaths. In regards to game programming, it's mainly about tasks that execute every frame or at a very high frequency, like unit movement, AI, animation. So it can be very useful to layout the data in favor of those operations because they run 90% of the time. increasing their cache coherency can improve the overall FPS greatly. As for lower frequency operations, like firing a gun, pressing the jump button, which accounts for 90% of the codebase, are easily written in the OOP manner without a huge performance impact. Can their data be grouped in a cache coherent manner? I don't know. Some ECS/DOD gurus might have the answer.

In short, DOD is at least about grouping high frequency data together.

Share this comment


Link to comment
12 minutes ago, Fulcrum.013 said:

Generaly it impossible to increase it chache coherency becouse size of most instances exids size of chache line. For some components its possible to increase code locality using a pools of same kind objects. It works well for passive objects like bullets and so on that can not change trajectory by its descigion. But again it have mach better architecture that not break common architecture with virtual Update. Just pull have a virtual Update method that called once per pool and run a loop to process each of its tiny instances using static dispatch. 

In my mind, if you're going to have a bunch of pools of distinctly-behaving objects, anyway, there's not a whole lot of point to making that Update method virtual, nor much point in calling it "Update." Just name it according to what it does - "MoveBullets" - and put a call to pool.MoveBullets at the appropriate place in the main loop. That way you can see in the code what each pool is doing when. 

Here's a few lines illustrating the principle from a side project I'm working on:

combat.resolve_attacks(collision, status);
hazards.apply_status_effects(status);
characters.update_sprite_data(sprites);
sprites.update_animations(dt);
particles.update_all_particles(dt);

projectiles.update_all_projectiles(dt);
projectiles.resolve_collision(status, collision);

Look how simple this is! I can control the order in which each of the steps happen. No PreUpdate or PostUpdate or deferred update queues. All I need to do to work out when something happens is look at my main loop code to see where it happens. If I had a "virtual void Update" thing going on this code snippet would be a bit shorter (and this is not the complete function!), but tracing execution flow and debugging would be a lot harder. The compiler could probably inline some of these shorter updates, too. Sometimes simple declarative-looking logic is nicer than a 6 line loop.

Edited by Oberon_Command

Share this comment


Link to comment
7 hours ago, Fulcrum.013 said:

If profile data will show that a virtuall calls actually a problem its will also show that its hardware not ready to games or other realtime simulations at all.

The (straw-man) data in the article shows a 10x performance improvement by removing virtual calls (i.e. 90% of the execution time was being wasted). This is running on a typical gaming PC from a few years ago (i7 CPU)... Definitely read for games.

Your other comments seem to be implying that if you don't use virtual / dynamic dispatch, then your alternative is to use static dispatch with O(log N) complexity (e.g. a switch)... That's just swapping the mechanism without fixing the underlying problem. For example in the code in the article, we've removed virtual without adding a switch -- we've gone from O(1) to O(0) by approaching the problem from a different direction.

6 hours ago, Yixin Xie said:

From my experience, what data oriented design addresses is the optimizations of the high frequency codepaths. ... As for lower frequency operations, like firing a gun, pressing the jump button, which accounts for 90% of the codebase, are easily written in the OOP manner without a huge performance impact.

OOP != slow. You can (and should!) use OOD and DOD at the same time. They're orthogonal concerns -- one on writing reusable and manageable software (fits well with human authors), and one on writing software that does the minimal amount of work (fits will with machine hardware).

6 hours ago, Fulcrum.013 said:

(1) Generaly it impossible to increase it chache coherency becouse size of most instances exids size of chache line. (2) For some components its possible to increase code locality using a pools of same kind objects.

(1) No, because (2) Yes.

Generally if you've split up your objects properly, you can (and should) create memory layouts based on the actual patterns of you flow of execution / flow of data.

Also, one cache line isn't the limit for locality. The prefetcher pulls in a lot more data than one line at a time, so it's important to have long sequential runs of hot data... 

Share this comment


Link to comment
10 minutes ago, Oberon_Command said:

If I had given a "virtual void Draw()" method to each of these, the main loop would have less code, but the flow of the rendering code would be a lot harder to follow and debug.

Yep. "virtual void Update" (or Draw) on a pool is 100x times better than doing it per object, but it's still obfuscating the flow of control, and still obfuscating the flow of data. If your main loop is just a loop that calls Update on a list of things, it's impossible to reason about which things have data dependencies on which other things.

By the time I get around to adding threading to this example code, I want to have it in a state where data dependencies are trivial to reason about.

Share this comment


Link to comment
6 minutes ago, Hodgman said:

 By the time I get around to adding threading to this example code, I want to have it in a state where data dependencies are trivial to reason about.

That's the other thing - notice that in my sample I'm passing the services/pools that each method needs directly to each method. The dependencies are injected to the method that actually needs them; the individual services and pools don't store them! This makes dependency reasoning really straightforward at the expense of having bigger function signatures (which, oddly enough, has been encouraging me to write updaters that have fewer dependencies).

Sometimes I wish the mainstream engines gave me control over their main loops so I could do stuff like this.

Edited by Oberon_Command

Share this comment


Link to comment
3 minutes ago, Oberon_Command said:

Just name it according to what it does - "MoveBullets" - and put a call to pool.MoveBullets at the appropriate place in the main loop. That way you can see in the code what each pool is doing when. 

Really i have for ecample up to 50 spaseships that each can fire up to 3000 bullets per minute. Each phisical/logical simulation onject have it own set of Update functions for some of actions like recalculate autopilots, recalculate engines, collide and so on. Each object just can unsubscribe action that it put to rest for now by its solo descign. Bullets pool is same object that contain for example a bullets and unguided missiles that run out of a fuel. Other pool contain a unguided missiles that have a working engines yet, from wich missiles shifted to bullets pool after run out of fuel/. Empty pool unsubscribed from any actions. But when it receive a conent it subscribed to required actions. obviously subscription/unsubscribtion works much rare than processing,and active missiles and bullets pools have to be subscribed to different set of actions.As result anything of it just processed as abstract object witout any problems for perfomance, but ready to put-in-model-and-forget objects managment scheme. Really virtual dispatch affect perfomance only in cases called function is tiny, but for heavy functions its just overhead that not worth to account.

Share this comment


Link to comment
20 minutes ago, Fulcrum.013 said:

Really i have for ecample up to 50 spaseships that each can fire up to 3000 bullets per minute. Each phisical/logical simulation onject have it own set of Update functions for some of actions like recalculate autopilots, recalculate engines, collide and so on. Each object just can unsubscribe action that it put to rest for now by its solo descign. Bullets pool is same object that contain for example a bullets and unguided missiles that run out of a fuel. Other pool contain a unguided missiles that have a working engines yet, from wich missiles shifted to bullets pool after run out of fuel/. Empty pool unsubscribed from any actions. But when it receive a conent it subscribed to required actions. obviously subscription/unsubscribtion works much rare than processing,and active missiles and bullets pools have to be subscribed to different set of actions.As result anything of it just processed as abstract object witout any problems for perfomance, but ready to put-in-model-and-forget objects managment scheme. Really virtual dispatch affect perfomance only in cases called function is tiny, but for heavy functions its just overhead that not worth to account.

It sounds to me like we're largely in agreement here. Sort your data according to its behaviour! :)

You can even use separate pools for the same "object" (as the user would see it) that's in a different state. Eg. from the same project as the snippet I posted earlier, instead of having a variable on my weapon class that indicates whether it is lying on the ground, being held by a character, or has just been dropped, and instead of representing that with a set of "weapon state" classes with virtual update functions, my "weapon pool" stores three vectors of weapons:

std::vector<WeaponDatum> FreeWeapons;
std::vector<WeaponDatum> BoundWeapons;
std::vector<WeaponDatum> DroppedWeapons;

Then it applies different logic to each one; free weapons just idle and wait for something to pick them up, bound weapons mimic their owner's animations, and dropped weapons start playing the idle animation, then enter the free state. Switching states means moving a weapon from one "sub-pool" to another one. I haven't yet, but there are some further optimization opportunities here - the "free" (ie. not being held or dropped) weapons don't need to store a reference to the character that owns them, for instance.

Edited by Oberon_Command

Share this comment


Link to comment

After reading most of the article, I felt I had two points to make:

1. I agree that object oriented design doesn't have to be as bad as it usually turns out, and DOD overlaps heavily with relational database theory. However, I think that the most important distinction here is that DOD asks that data (not code) is considered first, whereas OOP assumes data joined with and secondary to its code and asks you to compose them in some subjectively pleasing way.

Ultimately, code is the tool that transforms data, and not the other way around. That said, it is also a tool for communicating processes to various audiences, so I'm waiting for the day that we'll stop thinking in extreme principles and find a way to reconcile both (and possibly other) purposes so that they work together to the extent possible.

2. Can we finally drop SOLID(C) please? Should be obvious by now that some of the rules are vague and infeasible at best and self-serving at worst.

SRP - what is "single"? Is "game" single? Is manager single? Entity, vector, float, byte? Tree, node, part of node? Is multiply+add not single, and what about SIMD? Where do we vote about all of these? Principles that mean nothing specific are only used as a tool to justify screaming about how poor someone else's code is, regardless of whether that is actually the case.

O/CP - in my experience, when the data changes, the interfaces change as well (for optimal access). And similarly, I find implementations to be extremely difficult to substitute without side effects, since they themselves have often very different I/O constraints, performance characteristics and side effects. So I'm not sure in what fairy tale world is interface lockdown or trying to accomodate unforeseen implementations productive.

LSP - in general, there's nothing to object to and people generally try to do this. That said, interfaces are frequently used to bridge inherently incompatible constructs (such as different rendering backends) where support for certain features is limited and it would be pointless to go to extremes to provide perfect feature parity.

ISP - no objections here. Note that this is the only principle for which you have yourself provided a practical argument to support it.

DIP - interfaces exist to bridge multiple implementations, otherwise implementations could be used directly, which is also beneficial for performance due to inlining and lack of virtual calls, and greatly simplifies allocation of data. You say that a POD struct for communication is enough but how is a POD struct different from a regular function parameter list? And I can almost guarantee that a plain function won't be considered DIP-compliant by many people. I would argue that it's merely a somewhat obvious tool used to accomodate refactoring, definitely not a principle.

CRP - while seemingly nice in theory, there is the practical consideration of C++ multiple inheritance casting headaches as well as the issue of composing components that need to know about their parent objects or neighbors. Inheritance, while not without its numerous downsides, solves the parent object issue without extra pointers.

Since you only mention SOLID(C) in your code criticism, and not design, I would argue that the worth of most of these is limited to justifying being annoyed about someone's code, unlike a concrete code example, which also shows an alternative implementation, open to concrete and fact-based comparisons, reviews and future improvements.

Share this comment


Link to comment
1 hour ago, snake5 said:

DOD asks that data (not code) is considered first, whereas OOP assumes data joined with and secondary to its code and asks you to compose them in some subjectively pleasing way

OOP's joining of code + data isn't some subjective voodoo. The separation of implementation details from simpler interface declarations is meant to reduce coupling through thin interfaces (ISP) but also for the purpose of enforcing class invariant. e.g. in C++ vector::resize is a member function, because it alters the internal pointers. There's a lot of invariants involving those pointers, so they're hidden within the implementation so you can easily reason that any bugs with them are caused by that implementation and not user code. On the other hand std::find is not a member function, because it's an algorithm that does not depend on any internal details of a vector.

If the data needs to be controlled to enforce class invariants, then it's internal. If code needs to interact with that fragile data, then it needs to be a member. If code doesn't need to interact with that fragile data, then it should be a free function (not a member).

The Java school of OOP shits all over this idea though and decides that everything should be a member...
In C++ we're taught to try and make as much of our logic as free-functions (not members) as possible.

1 hour ago, snake5 said:

Can we finally drop SOLID(C) please? Should be obvious by now that some of the rules are vague and infeasible at best and self-serving at worst.

Uh, no.

1 hour ago, snake5 said:

SRP - what is "single"? Is "game" single? Is manager single? Entity, vector, float, byte? Tree, node, part of node? Is multiply+add not single, and what about SIMD? Where do we vote about all of these? Principles that mean nothing specific are only used as a tool to justify screaming about how poor someone else's code is, regardless of whether that is actually the case.

I, really don't get what you're trying to say here... If a class has multiple different invariants that it's enforcing, can you draw a line through the class that splits them cleanly, so that some members + invariants are on one side of the line, and other members + invariants are on the other side of the line? If yes, then you can split that class into two. If not, then you can't. If you don't know what invariants your class exists to enforce then, sure, get confused.

1 hour ago, snake5 said:

O/CP - in my experience, when the data changes, the interfaces change as well (for optimal access).

The entire std library would be one example. The interface is agreed upon but there's several different implementations of it that work quite differently.
Or in a game project one time, we ported an Xb360/PS3 game to XbOne/PS4 by isolating the interface between the game and the engine and building a completely new engine underneath that interface.
Or in general, any bit of software that has a public specification (GL, Vulkan, C++, ECMAScript, etc...) follows this guideline.

It's a pretty vanilla guideline really -- "specs are good if they don't change, try your best not to change the spec". Very bland and acceptable...

1 hour ago, snake5 said:

DIP - interfaces exist to bridge multiple implementations, otherwise implementations could be used directly, which is also beneficial for performance due to inlining and lack of virtual calls, and greatly simplifies allocation of data. You say that a POD struct for communication is enough but how is a POD struct different from a regular function parameter list? 

The problem that DIP is solving is layered software.

Typically when designing large scale projects you want to build it up in layers. Everything in Layer 0 only uses other code in Layer 0 ("the core"). Then, you build more specific modules that exist on Layer 1 -- code in those modules only accesses code within their own module plus code in Layer 0 (e.g. graphics depends on core, input depends on core). Then you build even more specific modules that exist on Layer 2 and use all the code below (e.g. the game depends on graphics, input and core).

Instead of building things in vertical Layers, DIP offers a way to build horizontally and shift code down one layer. e.g. if you make an "input data" module that contains a just simple interface (e.g. data descriptions), then the input module and the game module can both depend on the input-data module, and now game no longer has to depend on the input module -- it can be moved down a layer to be horizontal to input.

This isn't just subjective, vague, hand-waving so that people can feel smug in code reviews and tell you that you've been a bad boy. I mean, that's what it sounds like you're complaining about? Some design nazi has used SOLID as a rolled up newspaper to whack you, unproductively, in a code review? If so, yeah that sucks, but don't let that put you off actually learning the useful parts of the theory....

This kind of planning is important on very large scale projects to keep the amount of dependencies between different parts of the code-base low so that you down drown in technical debt later. Reducing the surface area of modules like this, and the connections between modules, is a real concrete outcome.

1 hour ago, snake5 said:

CRP - while seemingly nice in theory, there is the practical consideration of C++ multiple inheritance casting headaches as well as the issue of composing components that need to know about their parent objects or neighbors. Inheritance, while not without its numerous downsides, solves the parent object issue without extra pointers.

Honestly, having two-way dependencies between components and their parents/neighbors is a bit of code smell, and often indicates that there's a bit of a mess of dependencies and an unclear structure. Usually if this kind of data is needed, it can be passed as arguments to the functions that actually do work, instead of being stored permanently in members, which solves the issue without extra pointers too.

1 hour ago, snake5 said:

I would argue that the worth of most of these is limited to justifying being annoyed about someone's code, unlike a concrete code example, which also shows an alternative implementation, open to concrete and fact-based comparisons, reviews and future improvements.

Didn't I post a github link and numeric comparisons of several metrics at the bottom? The original "faux OOP" code is subjectively and objectively terrible.

Share this comment


Link to comment

I'm a big proponent of bad/faux OOP in C++...... I use multiple inheritance everywhere, class hierarchies 15 levels deep, templates with 20 parameters where the base class is often a template parameter and I pretty much never never use the standard library.  On top of that I tend to make everything pubic unless I know for sure it should be private upfront, and then I go back and privatize stuff and clean things up after it works (assuming I don't forget).

I prioritize in this order:

1) Elegant  algorithms & data structures

2) Robust memory management

3) Speed

4) The structure of the code an how lit looks to others.

Mind you I'm not trying to sell anyone on my approach :D

Share this comment


Link to comment
14 minutes ago, Hodgman said:

OOP's joining of code + data isn't some subjective voodoo.

I totally agree, though what I consider to be subjective voodoo are the relationships and structure of objects themselves. This seems to appear the most in classes that are effectively layers of managers, proxies and factories.

20 minutes ago, Hodgman said:

If a class has multiple different invariants that it's enforcing, can you draw a line through the class that splits them cleanly, so that some members + invariants are on one side of the line, and other members + invariants are on the other side of the line? If yes, then you can split that class into two.

The question I ask is, should you split that class? I don't question the ability, as you have defined it, but the productivity of always doing so. Say you have a "human" component with "health" member. Does it make sense to move "health" to a separate component? Even if there is no other component that would need it? Likewise, multiply-add are clearly two separate operations, but are joined for performance reasons.

28 minutes ago, Hodgman said:

It's a pretty vanilla guideline really -- "specs are good if they don't change, try your best not to change the spec".

And a lot of good that did for OpenGL... :) as a particular counterexample, I see AZDO which is almost a self-sufficient subset of the broader, bloated API, which makes it pretty hard to argue that it was merely an extension. STL is for the most part a reasonable example in favor of the principle, though I find that it likely wasn't aimed at STL developers. And it's not like the spec hasn't changed at all over the years. IIRC, string::c_str() was at some point allowed to add the terminating zero at runtime and range-for was changed to allow for a separate end type.

43 minutes ago, Hodgman said:

The problem that DIP is solving is layered software.

Sure, I'm not against separation of software layers, but again, how does that make it a principle?

I'm not sure if there's a term for it, but there is a kind of dependency that is not explicitly written, but when a part is substituted for another with a fully compliant interface, something subtly breaks down regardless. Seems to be particularly common with computational geometry and image processing. Also observed with LLVM when manually specifying optimization passes to run. My point here is that no interface would help in this case, and making one only would cause performance issues (whether compile-time from templates or runtime from virtual interfaces), so how can something that doesn't always work be a principle?

52 minutes ago, Hodgman said:

Honestly, components needing to know about their parents or neighbors is a bit of code smell, and indicates that there's a bit of a mess of dependencies and an unclear structure.

I agree, but like I said, the issue here stems from practical considerations. When writing a game from scratch, all in the same code base and language, without data-driving anything, all such issues can probably be avoided quite easily, otherwise I'm not too sure.

 

All in all, my main point regarding SOLID(C) is that if some theory does not work always, without exceptions and provably so, it does not deserve to be a principle, and should not be applied unquestioningly. And this of course applies to the omnipresent horrible kind of OOP as well.

1 hour ago, Hodgman said:

Didn't I post a github link and numeric comparisons of several metrics at the bottom?

Please don't get me wrong, I did notice it and appreciate that a lot. I'm just saying that in my opinion, it has a great deal more value than all the criticism of original code, and so there should be even more code changes, metrics and reasoning behind the code changes.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By jnbutler
      How do you make it where the program itself does not exit until both windows are closed. I have a project and created two windows using two different window classes two different window handles and two different winprocs, two boolean variables hwnd0Closed and hwnd1Closed. Then inside each of the winprocs in the WM_CLOSE handlers, I have an if statement that tests the two boolean variables
      hwnd0Closed = true; if(hwnd0Closed && hwnd1Closed) { PostQuitMessage(0); } DestroyWindow(hwnd);  This is the one for hwnd0 in WindowProc0. A similar one is in WindowProc1 but sets the hwnd1Closed  = true. 
      This should not close the whole program until both the windows have been closed, but when I click on one of the windows X to close it, both of them close and the program shuts down. I have attached my full source code file.
      Thanks for any help you can provide.
       
      TwoWindows.cpp
    • By JeremyAlessi
      In episode #2, Jeremy adds some formatting by covering the news, reflecting on the inspiration for PixelFest, and delving into an important developer lesson; that period of time everyone faces when they have to decide whether to play a game or make a game with their time.
      https://youtu.be/fvaG_pIIUYM
       

      View full story
    • By JeremyAlessi
      In episode #2, Jeremy adds some formatting by covering the news, reflecting on the inspiration for PixelFest, and delving into an important developer lesson; that period of time everyone faces when they have to decide whether to play a game or make a game with their time.
      https://youtu.be/fvaG_pIIUYM
       
    • By calioranged
      This question is based on a completely hypothetical situation which has occurred to me. It is not a problem I am actually having, just one that I think could potentially occur in the future.
      Suppose that we have two vertex array objects - Squares_VAO and Trapezium_VAO:
      std::array<float, 18> square_vertices { -0.75F, 1.0F , 1.0F , // Position (Attribute 0) 0.5F , 0.0F , 0.0F , // Colour (Attribute 1) -1.0F , 1.0F , 1.0F , 0.5F , 0.0F , 0.0F , -1.0F , 1.0F , 0.75F, 0.5F , 0.0F , 0.0F , -0.75F, 1.0F , 0.75F, 0.5F , 0.0F , 0.0F }; Squares_VBO(squares_vertices); // sets up squares vbo... Squares_VAO; // sets up squares vao... std::array<float, 18> trapezium_vertices { -0.75F, 1.01F, 1.0F , // Colour (Attribute 0) 0.5F , 0.0F , 0.0F , // Position (Attribute 1) -1.0F , 1.0F , 1.0F , 0.5F , 0.0F , 0.0F , -1.0F , 1.0F , 0.75F, 0.5F , 0.0F , 0.0F , -0.75F, 1.0F , 0.75F, 0.5F , 0.0F , 0.0F }; Trapezium_VBO(trapezium_vertices); // sets up trapezium vbo... Trapezium_VAO; // sets up trapezium vao... The only difference between square_vertices and trapezium_vertices is that the position and colour attributes have swapped positions; in square_vertices, position and colour are attributes 0 and 1 respectively, and then vice versa for trapezium_vertices. 
      Suppose that the shader looks something like this:
      #vertex shader #version 330 core layout(location = 0) in vec4 position; layout(location = 1) in vec4 colours; //... There would obviously be an issue here where for the Trapezium_VAO, the attributes are going to be fetched the wrong way round (i.e. position will be attribute 0 and colour will be attribute 1). Obviously you could just correct this in trapezium_vertices (by swapping the location of the attributes), but suppose that for whatever reason this isn't possible - what would one do to solve this?
      There could be other scenarios similar to this, for example the attribute at a given location being a vec3 in one VAO and a vec4 in another VAO:
      std::array<float, 8> square_vertices { -0.75F, 1.0F, 1.0F, 0.5F // Position (Attribute 0) ... 0.5F , 0.0F, 0.0F, 0.0F }; std::array<float, 6> triangle_vertices { -0.75F, 1.0F, 1.0F, // Position (Attribute 0) ... 0.5F , 0.0F, 0.0F }; ... #vertex shader #version 330 core layout(location = 0) in vec4 position; // will only work for square_vertices, since has 4 components per vertex.. // whereas triangle_vertices has 3 components per vertex... How could one get around this?
       
    • By NeedHelp12
      Hello,
      I have a few problems trying to run the samples from the book "Programming a Multiplayer FPS in DirectX".
      I have directx 9.0c installed and use windows 10.
      I can run the sample project 7 and the projects from chapter 2 - 5, but have problems with projects 6 and 7 - 10.
      After I compile any of those and click on the according exe files in the debug folder they close immediately after the initial dialog.
      Furthermore, I get the following error, when trying to compile the last 2 projects:
      "The value of ESP was not properly saved across a function call".
      I greatly appreciate any help!
       
       
       
       
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!