Martin Vajsar wrote:Couldn't you take the ID generation into your own hands completely
Martin Vajsar wrote:(it is much easier to read, remember and/or type a four, five, six or seven-digit number than a UUID).
Bill Gorder wrote:Changing the type seems a little strange in the inheritance strategy. I am not sure about the function of the objects to know how much sense inheritance makes in your domain.
Jayesh A Lalwani wrote:I'm with Bill here. Morphing of types just feels so wrong. It's like you are breaking some cardinal rule of OOP Are you sure you want to do that? Are you sure you don;t want to model these objects as differrent "states" rather than as differrent types.
Jayesh A Lalwani wrote:Ok, so does the user change the Point, or do they change what is contained in the Point? It seems to me like you are conflating the topology of your system with what is contained in the topology. It seems to me like you should be able to describe that shape of the system seperately. It could be that many of your "shared" properties are the property of the topology rather than the object itself
Jayesh A Lalwani wrote:Similarly I have the main pipe running between floors. Is that the Line? or does the Line contain the Pipe? It seems to me that if I replace the I dunno.. copper pipe with gold pipe
Jayesh A Lalwani wrote:From what you describe.. and the way I see it.. a Point has a Node/Inlet/Storage Area. You are seeing the relationship as a Is-a relationship which is why you have the "problem" of morphing types.
Bill Gorder wrote:Or alternatively if a point has common properties such as x, y coordinates it sounds like it really is kind of like a location. So maybe really what you have is a Node/Inlet/Storage Area that all have a location.
Martin Vajsar wrote:And what about the requirement that the ID of the entity must not change when the type changes? Why is this so? To protect referential integrity, or some other reason?
Roel De Nijs wrote:
Jayesh A Lalwani wrote:From what you describe.. and the way I see it.. a Point has a Node/Inlet/Storage Area. You are seeing the relationship as a Is-a relationship which is why you have the "problem" of morphing types.
To be honest I have thought about this approach. From an OO perspective this is definitely the better design eliminating the need of morphing types. An initial version could be:
But I have no clue about mapping this using JPA annotations to a database model (each PointType having specific properties). That's why I implemented the current design. If I can't solve this issue, I'll have to stick with the current one.
Bill Gorder wrote:I think you have a couple options now that should help you solve your problem without the need to 'morph' objects.
That is a really big piece of pie for such a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|