Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6629 > unrolled thread

Really "BIG" class name wanted

Back to article view | Back to comp.lang.java.programmer

Contents

  Really "BIG" class name wanted Ross <rossclement@gmail.com> - 2011-07-28 03:20 -0700
    Re: Really "BIG" class name wanted Patricia Shanahan <pats@acm.org> - 2011-07-28 03:38 -0700
    Re: Really "BIG" class name wanted Roedy Green <see_website@mindprod.com.invalid> - 2011-07-28 04:01 -0700
    Re: Really "BIG" class name wanted markspace <-@.> - 2011-07-28 06:35 -0700
      Re: Really "BIG" class name wanted Ross <rossclement@gmail.com> - 2011-07-29 05:28 -0700
        Re: Really "BIG" class name wanted markspace <-@.> - 2011-07-29 06:36 -0700
        Re: Really "BIG" class name wanted Robert Klemme <shortcutter@googlemail.com> - 2011-07-29 15:55 +0200
        Re: Really "BIG" class name wanted Tom Anderson <twic@urchin.earth.li> - 2011-07-29 14:56 +0100
        Re: Really "BIG" class name wanted Tom Anderson <twic@urchin.earth.li> - 2011-07-29 15:08 +0100
        Re: Really "BIG" class name wanted Silvio <silvio@moc.com> - 2011-07-29 17:32 +0200
          Re: Really "BIG" class name wanted Silvio <silvio@moc.com> - 2011-08-01 13:47 +0200
        Re: Really "BIG" class name wanted lewbloch <lewbloch@gmail.com> - 2011-07-29 09:25 -0700
        Re: Really "BIG" class name wanted lewbloch <lewbloch@gmail.com> - 2011-07-29 23:08 -0700
          Re: Really "BIG" class name wanted Martin Gregorie <martin@address-in-sig.invalid> - 2011-07-30 11:24 +0000
            Re: Really "BIG" class name wanted Patricia Shanahan <pats@acm.org> - 2011-07-30 06:10 -0700
              Re: Really "BIG" class name wanted Gene Wirchenko <genew@ocis.net> - 2011-08-01 16:22 -0700
        Re: Really "BIG" class name wanted Lew <lewbloch@gmail.com> - 2011-07-31 02:29 -0700
        Re: Really "BIG" class name wanted Lew <lewbloch@gmail.com> - 2011-08-01 14:22 -0700
          Re: "$" in class names reserved [was: Re: Really "BIG" class name wanted] Wayne <nospam@all.invalid> - 2011-08-02 02:33 -0400
      Re: Really "BIG" class name wanted Ross <rossclement@gmail.com> - 2011-07-29 05:37 -0700
        Re: Really "BIG" class name wanted Bent C Dalager <bcd@pvv.ntnu.no> - 2011-07-30 22:42 +0000
          Re: Really "BIG" class name wanted thoolen <thoolen@tholenbot.thorium> - 2011-07-30 23:38 -0400
    Re: Really "BIG" class name wanted markspace <-@.> - 2011-07-31 20:32 -0700
    Re: Really "BIG" class name wanted Silvio <silvio@moc.com> - 2011-08-01 13:54 +0200

Page 1 of 2  [1] 2  Next page →

#6629 — Really "BIG" class name wanted

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?

[toc] | [next] | [standalone]

#6630

On 7/28/2011 3:20 AM, Ross wrote:
> 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?

One of the tests I use for my program design ideas is whether the thing
I'm thinking up has an obviously suitable name. Trouble thinking of a
name for a class or method is a warning sign that it may not be a really
good idea.

Patricia

[toc] | [prev] | [next] | [standalone]

#6631

On Thu, 28 Jul 2011 03:20:22 -0700 (PDT), Ross <rossclement@gmail.com>
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. 

[toc] | [prev] | [next] | [standalone]

#6634

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.

[toc] | [prev] | [next] | [standalone]

#6644

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.

[toc] | [prev] | [next] | [standalone]

#6647

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.

[toc] | [prev] | [next] | [standalone]

#6649

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/

[toc] | [prev] | [next] | [standalone]

#6650

[Multipart message — attachments visible in raw view] — view raw

On Fri, 29 Jul 2011, Stefan Ram wrote:

> Ross <rossclement@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#6651

On Fri, 29 Jul 2011, 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.

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

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

[toc] | [prev] | [next] | [standalone]

#6652

On 07/29/2011 02:28 PM, 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.
>

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

[toc] | [prev] | [next] | [standalone]

#6710

On 07/30/2011 01:19 PM, Stefan Ram wrote:
> Silvio<silvio@moc.com>  writes:
>> 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 ){} }
>

Good one, although my anecdotes took place quite some time before 
generics. I admit that makes the reference to current Scala a but 
misleading.

Any way, lifting methods to the omega object made even this impossible.

In short I was just trying to support the claim that super objects are bad.

Gr. Silvio

[toc] | [prev] | [next] | [standalone]

#6655

Ross wrote:
> 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.

--
Lew

[toc] | [prev] | [next] | [standalone]

#6671

Ross wrote:
> 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.

--
Lew

[toc] | [prev] | [next] | [standalone]

#6673

On Fri, 29 Jul 2011 23:08:15 -0700, lewbloch wrote:

> Ross wrote:
>> 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.

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


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#6674

On 7/30/2011 4:24 AM, Martin Gregorie wrote:
> On Fri, 29 Jul 2011 23:08:15 -0700, lewbloch wrote:
>
>> Ross wrote:
>>> 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.

Why "sed-driven renaming" rather than loading it into e.g. Eclipse and
using Refactor-Rename?

>>
>> Excellent Frank Zappa reference.
>
> CentralScrutinizer should be reserved for a mongo monitoring class. How
> about GrandWazoo ?
>
>

PileOfCoincidentallyCoupledStuff

Patricia

[toc] | [prev] | [next] | [standalone]

#6720

On Sat, 30 Jul 2011 06:10:57 -0700, Patricia Shanahan <pats@acm.org>
wrote:

>On 7/30/2011 4:24 AM, Martin Gregorie wrote:

[snip]

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

>PileOfCoincidentallyCoupledStuff

     "BigBallOfMud" is shorter.

     I suupose, though, that makes your suggestion better, because it
is more descriptive of the situation.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#6702

Ross wrote:
> 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>

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#6714

"$" is generally (but not AFAIK mandatorily) reserved for internal class names such as those generated for nested / inner classes.

[toc] | [prev] | [next] | [standalone]

#6732 — Re: "$" in class names reserved [was: Re: Really "BIG" class name wanted]

On 8/1/2011 5:22 PM, Lew wrote:
> "$" is generally (but not AFAIK mandatorily) reserved for internal class names
> such as those generated for nested / inner classes.

It should be reserved but you're right, it isn't.  Consider this:

<file A.java>
class A {
  class B {}
}
</file>

<file A$B.java>
class A$B {}
</file>

If you compile the two separately, whichever compiles
last overwrites the previous A$B.class.  If you try to
compile them both at once, you get this:

C:\Temp>javac A.java A$B.java
A$B.java:1: duplicate class: A.B
class A$B {}
^
1 error

-- 
Wayne

[toc] | [prev] | [next] | [standalone]

#6646

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web