Would delegation work for you? Or is that what you mean by the Mediator pattern? I don't have all the different design patterns memorized yet. It seems like you could sub divide the responsibility of GameScene into separate objects that handled different aspects of the game, which would help things stay modular, but would also alleviate the need for listeners. Every many to many relationship can be modeled as a one to one relationship that dispatches messages to others as necessary. I just don't see the value of listeners yet.

Actually what you are doing is much closer to what one would expect to see in professional/enterprise code than what others are suggesting. The difference is that professional code would likely be broken down into even smaller components, with even more emphasis on extensibility and maintainability.

Let's hope not.

I'm not sure about C++, but in C# listeners (which are necessary for events) are wonderfully elegant and are the cleanest solution to a multitude of problems.

This is a little too vague to be helpful.

Edit
@jmasterx
The way I do it is like this :

void InheritedClass::QueueUserMessage(Widgetmsg wmsg) {
   const Widgetmsg msg1(&some_widget , TOPIC_SOME_KIND_OF_WIDGET_TOPIC , ENUM_MESSAGE_VALUE);
   if (wmsg == msg1) {
      // blah, we got a message from some_widget about something blah blah deal with it here
   }
   if (notused) {
      parent->QueueUserMessage(wmsg);
   }
}

That is Chain of Responsibility, you pass it up the parent chain until someone consumes it. That works pretty well for Gui components with children, or composed Widgets like a NumbericUpAndDown. In this case, that works much more effectively than a listener. It is also small though. In GUIs in general it is a good tool for the job. Java's Swing I read uses a Model View Controller which adds a fair amount of flexibility.

Pongception

Psst. It is no longer C++0x it is now C++11 .

Yeah I've thought the same thing, but don't have anything that would be beneficial to be put up. Sometimes I wish we had Pixelate still going from the users but I think almost all the writers have moved onto other things.

Meanwhile as we speak - ok, about an hour ago - I've put online chapter 3, more coming tomorow/today depending on your timezone.

You're really determined to crap on this thread, aren't you?

In C#, events/listeners look like this:

The point is that "listeners" are so cleanly supported by the language that it tends only to be inexperienced programmers that don't use them and instead opt for polling.

Can we use the spoiler tags for off-topic comments? wouldn't be that a great idea?

I mean, it bothers me to skip off-topic comments, it would be great if it were some way to easily see off-topic comments and then just ignore them.

By the way, I really like Death Note デスノート Desu Nōto , take a look at it: http://en.wikipedia.org/wiki/Death_Note

L Lawliet? hahaha. I'm reading the manga right now (chapter 45/108) it's amazing! I think I'm going to watch the anime after reading all the chapters!

I wish I had a Death Note, real names and pictures of some of the members in this forum off-topic comments would be dramatically reduced in my threads.

I heard the anime was sub-par compared to the manga. Haven't seen it, but the manga was fantastic. Until about the half-way point (JUST AS PLANNED). Then it dropped a bit to pretty good.

Fun fact: The same artist/writer team who did Death Note (writer Tsugumi Ohba and artist Takeshi Obata) now write and draw Bakuman, which is one of my current favorite mangas. It's kind of a meta-comic about a couple of teenagers trying to make it as a manga writer and artist.

(... how did we get off on this topic ...)

Talking about cartoons/animes here is fine, I can't control it. But if you're ever in my house, remember this rule: NO ANIME.

Textbook OOP modelling is often inconvenient, inefficient, or plain old wrong.

Consider the typical moving ball problem. Many OOP textbooks model a moving ball like this:

class Ball {
    public:
    virtual void move() { x += dx; y += dy; }
};

Very nice, the ball moves itself. Awesome. We can even implement a bunch of moving objects, each with a different implementation of the polymorphic move() method, and they will all move differently.

But then we want to do collisions, and the thing breaks. The ball moves, but in order to check if it can actually move, it needs to know a lot about its environment: the position and type of all the other objects, the walls, and maybe a lot more. We can, of course, change the move method's signature to:

virtual void move(World& world);

...but this means we have to open up a whole bunch of internals of both the world and its objects so that individual objects can read and manipulate them. The benefits of encapsulation are mostly moot this way. Another ugly spot is that if two object collide, the design mandates that one of them is the 'bouncer' and one is the 'bouncee': it's ball1->bounceWith(ball2);, even though they are really equal partners in the collision.

If we take a step back, we might observe, though, that in the real world, a ball does not in fact move itself. It is a passive object, subject to physical effects such as elasticity, inertia, in short, mechanics. The ball does not move itself: the ball has a bunch of properties, and the laws of nature act upon it.

Taking this back into the OOP domain, we end up with a design where the ball is just a data object with little functionality; it has a position and a velocity, and a few immutable properties such as mass, elasticity, etc. Movement is not handled by the ball itself, but by the Physics class: this class reads the object's parameters, and performs suitable physics calculations, something like this:

class Physics {
    void updatePositions(Object[] objects) {
        foreach (objects as object) {
             object->position += object->velocity * deltat;
             foreach (collidingObjects(object, objects) as cobject) {
                 handleCollision(object, cobject);
             }
        }
    }
};

The Physics class can act upon all the objects, without knowing too much about them (e.g., it doesn't have to know the color of a ball to calculate how it bounces, so the ball can keep that information to itself), but it can naturally operate on two objects at a time - the bouncer/bouncee problem goes away, as it is now physics->bounce(ball1, ball2);.

If you're a keen observer, you may notice something: the ball is a plain data object with little or no functionality; the physics class is pure functionality with little or no state. This means that we have separated state from behavior, exactly the opposite of what OOP tries to do (bundle state and behavior into classes). We could just as well have written this in a procedural paradigm or, in fact, if we ignore the OOP boilerplate, we actually have: class Physics is basically just a function (or a set of functions), and class Ball is just a record type (polymorphic, if you have different object types, but still just a record type).