Really "BIG" class name wanted

[Ross]

I'm now building a centralised class for a whole lot of important
functions in a program I'm writing. At present, there are too many
"little" objects that are passed around to parts of the application.
E.g. there's a "PropertyHandler" from/to which properties can be read/
written. There's a global save/load object which can save and load
various types of data items. There's an update notifier so that
updates in one part of the application are sent to other parts of the
application, either end of which might be plugins. Rather than have
too many little object, I'd like to have one "BIG" object which stores
all the little ones, and has methods such as "getPropertyHandler()",
"getSaveLoadMediator()", "getPatchMediator()" etc. This will also
simplify my interface for Plugins.

But given the importance of this central class, I want a really "BIG"
name for it. I could call it "BigMediator", or "ImportantObjects", but
want a more impressive name. Just thought that calling it
"TheCentralScrutinizer" might work, as well as being a tip of the hat
to Frank Zappa. But particularly since this object will be important
for any future plugin writers, I want a really good class name for it.

Any suggestions?

 

[Roedy Green]

Any suggestions?

Politicians call such things "omnibus bills".

Programmers tend to avoid processors with a switch for "food" and
"word".

 

[markspace]

I agree with Patricia, if you can't think of what the thing actually
does in the context of your program, it's a rather large red flag.

However, perhaps we could suggest what it might be doing. What you're
describing sounds like something I've actually used. It's an
ApplicationContext. Mostly I use this so I can decouple the real
property handler (probably what I would call Configuration) from the one
I use while testing, etc.

But in general I've found that defining an ApplicationContext with
smaller objects like Configuration, Persistence, Gui, etc. makes it easy
to decouple large modules in the code, as well as makes it convenient on
the programmer, since there's only one object to pass around and keep
track of, and it has your entire context in it.

 

[Stefan Ram]

But in general I've found that defining an ApplicationContext with
smaller objects like Configuration, Persistence, Gui, etc. makes it easy
to decouple large modules in the code, as well as makes it convenient on
the programmer, since there's only one object to pass around and keep
track of, and it has your entire context in it.

I have an object of an interface I call »environment« that I
pass around a lot in my code.

Here, a »main« method obtains a default environment:

final de.dclj.ram.system.environment.Environment environment
= new de.dclj.ram.system.environment.DefaultEnvironment()

. Code can use an environment to report errors:

environment.reportError( "Missing type in " + source + "\n" )

, or pass it to other objects:

htmlGen = new HtmlGen( environment )

. My environment has a »default output« (which is the
console, when the default environment is used). Here is
(simplified) example code, which changes the default output
during the call of a method.

outputStreamWriter = new java.iutputStreamWriter( fileOutputStream, "UTF-8" );
environment.pushOutput( outputStreamWriter );
rendoweb.write( environment );
environment.popOutput();
outputStreamWriter.close();

One can see »popOutput()« above, which restores the previous
environment.

(Recently, in this newsgroup, there has been a suggestion to
have a property getter for every property setter, so that
the client can save and restore a previous value of a
property. The above push-and-pop solution shows another way
how to achieve this, which also realizes »Tell, Don't Ask.«
with respect to that property.

Not changing a property at all, but deriving another
temporary environment object would be another means to
realize this, which would even be more threadsave.)

 

[Ross]

I'm really confident that what I am doing is a really good idea. A lot
of things that were tricky and/or non-intuitive or complicated have
suddenly simplified right down, and it's a much, much, better
structure program now than before I had this class. A fair number of
classes which before had long and complex argument lists in their
constructors now take one argument. And I find that when I find that I
DO need access to the properties from one particular class, I just get
them from this "central" object, and don't have to go around changing
constructor calls elsewhere.

Calling it an "ApplicationContext" would work. As would calling it
"ApplicationComponents", or "CommonComponents".

I just wanted a name more exciting than that. At present it's called
"CentralScrutinizer" which is not the best, and hence it's ripe for
some sed-driven renaming. But I like the idea of this class having a
distinctive name. Particularly since should anyone end up writing any
plugins for my application, they'll have to make use of it.

 

[Ross]

PS: To address Patricia's concerns (which I can understand), then the
class name "ToolsAndComponents" is bang on for what it is. Just not
impressive enough. "CircusRingmeister" might be an alternative, but
not on topic enough.

 

[Stefan Ram]

I just wanted a name more exciting than that.

You could call it »$« or use a fancy Unicode letter.

 

[markspace]

Calling it an "ApplicationContext" would work. As would calling it
"ApplicationComponents", or "CommonComponents".

I picked ApplicationContext because it seemed to be used elsewhere as
well. C.f.:

<http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch04s10.html>

You might want to compare that and a few other frameworks for ideas how
they treat an application context. The important thing I think is to
have some structure to it, not just turn it into a dumping ground for
any global variable that you happen to need.

 

[Robert Klemme]

I'm really confident that what I am doing is a really good idea. A lot
of things that were tricky and/or non-intuitive or complicated have
suddenly simplified right down, and it's a much, much, better
structure program now than before I had this class. A fair number of
classes which before had long and complex argument lists in their
constructors now take one argument. And I find that when I find that I
DO need access to the properties from one particular class, I just get
them from this "central" object, and don't have to go around changing
constructor calls elsewhere.

Downside is that now you have a dependency from all these classes to the
single class which might seriously prevent reuse. Also, it is far less
obvious what kind of information particular classes really need because
you just hand in the single large object. And this /can/ make
understanding the code harder.

Another typical example where things get so much easier is copy and
paste: you do it modify the copy in one location and be done. Headaches
come later, especially if you fix a bug in one of the two copies but
forget to do it in the other one as well. Plus, people might start
wondering why the same code occurs in several places which also makes
navigating the code harder: you won't find all the callers which use
that specific piece of code since you alway only see callers of one copy.

What I am trying to say: "things are easier" is probably not a reliable
metric. Take this with a grain of salt because I don't know your
application etc. but I would reconsider this.

Calling it an "ApplicationContext" would work. As would calling it
"ApplicationComponents", or "CommonComponents".

I just wanted a name more exciting than that. At present it's called
"CentralScrutinizer" which is not the best, and hence it's ripe for
some sed-driven renaming. But I like the idea of this class having a
distinctive name. Particularly since should anyone end up writing any
plugins for my application, they'll have to make use of it.

PS: To address Patricia's concerns (which I can understand), then the
class name "ToolsAndComponents" is bang on for what it is. Just not
impressive enough. "CircusRingmeister" might be an alternative, but
not on topic enough.

The name "ToolsAndComponents" sets off an alarm - that's just too much
and too unspecific.

Kind regards

robert

 

[Tom Anderson]

You could call it »$« or use a fancy Unicode letter.

How about ÁÙ?

tom

 

[Tom Anderson]

I'm really confident that what I am doing is a really good idea. A lot
of things that were tricky and/or non-intuitive or complicated have
suddenly simplified right down, and it's a much, much, better structure
program now than before I had this class. A fair number of classes which
before had long and complex argument lists in their constructors now
take one argument. And I find that when I find that I DO need access to
the properties from one particular class, I just get them from this
"central" object, and don't have to go around changing constructor calls
elsewhere.

The usual response to this situation is to use dependency injection. You
write objects without worrying too much about how they will get references
to each other, then use some sort of container to wire them up. If you
have a lot of singleton objects, as it sounds like you do, then you can
use a fairly simple type- or annotation-driven injection system like Guice
or CDI to inject dependencies.

I am uncertain whether this is actually better than having a God Object -
sorry, application context - sitting in the middle of the system waving
little static tentacles around, but it'll get you more brownie points.

tom

 

[Silvio]

I'm really confident that what I am doing is a really good idea. A lot
of things that were tricky and/or non-intuitive or complicated have
suddenly simplified right down, and it's a much, much, better
structure program now than before I had this class. A fair number of
classes which before had long and complex argument lists in their
constructors now take one argument. And I find that when I find that I
DO need access to the properties from one particular class, I just get
them from this "central" object, and don't have to go around changing
constructor calls elsewhere.

I went down that road a couple of times and in all cases what looked
like a good idea at the beginning has resulted in an enormous amount of
tightly coupled code and shameful regret in retrospect.

Each time I started with utility classes/interfaces like A, B and C and
depending classes AU1 (using A), ABU2 (using A and B), ACU3 (using A and
C), even an ABCU4 (using A, B and C) and a whole bunch of AUn, BUn and
CUn classes.

So far so good but to get rid of classes with multiple parameters I
created a wrapper O (short for Omega, I love descriptive names) around
A, B and C. Along with that all U classes became OU1 to OU28. Simple and
clean, at first sight.

But where my xxxUnn classes could first be subdivided looking at their
dependencies this was no longer possible. Things exploded when utility
classes D, E, F and G where added to O.

I even discovered a way to make matters even worse. I got annoyed by
using o.getA().aMethod(..) and decided to lift some A methods (along
with some B, C and G methods) to O to allow o.aMethod(..). Brilliant stuff.

Long story short: Some 8-10 years later I will never do this again and
have even gone through some horrible refactoring processes to revert my
accomplishments. It turned out I needed some of the Unn classes for
something separate and could not afford to carry all the other users
with me.

Nowadays I use Scala. This language allows me to implement interfaces A
through G in a single class O (just like Java does) BUT it also allows
me to be specific about the dependencies in my U classes:

class U19(session : A with B with E with F)
class U2(context : A with G)

and allows instantiation of Unn with an O object as long as it
implements all of the mentioned interfaces (which it obviously does)
WITHOUT messing up the dependency graph.

That was a cowardice move but I will never look back (OK, except when I
need to dive back into the Java code).

I wish you good luck!

Silvio

 

[lewbloch]

I'm really confident that what I am doing is a really good idea. A lot
Nope.

of things that were tricky and/or non-intuitive or complicated have
suddenly simplified right down, and it's a much, much, better
structure program now than before I had this class. A fair number of
classes which before had long and complex argument lists in their
constructors now take one argument. And I find that when I find that I
DO need access to the properties from one particular class, I just get
them from this "central" object, and don't have to go around changing
constructor calls elsewhere.

Avoid "God classes". Your suggestion is an infamous antipattern in
the industry. You are "confident" about a really bad idea.

http://en.wikipedia.org/wiki/God_object

Keep learning, grasshopper.

 

[lewbloch]

I just wanted a name more exciting than that. At present it's called
"CentralScrutinizer" which is not the best, and hence it's ripe for
some sed-driven renaming. But I like the idea of this class having a
distinctive name. Particularly since should anyone end up writing any
plugins for my application, they'll have to make use of it.

Excellent Frank Zappa reference.

 

[Stefan Ram]

Nowadays I use Scala. This language allows me to implement interfaces A
through G in a single class O (just like Java does) BUT it also allows
me to be specific about the dependencies in my U classes:
class U19(session : A with B with E with F)
class U2(context : A with G)
and allows instantiation of Unn with an O object as long as it
implements all of the mentioned interfaces (which it obviously does)
WITHOUT messing up the dependency graph.

class U19 { public< A extends B & E & F >U19( A a ){} }
class U2 { public< A extends G >U2( A a ){} }

 

[Martin Gregorie]

Excellent Frank Zappa reference.

CentralScrutinizer should be reserved for a mongo monitoring class. How
about GrandWazoo ?

 

[Bent C Dalager]

PS: To address Patricia's concerns (which I can understand), then the
class name "ToolsAndComponents" is bang on for what it is. Just not
impressive enough. "CircusRingmeister" might be an alternative, but
not on topic enough.

TheOneClassToRuleThemAll

ok, so maybe a bit awkward.

BinderInDarkness?

Bent.

 

[thoolen]

Cute.

ok, so maybe a bit awkward.

BinderInDarkness?

Why not just go for the truth-in-advertising straightforward approach:

public class Antipattern {
...
}

Bent.

Hey, aren't you that guy that doused this newsgroup in gasoline and set
fire to it a few years ago when someone criticized emacs?

 

[Lew]

I'm really confident that what I am doing is a really good idea. A lot

Actually it's an infamous antipattern.
<http://en.wikipedia.org/wiki/God_object>

 

[markspace]

I'm now building a centralised class for a whole lot of important
functions in a program I'm writing.

Here's an example of a similar thing:

<http://download.oracle.com/javase/6/docs/api/javax/annotation/processing/ProcessingEnvironment.html>

That's the Processing Environment for the Java compiler annotation
processor. Notice it's got some things similar to your idea --
getOptions, getTypeUtils, some other stuff like getFiler (the file
system, i.e., persistence) and some stuff specific to the problem domain
(ElementUtils, Messager, etc.)

Notice too it's not a "god object" -- it's only got a few objects
contained with in it. It doesn't know everything, just the top level
interfaces. That's much closer to what I think of as an
ApplicationContext -- half a dozen to a dozen getters max, and only
deals with well scoped top level concepts.