Created attachment 15646 [details] RecordFactory added to instanciate pp records
Created attachment 15647 [details] cvs diff for the previously attached jar cvs diff for the previously attached jar
Is this an improvement on the new record instantiation code I committed on Friday? It looks like a slight step back to me, since it has two places recording the types, RecordType+RecordFactory, while my new code only has the one (RecordType)
(In reply to comment #3) > Is this an improvement on the new record instantiation code I committed on > Friday? It looks like a slight step back to me, since it has two places > recording the types, RecordType+RecordFactory, while my new code only has the > one (RecordType) Yes, it is an improvement. We shouldn't put all eggs in one basket. RecordTypes should be simple. It's just a map of record ID and Name. RecordFactory is responsible for the new record instantiation. Such design keeps things simple and more object oriented. It is not a step back at all.
I consider it a step back, because there's a lot of duplication in your design. Rather than have on class hold the triplet of name+type+class, you end up duplicating information across two classes. It makes it harder to follow, and increases the chances of mistakes/inconsistencies/confusion. Personally, I find one long list in one place much simpler than two half duplicated lists in two places... It might not be purest OO, but I find it a more pragmatic design!
(In reply to comment #5) > I consider it a step back, because there's a lot of duplication in your design. > Rather than have on class hold the triplet of name+type+class, you end up > duplicating information across two classes. It makes it harder to follow, and > increases the chances of mistakes/inconsistencies/confusion. > Personally, I find one long list in one place much simpler than two half > duplicated lists in two places... > It might not be purest OO, but I find it a more pragmatic design! There is no duplication. There are two objects and which of them is responsible for the specific functionality. RecordTypes is needed only to map ID and Name. That'all. Consider it as final class. It is not meant to be modified. RecordFactory is responsible for the instantiation. When you create a new class which extents Record you will have to register it there, not in RecordTypes! Also I think we should follow object oriented design. It's going to be a big project and we must do it right. What seems pragmatic to you now can be a pain very soon!.
It depends on if you consider things at just the java object level, or at the overall object level. There is a record "entity". For every kind of powerpoint record, we have an "entity". This entity contains details of the type, the name, and the implementing class. I don't want to duplicate any of that information, hence my desire to put all the parts of that entity into one file. Your scheme puts one pair (type+name) from the entity into on file, and another (type+class) into another. There is duplication of "type" across two files, and duplication isn't great. I much prefere keeping the whole of the record's "entity" details in one class, or failing that in just one file. If we did go down the two class route, I think it would be via two auto-generated classes from one master meta-file, which contained the tripplet of details for each record.
Fixed long time ago.