Im developping for my company a software where clients can requests app deployements and upgrades.

Each request has 3 status (Validated, Started and closed).

For every type of request (deployment or upgrading) and for every status , each application has it own logic to execute.

enter image description here

I used the factory design pattern to handle this (picture below).

enter image description here

Is it the good or bad way ?

If I add a new application in the database, I need to edit the code and add new ApplicationInterface, is it bad practice ?

  • How do you define "good" and "bad?" Sep 5, 2018 at 14:52
  • hard to say.what sort of logic do they have?
    – Ewan
    Sep 5, 2018 at 15:09
  • Good = less complex and more maintable, Bad = the opposite.
    – tannana
    Sep 5, 2018 at 15:23
  • example : Deploying app 1 : when we validate the request, many calls to rest apis will be made. Deploying app 2 : sh script will be executed. And we can add new apps and new request steps
    – tannana
    Sep 5, 2018 at 15:27
  • 1
    Also look at the Strategy Pattern. But you have the right idea. Sep 5, 2018 at 15:33

3 Answers 3


The real problem is that an application deployment is encapsulated by a class specific to each application, requiring database and application code changes.

First you need to break each deployment down into a number of steps (Erik Eidt hinted at this, but didn't go far enough). Then identify a clear abstraction for each step.

For instance, you need to move files from a staging location to a server. Define a step (and class) that executes this step given the source and destination, plus login credentials if need be.

Other steps can be abstracted out in general terms, like running shell scripts or making calls to API services.

No single application should be its own class. It could be a class called "ApplicationDeployment" which has a collection of steps. The information specific to each step should be kept in one or more tables in a database or flat file store.

The factory pattern is still applicable for this problem if using it to generate concrete instances of some sort of "step" in an application deployment process.

The problem lies with each application requiring a custom class and database changes.


Generally any time you are reconstituting an object (with methods) from a database you will need to use the factory pattern in one form or another.

Since you can't store the object itself, you need to tell the code which object to create, and that "string to object" code is the heart of the factory object.

However, it's not the only way to do things. You could for example have an object like

class Application { List Steps {get;set;} }

and a number of StepProcessor classes with the logic to run different steps

Now, I always create one of each step processor in my program, and send each step to its matching processor.

I no longer need a factory per se, Step is just a data class with no logic and the processors are always instantiated.

  • The OP is describing Abstract Factory. Don't confuse it with a factory method. Sep 5, 2018 at 15:32

On the face of it, there might be some unnecessary coupling.  To add a new application, you (add a row to the database, and) then have to edit the code in multiple places: first, you have to add a new class that supports the interface, and then second, you have to edit the ApplicationFactory to link the application name string to the new class.

A more generic solution might require only adding (the db row and) the new class.  This might rely on a naming convention and reflection to look up the appropriate class by name.  Alternately, one could have an external configuration file or other entry in the database that associates application names with class names.

Under such schemes, the class could be moved into an externally loaded DLL, and new app-specific DLLs could be created without editing the main application containing the factory.

Still, to add a new app, one has to add to the database and also distribute the DLL.  Distributing the DLL may offer nothing over distributing a new copy of the factory containing application.  On the other hand, such looser coupling may allow different authors to contribute (develop, test, and distribute) code DLLs for new apps without editing the main source code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.