In OO programming, what's the preferred way of handling multiple instances (objects) of a single class? Say you want to write a program where a random number of circles get drawn on screen, where every circle is an instance of a Circle class, and when you click a button, every circle changes color.

How would you do that?

I see two ways, either to use a static variable (array) in the class holding all instances, along with a static function which loops through that array and calls a recolor method on each instance. Or to use the same variable and method, but instead put it in a separate class, maybe called CircleManager.

  • Im also intrested to know where one may find more info about this topic? Commented Jan 7, 2012 at 13:27

4 Answers 4


Basically the direction of your thoughts is correct. I would generalize the array to a collection, of which the array is just one. There are many different types: lists, maps, sets etc. to choose from according to your needs.

The collection can be maintained inside another class object if you wish so. This is a design question, which is hard to answer without more details, including the programming language you are using. In some languages, everything is inside some class, so you have no choice in this respect. In others (like C++) you do.

Typically in modern GUI frameworks, clicking a button generates an event, which is then handled by some entity registered to get notifications about that type of event. You may choose to register a single controller object (CircleManager if you want), which then iterates through each circle and changes their color. Or you may register each individual Circle as a listener to the button click, so then each gets notified in turn and changes its color independently.

  • Ok, thanks. Im intrested in keeping it object oriented, so its more an example to open up for a discution, to discust whats the best-practise in à simular situation. Commented Jan 7, 2012 at 14:19
  • 2
    @LarsC.Magnusson, the problem is, what you describe is too general and vague yet. Either of the options I mentioned can be a "best practice" in a specific situation. But there is no one-size-fits-all solution in software development. Commented Jan 7, 2012 at 15:45

I would suggest you look into publish and subscribe event systems, such as the Qt signals and slots system.

Using this system each graphic object would publish a click event signal, and any other object interested could subscribe to that event, and thus react to the signal.

Your graphic could also subscribe to a 'set color' event, and react accordingly when that event was published by another object.

  • Could be interesting. Thanx Commented Jan 7, 2012 at 18:37
  • Nice - thinking in a different direction
    – Murph
    Commented Jan 7, 2012 at 19:39

Since this rather a broad question, I would try to answer it in a general context and then with the circle example you have mentioned

General Explanation

If you are creating multiple instances of your class and you want the instances to communicate with each other, looping them as a collection would be ideal as pointed out by Peter Torok. Read your language documentation to implement this as this may vary across languages. This is OK in case all the instances would be called by a single program or would be executed in totality. I don't recommend storing the data inside the classes as static variable as this would make the class somewhat rigid to modify in future.

But in case you want to create multiple instances of your class and multiple collections of your class instances, then it would turn tricky as you need to exchange information among classes and if the classes are stateful, then it would take some real good work

Circles Example

In this case, you can wrap your class with an another class that would draw a specified number of circles and a click action (assuming general GUI components) that would redraw the circles.

class CircleWrapper(number):
   constructor creates the required number of circles by calling the circle class with draw method
   click event that calls the recolor method on each of the circles

class circle ():

CircleWrapper(10)creates 10 circles. Clicking the GUI invokes the recolor method. Wrapper methods aren't given in detail in the above example. Though this involves an extra call, it is easier to extend the model and to add run-time changes and validations.


Hearing your description makes me want to have 3 classes.

a class for a circle a class for the circle container (say, Circles) ;) a class for your application logic

The Circles class hold and retrieve different circles to be interacted with. An instance of it could be part of the application class.

This is informed by the Single Responsibility Principle: Circle is responsible for holding state about a single Circle, not multiple Circles. Circles is simply responsible for holding the collection of circles. The application then can have logic which ties the UI to the Circle data or whatever the heck you need to do.

As you add stuff to this (say, what if you want someone to interact with the circles using their mouse?) then you will obviously need to grow out a more complex object model.

I'd strongly recommend investigating the SOLID OOP principles, as well as looking into things like "Tell, don't ask" etc.

  • That was the kind of the answer I was looking for:) Commented Jan 8, 2012 at 11:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.