I am designating an architecture which uses some differents objects
controller which implement an
Their goal is to encapsulate the use of some data.
Some factories are responsible for creating and initializating the controllers.
controllers might need some other
controllers, and every used
controllers needs some information from the database, especially on first run.
Nb : In my application, clients must know about the catalogs they can order from.
For instance, if on an execution I need tu use the
client are created by the
client_factory (and somehow provided), but in this case I must be able to provide information about
catalogs as well, and initialize my
catalog_controller (and so on).
So here, there would be only three dependencies :
clientdepends on the data in the database.
catalogdepends on data in the database. (assuming this is the only dependency of the
What are options to indicate that
yyy_controller or even
In the first time I thought of maybe making corresponding
requires_xxx_controller interface with a predicate, but then it seems I should make one interface for each and every
controller, and then it wouldn't be really extendable.
My next idea was to make
has_requirements interface , make
database_information (and some others types) implement
requirement and controller
has_requirements would return the list of dependecies it has, which I would store in an ordered set, ordered by insertion order, (which luckily exists in
boost), but even then, I would be obligated to come up with a solution to return a collection of those
requirements which I cannot build.
What flaws am i exposing to in theses cases ? Is there a commonly accepted solution for this problem ?
I doubt it changes anything big, but
c++ is the language used in this application.