2

My Command object contains a combination of required and optional information used to construct my domain object.

class Command
{
  /*
  | Required stuff
  */
  private $req1;
  private $req2;

  /*
  | Optional stuff
  */
  private $opt1;
  private $opt2;
  private $opt4;

  private function __construct($req1, $req1, $opt1, $opt2, $opt3)
  {
    $this->setReq1($req1);
    // ...
  }
}

For objects which have a large number of parameters (required and/or optional), you might make use of the builder pattern rather than having lengthy constructors. I could use a builder for my command, however, I'm not sure this is the correct approach?

Is the builder pattern appropriate here or should I simplify the command to be more DTO like (public attributes) and perform the validation in the command handler? Or is there another option?

Peppermintology
  • 9,343
  • 3
  • 27
  • 51
  • Builder is a fairly complex pattern. Are you positive it will solve more problems than it'll bring? – Justinas Marozas Feb 03 '18 at 19:32
  • @JustinasMarozas - I don't know, hence my question. – Peppermintology Feb 04 '18 at 13:13
  • You could have a builder that requires the required parameter to be used, and let the user to configure just the optional ones, something like: `Command.builder(req1, req2).opt1("aValue").build()`. I like this approach because it enforce the requiredness of the parameters (you can't create the builder without the required parameters). – rascio Feb 05 '18 at 09:49
  • 1
    @rascio - That is currently what I am doing and it seems like a reasonable approach. – Peppermintology Feb 05 '18 at 12:26

1 Answers1

1

For objects which have a large number of parameters (required and/or optional), you might make use of the builder pattern rather than having lengthy constructors. I could use a builder for my command, however, I'm not sure this is the correct approach?

You should probably think about command the way you do about message.

Message builders are a convenient pattern for isolating consumers from the details of the optional parameters in the message -- your builder can come packaged with reasonable default values that the clients don't need to know about.

Note that this is an orthogonal concern from whether or not the constructed properties should be public or private; once you have decided that the properties of the message are immutable, public vs private largely becomes a question of whether or not you need to isolate the consumers from possible re-arrangements of the underlying data.

Not sure what you mean when you say think about command the way you do about message?

What a command object really is: an in memory representation of inputs being passed to a model.

Common case: user submits a form, which is transmitted via an http request. The payload (which is, at one level of abstraction, just a byte array) is given a domain specific interpretation. Typically, our application layer wraps/converts the byte array, and passes it to the domain model -- the domain model never sees "bytes", but rather "values".

But the semantics are those of a message; in particular, you have various compatibility concerns if the original source of the command and the domain model are independently deployable -- old clients trying to send commands to new models, new clients trying to send commands to old models, and so on.

One approach to dealing with these concerns is to treat the command as a weakly schemaed message; many optional fields, with default values to be assumed if an optional value is missing. The Builder pattern is a natural fit for this approach -- the builder knows all of the default values, tracks those cases where an override of the default value has been provided by the client.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91