Brian Brazil

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