views:

170

answers:

3

I am working on a project where I have lots of classes referring to my GUI (mainly the panels but sometimes the frame itself). So I was thinking that instead of passing the frame as an argument to every constructor and create getters in each class, I would make a singleton instance of the JFrame so all the classes get access to it instead. Is this a good approach or will it just punish my laziness in some way?

Edit: I'm not just lazy, I'm trying to think in models here: For example, let's say I have various Car objects and the Road is my GUI. All Cars should have access to the same Road, and the Road is not a part of a car.

A: 

A better approach would be to hide the main JFrame behind static methods, but in general it is a good idea if you have only one JFrame object for the whole program to make it static anyway.

Hiding it behind static methods ensures that if you work on this with anyone else you can constrain what you want them to be able to access on the main JFrame, but would be useless for something like a school project etc.

It's not for a school project, it's simply some games and experimenting I'm doing for myself.
pg-robban
Then I don't think there is anything wrong with having a static JFrame object. Would prevent you from having to pass pointers around.
+1  A: 

There is plenty of opinions in the area, see referenced material below.

My feeling is that we should try to avoid Singletons because "there's no such number as 1".

[This follows on from my theory that "there is no such number as 2". If you have code, that allows for two of something, and only two of something, then you've missed a trick - there's almost certain to be more than two, instead solve how to deal with "many".]

The "no such number as 1 argument" is that just when you thought there could only be one of something there will be some context in which it's possible to have more ... and it's usually very little extra work to allow for more.

Look at your example ... I have various Car objects, they all have access to the same Road? Does that sound like a model of a realistic world? UK Roads and French Roads, any difference? ;-) Why build that "Only One" assumption into your code?

Use of factories and dependency injection of those factories will often be the better answer. Lots more material in answers to this question.

djna
Hehe, sorry for the lousy example :) It's not that I just want to limit the instance, the problem is that I want an easy reference for all the classes to work with and make my code look decent.I would like to upvote but I'm still short of points, so I'd like to say thanks to all of you who have replied so far.
pg-robban
Not just your example, it's amazing how oftern something starts out looking like a singleton and then ends up not being one. The easy references can come from injected factories. See the references.
djna
+1  A: 

The Singleton pattern is considered today to be an "anti-pattern". The problem will become apparent when your Cars will need to be used with a different Road one day.

It will become even more apparent if you decide to unit-test the Cars for themselves. If you can't provide a Mock for the Road, how will you test them? And you won't be able to, since they refer to their Road through a Singleton.

(Obviously there's a workaround by having the Singleton return a MockRoad when in "test-mode", but that just means you're adding testing code into your production code.)

Aviad Ben Dov