• Post Reply Bookmark Topic Watch Topic
  • New Topic

design advice  RSS feed

 
Mike Southgate
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I need some advice on how to best design something. I have the Java Threads book to cover the thread side, and also the Head First Design Patterns (which I haven't finished yet) to help with the design...

I need to build a gui to start and report on a number of daemons. Each daemon is configurable by about 30 or so properties. Each property can be either a String, boolean, int, TimeStamp etc. The plan is to pass a Collection of DaemonProperties to the Daemon class to tell it how to behave.

What I'm planning thus far...

Create an abstract class called DaemonProperty which will be extended by classes like DaemonPropertyString, DaemonPropertyInt, DaemonPropertyBoolean etc.

I'll then create a DaemonPropertyFactory class which I'll use to actually build the right type of DaemonProperty.

Now the questions...
Obviously the daemon is gonna have to walk the collection of DaemonProperty s and interrogate each to figure out what to do. Trouble is, each property returns a different type so how do I avoid a big switch that has to be changed for each new property I invent?
What is the best form to put the list of properties currently supported in? I'm gonna have to walk this list and pass it into the Factory to get my Collection of DaemonProperty instances.

As an aside, my plan is also to have the DaemonProperty class return a JPanel that contains the components required to interrogate and update the property's value. Any pitfalls you can think of here would be appreciated.

thanks

ms
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure whether you would want to create new Property class based on the data type of the value stored.

I would suggest that store the property value as Object and give methods like:

getStringValue(), getBooleanValue(), so on and so forth.
Also provide a method giving the type of the property.

The property implementation can cast and give an appropriate object to the caller from the above methods.
The above is on the assumption that the user of the property knows the property type and so can call an appropriate method directly without checking the data type.
If the caller does not know the type then there are two options (depending on what the caller wants to do with it)
1) If the caller does not process the property: Do not worry about the type, take an Object and pass it to any class who processes it.
2) Get the type and call an appropriate method. No way to avoid the big switch-case as far as i think.

About the JPanel thing, i think it must be fine until and unless you are sure that you will never change the technology used to interrogate/update the property. If you think you will, then provide your own interface to interrogate/update the property. One of the implementation can be a JPanel. If you do this, you will be able to change the technology without the Daemon s being aware of it.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!