Really "BIG" class name wanted

Discussion in 'Java' started by Ross, Jul 28, 2011.

  1. Ross

    Ross Guest

    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?
     
    Ross, Jul 28, 2011
    #1
    1. Advertising

  2. Ross

    Roedy Green Guest

    On Thu, 28 Jul 2011 03:20:22 -0700 (PDT), Ross <>
    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.
     
    Roedy Green, Jul 28, 2011
    #2
    1. Advertising

  3. Ross

    markspace Guest

    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.
     
    markspace, Jul 28, 2011
    #3
  4. Ross

    Stefan Ram Guest

    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.)
     
    Stefan Ram, Jul 28, 2011
    #4
  5. Ross

    Ross Guest

    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, Jul 29, 2011
    #5
  6. Ross

    Ross Guest

    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.
     
    Ross, Jul 29, 2011
    #6
  7. Ross

    Stefan Ram Guest

    Ross <> writes:
    >I just wanted a name more exciting than that.


    You could call it »$« or use a fancy Unicode letter.
     
    Stefan Ram, Jul 29, 2011
    #7
  8. Ross

    markspace Guest

    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.
     
    markspace, Jul 29, 2011
    #8
  9. 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/
     
    Robert Klemme, Jul 29, 2011
    #9
  10. Ross

    Tom Anderson Guest

    On Fri, 29 Jul 2011, Stefan Ram wrote:

    > Ross <> 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
     
    Tom Anderson, Jul 29, 2011
    #10
  11. Ross

    Tom Anderson Guest

    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
     
    Tom Anderson, Jul 29, 2011
    #11
  12. Ross

    Silvio Guest

    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
     
    Silvio, Jul 29, 2011
    #12
  13. Ross

    lewbloch Guest

    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
     
    lewbloch, Jul 29, 2011
    #13
  14. Ross

    lewbloch Guest

    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
     
    lewbloch, Jul 30, 2011
    #14
  15. Ross

    Stefan Ram Guest

    Silvio <> 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 ){} }
     
    Stefan Ram, Jul 30, 2011
    #15
  16. 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 |
     
    Martin Gregorie, Jul 30, 2011
    #16
  17. On 2011-07-29, Ross <> wrote:
    > 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.
    --
    Bent Dalager - - http://www.pvv.org/~bcd
    powered by emacs
     
    Bent C Dalager, Jul 30, 2011
    #17
  18. Ross

    thoolen Guest

    On 30/07/2011 6:42 PM, Bent C Dalager wrote:
    > On 2011-07-29, Ross<> wrote:
    >> 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


    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?
     
    thoolen, Jul 31, 2011
    #18
  19. Ross

    Lew Guest

    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
     
    Lew, Jul 31, 2011
    #19
  20. Ross

    markspace Guest

    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.


    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.
     
    markspace, Aug 1, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harvey
    Replies:
    0
    Views:
    793
    Harvey
    Jul 16, 2004
  2. Harvey
    Replies:
    1
    Views:
    901
    Daniel
    Jul 16, 2004
  3. Shaguf
    Replies:
    0
    Views:
    562
    Shaguf
    Dec 24, 2008
  4. Shaguf
    Replies:
    0
    Views:
    511
    Shaguf
    Dec 26, 2008
  5. Shaguf
    Replies:
    0
    Views:
    279
    Shaguf
    Dec 26, 2008
Loading...

Share This Page