design pattern question

Discussion in 'Java' started by Josef Garvi, Apr 16, 2004.

  1. Josef Garvi

    Josef Garvi Guest

    I have a file that may contain different types of data.
    Depending on the contents of the file, I would like to create different
    types of objects. Is there a way that I can let my file parsing class know
    what processing classes are available, so that it can create an instance of
    the appropriate class?

    I would prefer not having to couple my file parser class to the processing
    classes, so that I could add new processing classes for other data types
    without having to modify the code of the file parser in any way. How can I
    solve this? Is there for example a way of finding all classes in a package,
    so I can load them and have them register themselves with the file parser
    in their static initialisers?
    Or am I forced to hard-code the names of all processing classes in my file
    parser class?

    --
    Josef Garvi

    "Reversing desertification through drought tolerant trees"
    http://www.eden-foundation.org/

    new income - better environment - more food - less poverty
     
    Josef Garvi, Apr 16, 2004
    #1
    1. Advertising

  2. Josef Garvi wrote:
    > I have a file that may contain different types of data.
    > Depending on the contents of the file, I would like to create different
    > types of objects. Is there a way that I can let my file parsing class
    > know what processing classes are available, so that it can create an
    > instance of the appropriate class?


    Your description is vague, so here are some vague suggestions:

    Consider using some kind of factory/kit class or method. Consider using
    reflection to create instances from parsed type names (strings).

    Alternatively, or in addition, consider using a prototype repository,
    where all handlers register a prototype of a handler object (or just a
    corresponding class object). The repository might use a hashmap to map
    parsed type names (strings) to object prototypes (or class objects).
    When a particular object is needed, clone the prototype object (or use
    the class object to create an instance).

    > Is there for example a way of finding all
    > classes in a package,


    This is an FAQ and has been answered here a thousand time. And the
    answer is:

    No, not in a general way.

    If you add restrictions (e.g. all handler .class files must reside in
    one particular directory), you can find them with the normal File methods.

    > Or am I forced to hard-code the names of all processing classes in my
    > file parser class?


    No. You could e.g. use a configuration file, e.g. a properties file,
    listing all handler classes and their location.

    /Thomas
     
    Thomas Weidenfeller, Apr 16, 2004
    #2
    1. Advertising

  3. Josef Garvi

    Josef Garvi Guest

    Thomas Weidenfeller wrote:
    > Alternatively, or in addition, consider using a prototype repository,
    > where all handlers register a prototype of a handler object (or just a
    > corresponding class object). The repository might use a hashmap to map
    > parsed type names (strings) to object prototypes (or class objects).
    > When a particular object is needed, clone the prototype object (or use
    > the class object to create an instance).


    That's my line of thinking. A HashMap would work well for creating objects
    based on data type. The question is just how I register my classes in the
    HashMap. The nicest thing would be if they could plug themselves into the
    HashMap by themselves. I.e. if I add a new class with appropriate methods,
    it would register itself into the map. I have tried putting that code into
    a static initialiser, but the static initialiser only gets called when some
    code in the program refers to the class, making the class-loader load it.
    Assuming I have not referenced the classes when I read the file, I will
    have an empty HashMap...
    (this would have been different in language like Delphi, where all linked
    units are initialised when the program loads rather than "on-demand")

    Your two suggestions about checking for all .class files in a particular
    directory, and creating a configuration file holding the names of all
    classes are both possible solutions.


    --
    Josef Garvi

    "Reversing desertification through drought tolerant trees"
    http://www.eden-foundation.org/

    new income - better environment - more food - less poverty
     
    Josef Garvi, Apr 16, 2004
    #3
  4. Josef Garvi

    Roedy Green Guest

    On Fri, 16 Apr 2004 11:20:03 +0200, Josef Garvi
    <> wrote or quoted :

    > Is there a way that I can let my file parsing class know
    >what processing classes are available, so that it can create an instance of
    >the appropriate class?


    I think you are hinting that you want class.forName. See
    http://mindprod.com/jgloss/classforname.html

    You write various parser classes that implement an Interface. You can
    dynamically load new parsers simply by providing a text file at run
    time with the names of the parsing classes. To see how the technique
    works see http://mindprod.com/holidays.html

    Each different holiday calculator is a class that implements the
    HolInfo interface. There is a properties file that lists which
    HolInfo-implementing classes you want to work with. You can then add
    new classes without recompilation.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Apr 17, 2004
    #4
  5. Josef Garvi

    Roedy Green Guest

    On Fri, 16 Apr 2004 13:49:07 +0200, Josef Garvi
    <> wrote or quoted :

    >I have tried putting that code into
    >a static initialiser, but the static initialiser only gets called when some
    >code in the program refers to the class, making the class-loader load it.
    >Assuming I have not referenced the classes when I read the file, I will
    >have an empty HashMap...


    There is no problem having a class register itself.

    Typically you have a text file with a list of classes to register.

    Alternatively you could write a sniffer that looked at every class on
    the classpath and decided if it fit the pattern of an autoloading
    class. Then all you need do add new parsers is name them
    appropriately and put them on the classpath. You might put them all in
    a jar to make them easier to find.

    If the class matches the pattern (e.g. implements your interface), you
    load it, and it registers itself with a static initialiser. See
    http://mindprod.com/jgloss/jasm.html
    for how you could tell what interfaces a class implemented before you
    loaded it.

    With the text file approach, you don't necessarily load the class
    until you need it.


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Apr 17, 2004
    #5
  6. Josef Garvi

    Josef Garvi Guest

    Roedy Green wrote:

    > On Fri, 16 Apr 2004 13:49:07 +0200, Josef Garvi
    > <> wrote or quoted :
    >
    >
    >>I have tried putting that code into
    >>a static initialiser, but the static initialiser only gets called when some
    >>code in the program refers to the class, making the class-loader load it.
    >>Assuming I have not referenced the classes when I read the file, I will
    >>have an empty HashMap...

    >
    >
    > There is no problem having a class register itself.
    >
    > Typically you have a text file with a list of classes to register.


    Yes, that's possible. The drawback here is that it doesn't work well with
    refactoring.


    > Alternatively you could write a sniffer that looked at every class on
    > the classpath and decided if it fit the pattern of an autoloading
    > class. Then all you need do add new parsers is name them
    > appropriately and put them on the classpath. You might put them all in
    > a jar to make them easier to find.


    That's an interesting approach. Do you have any "getting-started" advice on
    how to write a sniffer? (i.e. which classes should I use). Or is it all
    done with Jasm?


    --
    Josef Garvi

    "Reversing desertification through drought tolerant trees"
    http://www.eden-foundation.org/

    new income - better environment - more food - less poverty
     
    Josef Garvi, Apr 20, 2004
    #6
  7. Josef Garvi

    Roedy Green Guest

    On Tue, 20 Apr 2004 08:31:23 +0200, Josef Garvi
    <> wrote or quoted :

    >That's an interesting approach. Do you have any "getting-started" advice on
    >how to write a sniffer? (i.e. which classes should I use). Or is it all
    >done with Jasm?


    Bone up on ClassLoaders.

    You have the System Properties which tell you the path and classpath.
    You can parse that yourself.

    If you know the name of the jar file, you can use the Zip classes to
    go looking around inside it for a list of class names. In a primitive
    scheme, the class names you are looking for just fit some
    regex/wildcard pattern.

    In a sexier scheme all the autoloading classes have to do is implement
    some Interface. To discover which interfaces a class implements
    without loading it, you must read the class as a string of bytes and
    analyse it. Tools for doing that are discussed at
    "http://mindprod.com/jgloss/jasm.html"
    Tho tools themselves are typically written in ordinary Java. To them
    the class files are just a complicated string of bytes.

    If you LIKE the class file, then you load it with class.forName.

    See http://mindprod.com/jgloss/classforname.html


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Apr 20, 2004
    #7
  8. Josef Garvi

    Josef Garvi Guest

    Roedy Green wrote:

    > Bone up on ClassLoaders.
    > [...]


    Thanks!


    --
    Josef Garvi

    "Reversing desertification through drought tolerant trees"
    http://www.eden-foundation.org/

    new income - better environment - more food - less poverty
     
    Josef Garvi, Apr 20, 2004
    #8
    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. sunny
    Replies:
    1
    Views:
    478
    Salt_Peter
    Dec 7, 2006
  2. Bartholomew Simpson

    class design/ design pattern question

    Bartholomew Simpson, Jun 12, 2007, in forum: C++
    Replies:
    2
    Views:
    462
    Daniel T.
    Jun 12, 2007
  3. Pallav singh
    Replies:
    0
    Views:
    410
    Pallav singh
    Jan 22, 2012
  4. Pallav singh
    Replies:
    0
    Views:
    433
    Pallav singh
    Jan 22, 2012
  5. Pallav singh
    Replies:
    1
    Views:
    471
    Peter Remmers
    Jan 22, 2012
Loading...

Share This Page