On Apr 10, 3:35 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:

I prefer dependency injection for something like this.
You create an instance of your data initializer class.  This instance
is passed to all the places that need to know about it.

The Dependency Injection pattern is the response to the Singleton anti-
pattern. Don't get me wrong, sometimes a Singleton is exactly what you
want, but usually its not, and its often overused.

I would suggest singleton.

Arne

On Apr 10, 6:35 pm, Knute Johnson <nos...@rabbitbrush.frazmtn.com>
wrote:

why not use a global object?

I'm not sure I understand the question completely.

You're saying you read some data from a file and stuff it in a static
variable?

class Editor {
    static String myData;

    public Editor( IOStreamReader file ) {
        // read data into myData from file...
    }
}

Yes, this is pretty evil.  If you need direct access to the data, you
should at least go through a getter and a setter. JTextArea has, iirc, a
getText and a setText.  So if a second class needs to modify myData, it
uses the getter, makes changes, then invokes the setter.  However in any
case I'd ditch the static modifier.  It's not needed and will probably
produce some really unexpected behavior eventually.

If you're asking something different, I'm not sure what it is.  More info?

There's some room for debate on how/whether to use the Singleton pattern, but
this sounds like a reasonable occasion to me -- although it really depends on
factors I don't know about (such as whether this is library code or application
code, and what sort of execution environment it'll run it -- all "global"
concerns, which is reasonable given that your design issue is itself global).

One specific thing that you've mentioned makes me suspicious of the current
design -- if there are several items of closely related data, then you'd
normally expect them to co-exist in some object with some well-defined role(s).
It's not clear that your collection of static variables constitutes a clear
abstraction.

In general, pulling a bunch of related stuff out into its own object can be
expected to suggest further factorings and re-assignments of responsibility
which will simplify the code which uses it.

(For instance, if this data were represented as an object, then your editor
would be a GUI for editing objects of that type, rather than having the
"owning" class of the variables hardwired into it.  That would simplify
testing, and all sorts of things.  For instance allowing the user to make and
review changes, without immediately installing those changes into the global
state, would be trivial instead of messy.)

The previous three paragraphs apply whatever design you end up with, Singleton,
Dependency Injection (stupid name), or anything else.

   -- chris

P.S.  If you do decide to use Singleton, don't mess around trying to prevent
people creating other objects of the same class -- that is at best a waste of
time, and may lead to cripplingly inflexibility.

Is this configuration data that doesn't change very much, for example a
boolean to decide between using Algorithm A rather than Algorithm B? Or
is it passive data, like a bank balance?

.ed

Knute Johnson wrote On 04/10/07 18:35,:

   If you've got a constructor, you're presumably building
object instances (perhaps just one, but it's an instance).
It seems natural for the data to live in the instance(s).

   Or to turn it around: If all the data is static, why
use a constructor?  What good does the object instance do?

Thanks everybody for their responses.  Let me describe one case in a
little more detail and maybe you can give me a better idea about which
way to go.

I have an application. In the main class I create a GUI, the GUI class
loads some initialization data from a file, creates instances of several
other classes that use some of that data and has an editor that modifies
some of that shared data.  Originally I put all of the data in a class
of statics along with all of the constant data that was used by any of
the classes.  Then I thought maybe it made more sense to put the data in
the class that loaded it or was the primary user.  That just made a
mess.  The singleton is pretty much like my original idea only it will
be easier to synchronize the data.  The data injection idea is good too
and I had thought of that but it only really works one way.  Which is
probably OK but then the data would all end up back in my main class.

Another piece of this that is similar, I have an array of locks that I
use to synchronize access to some data files.  I don't know how many
locks I need until I load the initialization file in the main class.
These locks are used by two other classes that read and write these
files.  I created the lock references as static and share them that way.

So I don't know if that makes it any more clear about where I want to
go.  I would appreciate any ideas or comments.  I would like to know
what it is about the singleton that anyone thinks is superior to a class
of statics.

Thanks,