> > >> Have you considered a configuration-driven appoach, so you could declare > 1 Factory class and then configure it appropriately (with a config file, or > on-the-fly construction args), to perform all of the different types of > encapsulation that you could ever need to do, now and in the future? > > I'd then consider distilling this behaviour down into a Moose::Role, for > any Class to consume. >
I think that's basically what I have -- configurable factories via Bread::Board::Declare. I just thought there might be a way to declaratively build them and their products. I could use the factories to apply my roles to the foreign objects at run time, but that still leaves the foreign object exposed. I'm hoping to use composition instead, and hide the foreign object completely. But I can't always predict how the wrapper and foreign object are going to connect with each other, so there probably has to be some procedural code to do the heavy lifting. This feels like a classic architectural problem -- there is some graph of objects out there, but you don't want to expose them directly to your app (because you will change them out later). I suppose that is what Abstract Factories and Dependency Injection are all about. I'm just trying to figure out how best to realize those concepts with Moose (especially when the objects you're working with already come pre-wired). On a related matter, I'm having trouble deciding whether to use abstract base classes or roles to define the interfaces. I do understand why using both doesn't make sense. Bread::Board::Declare works really well with class type constraints, so it can automatically figure out what to construct for each dependency. But I'm not sure how it would work (if at all) using role types. So that's pushing me towards abstract base classes. They probably wouldn't really be abstract either. Probably more of a no-op implementation, like a logger that just writes to the console, or an emailer that doesn't really send anything. I've found that having a safe concrete implementation that does very little (or nothing at all) helps me fit the pieces together (and test them separately). Whereas roles and abstract classes are, well, more abstract. Anyway, using Moose has really helped me to think more about architecture. Probably because it has saved me from the drudgery of thinking about accessors and constructors and types and so on. I am very grateful for that. And there is much more for me to learn. -Jeff
