“Brokered definition set” design pattern — well-known under another name?

Question

In a project that I\'ve been involved with for many years, I\'ve gradually evolved a design pattern that\'s proven to be extremely useful for me. I sometimes feel I should

Answer 1

It sounds like a variety of a Flyweight (many cars share a WankelEngine). But how does that make sense? Most cars have an engine, but how can many of them have the same instance of an Engine? They wouldn't get far that way. Or do you mean that many cars have an Engine of type WankelEngine? Spose that makes more sense. Then what's the use of the "WankelEngine definition object"? Is it a Factory that's building flavors of that object and passing them back to the requestor? If so it doesn't sound like a definition object, sounds more like a Factory that's taking in the parameters of the object to build and giving that object back.

I do see some good GoF practices in here, specifically that you are composing instead of inheriting (my Car has an Engine vs. my Car's Engine is a WankelEngine). I wish I could recall the quote exactly, but it's something like "inheritance breaks encapsulation" and "favor composition over inheritance".

I'm curious what problem is solved by this. I think you've added a good deal of complexity and I'm not seeing the need for such complexity. Maybe it's something specific to your language that I don't understand.

The GoF guys do discuss composing patterns into larger patterns, MVC in particular is an aggregate of three other patterns. Sounds like you've done something like that.