Multiple abstract factories?

From: Bob Hairgrove (invalid_at_bigfoot.com)
Date: 12/11/04

  • Next message: Freecomputergetter.: "Opportunity is Knocking" 
    Date: Sat, 11 Dec 2004 21:54:27 +0100

    What's the best way (OK, I'll settle for a "good way") of designing
    this?

    1. An executable file can have more than one application type compiled
    into the project, e.g. a setup mode, a demo mode, and a batch mode.
    The setup mode has many GUI objects enabling the user to enter and
    store persistent data which is later used in batch mode. Demo mode is
    basically a special case of batch mode which doesn't need some of the
    library support (e.g. database access) required by batch mode, but
    might need additional GUI objects. Command-line parameters are
    evaluated at startup to determine which kind of application to run.
    Typically, one might have a factory method which takes a command-line
    parameter and returns a concrete instance of an abstract "Application"
    object ... but read on ...

    2. The application needs to fetch different configuration data
    depending on the concrete type of application which is to be run; i.e.
    setup mode needs some dialog templates which are not needed in demo
    mode or batch mode; batch mode needs connection parameters (user id,
    etc.) for a database, perhaps also needed by setup mode, but not demo
    mode.

    3. None of the configuration data is hard-coded into the concrete
    application class because it can come from different places; e.g. in
    some runtime environments I might use an external XML file, not
    compressed for ease in debugging, in other environments a database, in
    yet another I might store a zipped XML file as a custom binary
    resource directly in the executable.

    4. Any of the various concrete "xxxApp" classes can get configuration
    data from any of the derived "xxxCfgMgr" classes. That is, there is a
    many-to-many correlation between the two. Do I need an intermediate
    layer/class to handle this? I was hoping that I could have an
    overridden factory method in the concrete "xxxApp" classes which would
    create the appropriate "xxxCfgMgr" class ... Do I need an additional
    abstract factory for ConfigMgr? How would I link the two abstract
    factories together?

    So far, this is what I have:

                  <<abstract>>
                 +-------------+
     ............| Application |.....................
     . +-------------+ .
     . /\ .
     . ---- .
     . | .
     . | .
     . .-------------------. .
     . | | | V
     . +--------+ +-------+ +--------+ +------------+
     . |SetupApp| |DemoApp| |BatchApp|======>| AppFactory |
     . +--------+ +-------+ +--------+ +------------+
     . /\ /\ /\ <<singleton>>
     . \/ \/ \/
     . | | |
     . | | (BatchCfgData)
     . | (DemoCfgData) ^
     . (SetupCfgData) ^ ?
     . ^ ? ?
     . ? <<abstract>> ?
     . +------------------------+
     ........>| ConfigMgr |
              +------------------------+
                          /\
                         ----
                          |
              .----------------------.
              | | |
         +---------+ +---------+ +--------+
         |ResCfgMgr| |XmlCfgMgr| |DbCfgMgr|
         +---------+ +---------+ +--------+

    Thanks. 

    --
Bob Hairgrove
NoSpamPlease@Home.com
  • Next message: Freecomputergetter.: "Opportunity is Knocking"