BrianBrazil is a computer scientist (software engineer by trade) from Rhode Island who stumbled upon the WikiWikiWeb doing research on DesignPatterns.

While reading about such patterns, I came up with (what I believe to be) a cool idea called CoreObjectDesign. A CoreObject is an encapsulation of an encapsulation, a further abstraction of ObjectOrientedDesign. A quickie concrete example is the WarpCore on StarTrek ships (I don't really watch the show often, but every time I click through it, they dump the WarpCore 4 or 5 times). Imagine the "guts" of an object as a removable, replaceable core which can be "gotten" by a requesting object and later replaced by that object.  If you're familiar with the MementoPattern, this should all be very familiar: an object can request a "snapshot" of an object (without violating encapsulation) and replace it with a new one.  Now, to me, that kinda violates OO, knowing what's inside an object, whether done by "legal" means or not.  Using a CoreObject design, an arbitrary object contains a CoreObject, which maintains the current State of the object. The encapsulating object has externalized methods with which an external object may request a clone of the CoreObject.  The encapsulating object should also contain a method to request that the current Core be replaced with a new Core, provided by the calling object.

This sounds like a Memento object, doesn't it?  One of the key advantages of a CoreObjectDesign, at this point in its construction, is that an encapsulating object may contain two or more cores, which may be interchanged at will.  One application is a complex StateMachine (big whoop).  Another, more useful, application is the object's ability to jettison a core and replace it with a "good" core.

As I said, the idea is in infancy. :):)

''Moved this description to CoreObject... feel free to delete this or whatever at your discretion :) -- WilliamUnderwood''

----
CategoryHomePage