Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Really "BIG" class name wanted

Reply
Thread Tools

Really "BIG" class name wanted

 
 
Ross
Guest
Posts: n/a
 
      07-28-2011
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?
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      07-28-2011
On Thu, 28 Jul 2011 03:20:22 -0700 (PDT), Ross <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>
>Any suggestions?


Politicians call such things "omnibus bills".

Programmers tend to avoid processors with a switch for "food" and
"word".
--
Roedy Green Canadian Mind Products
http://mindprod.com
Most of computer code is for telling the computer
what do if some very particular thing goes wrong.
 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      07-28-2011
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.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      07-28-2011
markspace <-@.> writes:
>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.io.OutputStreamWriter( 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.)

 
Reply With Quote
 
Ross
Guest
Posts: n/a
 
      07-29-2011
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.
 
Reply With Quote
 
Ross
Guest
Posts: n/a
 
      07-29-2011
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.
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      07-29-2011
Ross <(E-Mail Removed)> writes:
>I just wanted a name more exciting than that.


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

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      07-29-2011
On 7/29/2011 5:28 AM, Ross wrote:
> 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.

 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      07-29-2011
On 29.07.2011 14:28, Ross wrote:
> 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

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      07-29-2011
On Fri, 29 Jul 2011, Stefan Ram wrote:

> Ross <(E-Mail Removed)> writes:
>> I just wanted a name more exciting than that.

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


How about ÁÙ?

tom

--
Watched Blade Runner again last night. Still think the new edition should
end with Harrison Ford staring blankly at a captcha. -- Quintin Smith
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Nested Class, Member Class, Inner Class, Local Class, Anonymous Class E11 Java 1 10-12-2005 03:34 PM
OT : But help really really needed re: Domain Name selling, hosting etc. problem nc HTML 1 02-03-2005 07:24 PM
HELP WANTED HELP WANTED HELP WANTED Harvey ASP .Net 1 07-16-2004 01:12 PM
HELP WANTED HELP WANTED HELP WANTED Harvey ASP .Net 0 07-16-2004 10:00 AM
REALLY REALLY WERID PROBLEM!!!!pls take a look Amir ASP .Net 3 01-23-2004 06:01 PM



Advertisments