I've been following the discussion on Inside Out objects with considerable interest. The subthread about Flyweights and the Flyweight design pattern further sucked me in.
I'm a database guy, so that perspective colors my perceptions of how this concept maps into my world. I haven't noticed mention of that angle (database). ...so here goes!
Let us consider a small relational model:
Entity Primary Key Attributes
Blazon Blazon_ID Blazon (which may be long)
Registration Registration_ID Date_Registered
Owner_Name_ID
Blazon_ID
How_Used
Date_Released
Name Name_ID Name (which may be longish)
...other attributes
Note that two of the attributes of a Registration are
foreign keys from the Blazon and Name entities.
One possible object interpretation of this data model can be based around the Flyweight pattern. A Perl implementation could use a blessed scalar for the object, where the value of that scalar is the Blazon_ID, Name_ID, or Registration_ID. The Blazon class implements the Blazon table; it could have a real RDBMS backend, or it could use some other persistence mechanism. Similarly for the Name and Registraton entities.
For nuts-and-bolts access/update, object methods provide access to the attributes/columns of the individual objects (update). Class methods provide entity/table level access (insert/delete/select). The class can provide caching as appropriate.
...so where am I going with this?
If one looks at one's object model through a "relational data model (normalized)" lens, many entities/tables are strong candidates for this approach (flyweight and/or inside-out).
A normalized data model tries really hard to follow the dictum "each datum is recorded in exactly one place". Multiple references to a specific datum need to be by a "reference" of some sort, be it a Perl reference or a foreign key relationship. It can be helpful to have the key value be content-free -- an arbitrary value (often numeric).
In the example above, one could have each class (Blazon, Name, Registration) overload stringify to produce sensible output (the Blazon, Name, or a string compounded of the attributes).
OK. I'll admit that I've changed subjects on the fly (and revised my title about here). I'm advocating that relational data modeling be kept in mind when putting together a package that has complex data. Many cases will only have a single entity class, but many others will have multiple, interrelated entities. If you have a data model that clearly describes your entities and their relationships, you can then make informed choices that may leave you with a denormalized implementation, but the key is "informed".
yours,
Michael
In reply to On Flyweights... (with sneaky segue to data modeling) by herveus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |