Re: Moose, Metadata and the Everything CMS

I see this kind of thing a lot in my work - we often assume that "type" means class, but as a design progresses we realize maybe it isn't after all, or maybe it is some sort of hybrid, or ...

In sorting out these sorts of problems, it is important to realize (as I think you have) that "meta" is relative. It is always meta to something else and we can have layers upon layers of meta. Just check the UML specs if you don't believe - if I recall there are 3 or 4 meta layers in that model alone, and that is just to model modelling!

So instead of thinking of these problems in terms of things, instances, classes, and types, I prefer instead to model "sets" - sets of related data, methods, and actions. To this end I recommend reframing the issue in light of the following questions. My sense is that you have a pretty good handle on 1,2,3 but are working your way through 4 and 5.

what data do I need to track about X?
what calculated things do I need to make with my data about X?
what operations or intentional side effects do I need to do using my base and calculated data?
How are the instances of X related to each other? When viewing the entire set of things that I consider instances of X how do they differ from one another? Is there a common core of data, actions, and calculations shared by all? Do subsets vary in specific ways? Is this really one class for all X instances? Separate singleton classes for each X instance? Or something in between - a superclass and a handful of subclasses? For that matter, is each instance of X really one "thing"? Or is a set of connected things? Can I explain the differences between various instances of X in terms of X's parts? Or is there something about each X instance that makes it more than just the sum of its parts?
And finally for a bit of intelligent crystal ball gazing: How stable is my current set of all X? Do I have enough information to be certain? What kind of objects are likely to be added to it (given scope, user community)? Why? How are they likely to be different from the X instances I already know about? Have I studied other applications, implementations, or standards documents to see what sort of X instances they come up with?

Question 1 identifies a set of data members. Questions 2 and 3 identify a set of methods. Question 4 keeps one from jumping to either-or conclusions about class architecture. And 5 is meant to jog one loose and prevent the short-sighted-ness that creates the need for yet-another-foo-framework.

Only after you have have a clear handle on these questions, can the questions about implementation be answered. (And if you have the answers expanding your post to include them will get better feedback).

A "class" is just an object with its own special set of data and methods. Some of this "data" may be pretty funky (e.g. code references) but it is still data. Furthermore, its definition is surprisingly dependent on your chosen framework. If your answers to the above questions line up with the data and methods available for a class as defined by OOP framework Foo, then by all means use framework Foo and treat X (or instances of X) as a class within that framework. But if not, pay closer attention to questions 4 and 5 and feel free to be creative in how you use the resources of your chosen OOP framework.

Best, beth

Comment on Re: Moose, Metadata and the Everything CMS

Replies are listed 'Best First'.
Re^2: Moose, Metadata and the Everything CMS by Nomad (Pilgrim) on Feb 27, 2009 at 09:58 UTC
Thank you for this great, thought-provoking reply. It has certainly got me thinking about how to group the data and operations that need to be performed on the data. In relation to specific issue of the data that have been classified class data, the data can be classified like this: the name of the class into which the object data should be blessed. data that allow a user object to perform an operation on another object(these operations are currently only insert, update, delete and execute) data that determine whether additional operations should be performed on a data node when it is inserted or updated in the back end database. These data are hierarchical so that data related to objects in a sub-class may override the defaults set in the superclass. These data follow the class structure of the objects to which they relate. What your post made me realise is that data such as access data don't necessarily have to follow the class structure of objects themselves. So, for example, whilst objects of class Node have access data of type Access::Node. Its subclass Node::HTMLData doesn't have to inherit its access data from Access::Node (although it could), perhaps its access data could come from Access::HTMLObjects. I'm going to give this some further thought and tweak some of the code - (first step will be to move the access methods into roles, I think). Thanks for your help.	[reply]
Re^3: Moose, Metadata and the Everything CMS by stvn (Monsignor) on Feb 27, 2009 at 15:38 UTC
What your post made me realise is that data such as access data don't necessarily have to follow the class structure of objects themselves. So, for example, whilst objects of class Node have access data of type Access::Node. Its subclass Node::HTMLData doesn't have to inherit its access data from Access::Node (although it could), perhaps its access data could come from Access::HTMLObjects. Perhaps you should look into Roles for this. They make it very easy to address cross-cutting concerns like this by using their more horizontal composition style. This approach also tends to help prevent the typical OO explosion of subclass trees where you need to subclass an entire section of your class hierarchy to just extend one node of it, sometimes called the Expression Problem. -stvn	[reply]