Results 1 to 5 of 5
Thread: Unknown design pattern
- 07-01-2009, 07:33 AM #1
Unknown design pattern
I just had a design rejected because I placed the logic to create the contents of an object in its constructor. Instead, the logic was moved to a static method that creates the object and then adds it content. Apart from being ticked off (it was actually around a dozen classes, with test and production versions, that were fully implemented and working), I was confused by where this design pattern came from.
Essentially, the pattern treats objects as data containers and implements the logic in external static methods that act on the data. I haven't seen or heard of anything like this in the Java arena. Is this a standard pattern, in Java or perhaps in embedded C?
- 07-01-2009, 01:40 PM #2Moderator
- Join Date
- Apr 2009
- Rep Power
If, however, that class is not simply created in that fashion, or intended to always be used in that way all the time, you might need to rethink and use a form of factory to build it, so you can then detach the class from how it is sometimes built.
I've used the former in areas that are fairly closed (ie a specific system, with very little intended to be reused anywhere). In larger often more open systems it is preferable to use the latter, so a factory method for building an object of class X is available in subsystem A (say reading from a db), and a different one is available in subsystem B (say XML).
- 07-01-2009, 05:37 PM #3
The classes I created have the following purpose: An XML-based model represents the contents of a simulation executable. In theory, the XML model exactly describes the simulation. In reality, the XML may be incorrect. On one side, JAXB is used to turn the XML into Java classes. On the simulation side, a monitor queries the simulation and reports the actual components in the simulation as a set of classes. My classes are initially based on the XML model, but they have a good deal of logic to allow the user to send information to the simulation. Once the simulation is running, my classes match the XML model to what is actually reported, adding any components missing from the XML model.
In addition, a test system was required. It does not use XML or a running simulation; it simulates both. I used abstract base classes with thin implementations, mostly constructors, to implement these two systems.
OO says that an object encapsulates the data, along with the methods that act on the data. Removing the logic to create the object from its constructor is not OO in any form I know of. What I am asking is, is there a design pattern that creates data structures and operates on them using external functions? I'm not planning on adopting this myself, but I do need to understand where the client is coming from. I'm guessing an embedded C background, but I'm not sure.
- 07-01-2009, 05:49 PM #4Moderator
- Join Date
- Apr 2009
- Rep Power
Maybe that's where the concept comes from? VOs seemed to permeate everything a few years ago, so I do wonder if that's where they got the idea from. I agree with you (in general) that objects should usually do things. Otherwise you end up with managers everywhere.
- 07-02-2009, 12:40 PM #5
I've never worked with EJB, in part because of what you are describing. I'm an old procedural programmer, and the when I saw the opportunity to have the logic operating on the data kept in one place, with the data, it was heaven.
The pattern in use where I am working seems to be the factory pattern gone wild.