Object-oriented – Handling Different Parameters for Derived Classes

api-designcdesign-patternsobject-oriented

I'm designing an API and I ended up having a few pure abstract classes. Because of the nature of the problem that I'm solving, each derived class has to be initialized with different sets of parameters. My solution was to basically define their constructors and pass the appropriate parameters when I'm making each class using the factory method. This makes the factory method rather complicated. Since I have to pass all possible parameters and then filter the appropriate parameters for each derived class and pass it around. It also opens up a path for error.

In order to avoid this complication, I would like to have the parameters as a type. So, I'm thinking to define struct BaseClassParams and basically include everything that derived classes need into it and simply pass the param to their constructor. This achieve what I want to do but since parameters of each derived class might differ from one to another, I want a better encapsulation. I thought doing something this:

class Base {

public:
     struct BaseClassParams {
          struct DerivedClass_A_Params {

          };
          struct DerivedClass_B_Params {

          };
     };
};

This way, I can encapsulate everything more neatly and in the factory method, only pass the appropriate parameter section to the derived class constructor. I wonder if you have faced this issue and if you have any suggestions? Overall what do you think of this approach and problem.

Edit: To clarify a bit, these derived classes are going to be used by a class, i.e., Manager. The Manager can choose to create different derived class, let's call them Employee, with different parameters. The Manager class can be initialized using a config file, i.e., JSON, or directly. If the Manager is created directly via the API, then Manager::Builder class can choose to create as many different employees with different parameters. So, I need to create these objects at run time.

P.S. I found this question and answer. The difference here is that my derived classes are not necessarily sharing parameters, they might have completely different parameters. This is kind of relevant too.

Best Answer

Problem with `BaseClassParams`

Using

 struct BaseClassParams {
      struct DerivedClass_A_Params {
      };

      struct DerivedClass_B_Params {
      };
 };

to capture the data needed to construct derived classes is DOA in my book. As soon as you need DerivedClass_C, you'll have to go back to the base class and update it to

 struct BaseClassParams {
      struct DerivedClass_A_Params {
      };

      struct DerivedClass_B_Params {
      };

      struct DerivedClass_C_Params {
      };
 };

That violates The Open-Closed Principle and should be avoided.

Separation of concerns

Make sure that Base and its derived classes are clean. Don't pollute them with what mechanisms are used to construct them.

Say your base class is Shape, and Circle and Square are derived from it.
- It makes no sense to pollute Shape with Circle or Square specific data.
- It also makes no sense to pollute Circle and Square with higher level concerns -- such as how does the user gather the data to construct them.
Using a factory to construct any derived type of a given base type implies the ability to capture derived class specific data in a derived class agnostic manner. You'll have to find a generic way of capturing such data. The can be:
- std::map<std::string, std::string>,
- std::vector<std::string>,
- A JSON object, etc.
You will need a set of classes/functions to bridge the gap between (1) and (2) above. That's were you need concrete factories that are able to:
- Take the generic data from (2)
- Validate the data for constructing the specific object type they are responsible for constructing.
- Construct objects of the derived type.

My suggestion in pictorial form

The image below illustrates my suggestion.

Related Solutions

Object-oriented – Avoiding constructors with many arguments

I wouldn't do option 2, because then you have forever convolved your object's construction with boost property tree parsing. If you're comfortable with a class that needs that many parameters, you should be comfortable with a constructor that needs that many parameters, such is life!

If your main concern is code readability, you can use the builder pattern, it's basically the c++/java stopgap for lack of named arguments. You end up with things that look like this:

MyObject o = MyObject::Builder()
               .setParam1(val1)
               .setParam2(val2)
               .setParam3(val3)
             .build();

So now MyObject will have a private constructor, that gets called in Builder::build. The nice thing is that that will be the only place you ever have to call a constructor with 10 parameters. The boost property tree factory will use the builder, and subsequently if you want to construct a MyObject directly or from a different source, you would go through the builder. And the builder basically lets you clearly name each parameter as you pass it in, so it's more readable. This obviously adds some boilerplate, so you'll have to decide if it's worth it compared to just calling the messy constructor, or lumping together some of your existing parameters into structs, etc. Just throwing another option on the table.

https://en.wikipedia.org/wiki/Builder_pattern#C.2B.2B_Example

C# – Command Handler for Executing Commands with Different Dependencies

The problem you have is the conversion of the string to the class.

Not much you can do about it, As you will always have to have some factory which knows how to parse string x into object a,b,c somewhere.

But I would move the logic outside the command handler, which should just accept the command objects. And do the conversion as the strings are read into the application, via a repository (your inputReader or IData?) into which you inject your string parsing factories.

If you allow failover, so that when one repo/factory cant handle an input string it moves onto the next, that will give you further seperation of concerns.

If you use a DI or object serialization/deserialization library in yoir repo/factories (unity,json.net) that will hide some of the reflection/switch statements from your code and make it neater.

Also I would allow for the case where a command cannot be handled. This isnt a bad thing, you should expect only to be able to handle the commands your code 'knows' about and for some other program to deal with the others.

Additionaly, are you sure you need both commandHandler AND command.Execute() it seems to me that you should choose one or the other. If you go with command handlers you cam have one or more per type. The handler has the injected dependancies and the logic from the execute method.

This keeps your handler decoupled, as it only handles a single type of command, you can pull only those types from a queue(IData).

Of course if you keep execute and only pull one type (or set of known types) of object you have the exect same code just arranged differntly, but you can cut out the command handler class, as it just calls execute.

The benefit (if any) of the handler is you can handle the same command type more than one way. Whereas with execute you have to define a new command type with the same data.

example :

class Engine()
{
    IData data; // application database
    IInputReader inputReader;
    Dictionary<string,ICommandHandler> commandHandlers;
    public void Run()
    {
        //todo use a DI framework to inject these types 
        commandHandlers = new Dictionary<string,ICommandHandler>();
        commandHandlers.Add("DisplayData", new DisplayDataCommandHandler(new OutputWriter()) );
        commandHandlers.Add("Build", new BuildDataCommandHandler(new Builder()) );

        foreach(var data in this.data.GetCommands())
        {
            if(commandHandlers.Keys.Contains(data.type))
            {
                var command = inputReader.Read(data.type, data.serializedObject);
                //handle the command
                commandHandlers[data.type].Handle(command);
            }
            else
            {
                //some other program will handle these commands
            }
        }
    }
}

public class InputReaderAndFactory : IInputReader
{
    public ICommand GetCommand(string commandType, string commandJson)
    {
        switch (commandType) 
        {
            case "DisplayData" :
                return JsonConvert.DeserializeObject<DisplayDataCommand>(commandJson);
            case "Build" :
                return JsonConvert.DeserializeObject<BuildCommand>(commandJson);
            default :
                return new UnknownCommand(commandJson);
        }
    }
}

class DisplayDataCommandHandler : ICommandHandler
{
    IOutputWriter outputWriter;
    public DisplayDataCommandHandler(IOutputWriter outputWriter)
    {
        this.outputWriter = outputWriter;
    }

    public void Handle(ICommand command)
    {
        var cmd = command as DisplayDataCommand;
        outputWriter.Print(cmd.Data.ToString());
    }
}
class BuildDataCommandHandler : ICommandHandler
{
    IBuilder builder;
    public BuildDataCommandHandler(IBuilder builder)
    {
        this.builder = builder;
    }

    public void Handle(ICommand command)
    {
        var cmd = command as BuildCommand;
        builder.Build(cmd.Data, cmd.MoreData);
    }
}
class DisplayDataCommand : ICommand
{
    public Data Data {get;set;}
}

class BuildCommand : ICommand
{
    public SomeOtherTypeOfData Data {get;set;}

    public MoreData MoreData {get;set;}
}