in reply to How to organize Catalyst stash
As a general rule, I think that an object should be entirely the master of its own affairs ... including “the set of properties that it may contain,” and “the means to present information about itself, in whatever format may be needed by anyone.” You don’t want to have a “third-party” piece of code that is dependent on knowing what an object is supposed to contain, nor that acts as an intermediary between two other parties, because it now becomes functionally dependent upon both of them.
If a particular object needs to serve-up a date, perhaps formatted in a certain way, then provide at least a method that will return a date-value, and a function (perhaps, which can be applied to any such date) to make it presentable. If it has a date-property that needs to be assigned, provide an accessor-method for that property which knows how to munch a string, and which croaks (see: Carp) in a meaningful way if that string is no-good. No one, other than the object itself (or perhaps one of its ancestor classes), knows any of the details – or needs to. Whatever you need to give the object, and whatever you need to take from it, tell that to the object.
If you have an object that has “a lot of properties, and you don’t particularly feel like churning out a bunch of accessors for them ... of course you don’t have to. There is plenty of CPAN support for that sort of thing. (“Laziness” is a Virtue.)
If the object needs to serialize itself out to the Catalyst stash, or back in again, once again, there are established tools for doing that. And the object (or perhaps an ancestor class) provides that service for itself.