• Post Reply Bookmark Topic Watch Topic
  • New Topic

Object design and use question  RSS feed

 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll tell you now, I am very new to OOD and Java and in need of direction. I am not even sure if this is the right place to post this question.

I am writing a program to access different type of sensors via serial port. Each sensor has different access requirements, different data formats, and rather than write a different program for each sensor I would have one program for all sensors that would be able to know via a configuration file what sensor to access and gather data from it.

My thoughts were to create a sensor object which can be extended by specific sensor objects that would have the specifics on how to access the sensor and what the data format would be. Normally in a procedural language I would just write specific subroutines to handle each sensor and the main portion of the program would read the config file and select the appropriate subroutine to run until requested to stop.

Just trying to figure how to do this in Java. I have some of the basics figured out and some of the simple code but this is the interesting and fun part.

So what advice and direction can you guide me?

Thanks
Mike
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A lot of Java code that does this sort of thing uses the class name as a configuration parameter, and then the program loads and uses that class at runtime. The nice thing about this is that you can add new sensor types without modifying or recompiling any existing code. For example (vastly simplified), you need an interface:




and then sensor classes implement that interface



and then your configuration file mentions the sensor to use



and then in your main program, something like



So the key thing is that the main program knows nothing about the class FakeSensor, but it can use it no problem.


 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Based on this I could run this in a thread to access the sensor, parse the data to a data object and other threads handle other processing against the data object, right? The interface enables me to multiple types of sensors (changing access and data parsing based on the sensor requirements) enabling me to add all sorts of sensors as needed.

What would be the approach if the configuration file had



where 31 is the defined sensor instead of



I could use some massive if statement (but that has issues if something is missed,) what about a switch statement?



or is there a better approach. I do not control the configuration file.

Mike
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, the whole point of the code I showed was to avoid exactly that, the "big if" that has to be updated when sensors are added or removed. How about two configuration files, with a new one which lists the sensor classes,

sensor.31=com.foo.something.Something
sensor.32=com.foo.something.SomethingElse

This second one could be packaged with the application, so the user doesn't have to worry about it. But I don't like this nearly as much.

Note that the two approaches I'm showing you allow you to introduce new sensor types whose class names are unknown when the application itself is compiled; the sensor class names are only data, and they are unknown to the compiler. This is a subtle but important point.
 
Mike Bates
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree, I do not like the two configuration file approach either. I like the approach you are presenting as I do not have to change code in the main program, it just works as I add additional sensors.

So if I can control the configuration file, the only concern is the person using it gets the name correct for the sensor. That would be clear documentation and error checking within the program.

Thanks, I now have something more to think on.

Mike
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!