|
This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Artima Forums.
Message:
Just old-fashioned I guess
Posted by Bill Venners on 17 Feb 1999, 6:16 AM
> Hi, Bill: > Perhaps you didn't quite intend this but I can think of several
> examples where use of run-time information can add considerably to an application's flexibility. Indeed, I think the present
> JavaBean design and tools that are coming out reflect the limitation of the view (and one that you seem to express) that
> such use of run-time information should be limited to builder tools. > I think it's a way of gaining flexibility and not losing it,
> if you design your application to be able to handle
> any Java object that can be thrown at it :) Always having to know
> the type of things that are coming at you is a woeful left-over
> from strong-typing fanatics. > Here's an example to illustrate my point:
> - if you were to design a form-based application would you rather
> buy a forms-tool and start hacking each time you had to build
> yet another form for yet another table/set of tables in the
> database or would you write a generic class that can use runtime
> information to customize the ui based on properties detected
> at run-time? Well, I agree with you that I wouldn't programmers to "start
hacking each time." I would be inclined, however, to make a
form an object. Sounds like an object. Sounds like I need
a class Form. That can be a superclass which
programmers subclass each time they need a new form, and
the superclass Form could have a method, say
display() that when invoked puts up a frame
which displays the form. This way, no run time class info is needed. The software
that uses the form knows it has (some subclass of a)
Form, and it just invokes display()
on it. Dynamic binding will ensure the right form gets
displayed. So this is how I would think about doing this
and it doesn't involve run time class info. Now if you want programmers or users to create their own
forms, which may be what you were getting at, then perhaps
you don't need a different class per form, but a different
object per form. In other words, there is a class
Form which contains sufficient data to describe
the look of the form and how it is related to the database.
These forms could be serialized and stored somewhere, so
they are always available. Users could build a little library
of their own forms. Once again, no run time class info. Is there something else that you envision for which these
solutions are unsatisfactory? bv
Replies:
|
