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?

Quote:

---

Originally Posted by Steve11235

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?

---

Depends on how tightly coupled the object should be to the data used to create it, I suppose. For example I'd say it was perfectly valid for a class that is representative of an element in some XML to take an Element in its constructor and use that to populate itself, but you need to be aware you've now tied that object to that XML.

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).

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.

Quote:

---

Originally Posted by Steve11235

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.

---

Well, objects as simple data containers seem to come from the database side of things, or at least in the old EJB days. DTOs (or VOs if you prefer) spring to mind...objects which are essentially data containers for transferring over the network. I had an argument with someone once who thought that if you stuck more code in the DTO/VO it would take longer to transmit over the network...oh how we laughed.

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.

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.