I am not sure if this is an intermediate level question or if most people on this forum would consider it a basic question, but here goes: If you were to develop an enterprise level framework for handling various kinds of data, would you create a generic object that could handle any kind of data put into it (say, a hashmap) or would you create a proper class heirarchy, adding sub-types everytime a new data type was added to the framework? Or is there some form of middle ground?
In other workd, you have a generic framework for moving data through a set of tasks. This data can take the form of jpeg images, xml files, text files, etc. Would you create a generic class, using something like a hashmap, into which you could place all the various kinds of data along with meta data that describes what the object was holding? Or would it make more sense to create a class heirarchy in which you passed the super/abstract class arount the framework? Each subclass would contain attributes specific to the type of data it represents and can be dealt with accordingly. The first method would involve first inspecting the object to determine what was inside of it before you could work with it.
My feeling is that the class heirarchy method is the proper OO way to go with this problem. However, I need some convincing arguments to this affect. Anyone have any or know of any links to arguments that relate?
I think this calls for composition. Create an object that moves other data of whatever type around. Maybe define an interface that that other data confirms to and use a decorator pattern to decouple the actual data from the interface you need for the framework.
So you'd have the actual moving object, which is a single concrete type inside the framework. That object contains anything that implements an interface you design which you publish to the outside world. To make it easy you define a system of decorators for real data of different types which implement that interface and just hope that your users will be smart enough to follow your example
Joined: Dec 13, 2004
Interesting idea, thanks. It maybe a little too complex for the managers here, but it gives me something to think about.
A question though: how would this be better than passing a super class around the framework and using the instanceof operator to inspect which concrete object is being received? I realise that doing it this way increases the coupling between the data object and the code working with that object, but is that necessarily a bad thing?
I'd also consider what behavior you want out of the things you store. Would it help if every object in your collection could render itself on the screen? Or report some properties or statistics? Then you might have an interface or base class with many new types extending it.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Dec 13, 2004
Something to think about. Currently, beyond the need to transport various types of data (xml, text, image) around a framework and manipulate that data is various ways (normalize, quality assurance), there is not much that the objects need to be able to do really. However, they do need to be able to carry a lot of data consisting of compound data types and express various relationships between objects that contain more data (these can become very complex data structures).
The current implementation uses a hashmap that can recursively store itself to several levels deep (currently 4 levels). And each level can contain up to 60 individual objects all stored in a Vector which is then stored in the hashmap.
There has got to be a better, more manageable way to deal with these.