Re: Design Pattern Question
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Mon, 20 Aug 2007 16:05:54 GMT
Responding to Marshall...
There is a formal mechanism for this known as subclass migration. Basically one deletes the old object and instantiates a new one with the same identity and attributes in the new subclass. However, it tends to be messy and fragile in practice, so it isn't used very much.
I didn't know there was a name for such a thing, and I'm not entirely comfortable that there is either for some reason. There is something about naming such a thing that lends it a bit more credibility than maybe it deserves. Dunno.
Actually, I've only seen that name in the old Shlaer-Mellor and ROOM methodologies back in the '80s.
At the OOA/D level classes are just identity sets. There is nothing to prevent an object with a given identity from moving to a different set so long as its identity is unique.
The problem lies in the fact that classes also defined property sets that are shared by members. Since normalization requires those property sets be unique, that creates problems for the migration because the object will have a different set of properties after migration. However, there is nothing technically wrong with that so long as the current property set mapping to object identity is clear. Subclassing provides a convenient mechanism for sharing properties so one usually only sees such migration in generalizations.
However it can get quite messy in practice. For example, let's say object X has property A in one subclass, X1, but not in another, X2. If X migrates to from X1 to X2, it loses property A. So far, so good. But what happens if it migrates back to the X1 set? It has property A again. But should the value of property A be the same as it originally was before any migration? (The value depends on the identity of X and only the identity of X via 3NF so intuitively one would expect it to "recover" the original value it had.) Carrying a history of migration then becomes a real rabbit hole.
A similar problem occurs for relationships. When the object migrates should all of its relationships still be in force? Clearly not for direct relationships to the subclass since those exist because only that subclass' properties satisfy LSP. But what about relationships via shared superclasses? Just finding them might be an adventure since they may be one-way implemented in clients as referential attributes. Worse, there might be direct relationships to the new subclass that need to be instantiated, which means the migration needs to understand a whole lot about context.
So it is pretty easy to see why the GoF State pattern is a whole lot easier to manage. b-)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- References:
- Re: Design Pattern Question
- From: H. S. Lahman
- Re: Design Pattern Question
- Prev by Date: Re: Design Pattern Question
- Next by Date: Re: Leader/Follower design pattern question
- Previous by thread: Re: Design Pattern Question
- Index(es):
Relevant Pages
|