Re: Adding functions to a class... without extending it

Discussion in 'Java' started by Steve Claflin, Aug 16, 2003.

  1. Loic Minier wrote:
    > * DemmeGod <>,
    > 15 Aug 2003 22:24:52 -0700:
    > > Ok, so I've got this class... It's called "node". Several of the
    > > methods in the node class return either node or node arrays (node[]).
    > > Node is an extremely general class, and it can be used alot of ways,
    > > so I want the ability to add functionality (methods), that are program
    > > specific, to it without modifying it. Normally, the (obvious) way to
    > > do this would be to extend it. My problem is that I'd want the
    > > inherited methods from node not to return node or node array, but to
    > > return the subclass, which we'll call superNode, for lack of a better
    > > name.

    > You can't, you have to cast. But keep in mind that the returned
    > reference to node objects are in fact references to your supernode
    > object, only the 'metainformation' of the class is returned wrong, so
    > you have to check with instanceof and cast.
    > I would use an interface to define which objects can be stored in your
    > noded structure, and make the objects I want to store implement that
    > interface.
    > > My first thought was that I could simply create wrapper functions...

    > Yes, good idea, just create a wrapper that calls all the functions and
    > casts. But it's a painful work, as long as you know what kind of
    > objects you are expecting, I don't see the problem of casting after
    > each call. So it would be a one shot work, won't be reusable.
    > Consider the Vector class, when you store an object into it, you get
    > a reference to a java.lang.Object at retrieval time. You have to cast
    > it explicitely (and you can check the specific type with instanceof if
    > you want to be sure and avoir ClassCastException).
    > > My current line of thinking is (vaguely) that node can have some sort
    > > of array of method object instances, which it can call. The problem
    > > with this is that one would have to run some ugly function like
    > > node.runMethod(String name, Object[] args). I'm assuming there's no
    > > way of running some sort of "catch-all" method in java that would run
    > > if a method name is not found... Of course if that existed then
    > > there'd have to be some way of telling the compiler that functions in
    > > that class actually DO exist whenever something needs to call a new
    > > function.

    > You want automatic code generation. For example you could design
    > Templates to generate code for a set of functions returning the type
    > you choose, ie superNode.
    > This is not in the optic of all you see in the JDK functions right now,
    > for example HashMap doesn't rely on a specific type being used.

    > > This one's kinda got me stumped.... Anybody got any bright ideas?

    > Hey it's your code, it depends what you want to make out of it. I'd say
    > Java-style suggests you should use a generic type and cast it from your
    > application. I recently had to deal with a very similar problem, but
    > I had to access classes-specific functions without knowing exactly
    > which class would be returned. So in each of my functions, I had 1 to
    > 5 instanceof checks depending on the types I could expect to see in
    > the context, and then I casted each time and used the class-specific
    > functions.
    > Good luck,
    > --
    > Loïc Minier <>

    From its name, it seems like node is a general class, the purpose of
    which is to store an item, not be the item. And, as Loïc said, the
    usual approach is to not predefine the type of object stored. Perhaps
    you should think of a structure similar to Model-View-Controller,
    although in this case it would be Model-StorageMechanism-Controller.
    Your class could have a reference to the object it stores, and a
    getStoredObject method that returns that reference. Then you could do
    with it what you wish. The difference here is that in MVC the model
    implements an interface where you know what the available methods are
    (and they are the same for each subtype). In your case you'd still need
    the check and cast mechanism.

    The benefit of that is if you subclass node to use a different storage
    mechanism, the stored object reference capability automatically comes
    along with it. I often wish that Sun had added something like a
    component model to JComponent, so that all the API subclasses like
    JLabel, JTextField, etc., would get the model reference. As it is, I
    often find myself adding virtually the same code to extensions of each
    of those classes (like an event handler for moving to a new record that
    calls setText on the component based on a field from the record -- kind
    of like the VB "D" versions of the GUI components).

    Steve Claflin, Aug 16, 2003
    1. Advertisements

  2. Steve Claflin

    DemmeGod Guest

    Actually, in this case, node is the object. Is has the data, and
    various methods to interface with the data. It also has a few methods
    which are how it interacts with and accesses other nodes. The
    functions I wish to add (usually) are of this type. Extending node to
    create other types of data, while it can be done, is not encouraged.
    This is a case where a typical hierarchy is perfect. EVERYTHING is a
    node first... Various nodes, however, can be used in different ways...
    This is dictated by their placement in the database.

    At one point I considered making node an interface, and doing
    something similar to what you are discussing but ultimately dismissed
    the idea because the hierarchy model works so well with it; with this
    one exception, of course.

    DemmeGod, Aug 17, 2003
    1. Advertisements

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. Roedy Green
    Aug 18, 2003
  2. Hugh Beyer
    Dale King
    Apr 15, 2006
  3. E11
    Thomas Weidenfeller
    Oct 12, 2005
  4. Xiangliang Meng
    Victor Bazarov
    Jun 21, 2004
  5. Simon Elliott
    Simon Elliott
    Jan 11, 2005
  6. Hicham Mouline
    Hicham Mouline
    Nov 11, 2008
  7. marekw2143
    Jul 25, 2009
  8. Nit Khair
    Nit Khair
    Oct 3, 2008