...
| Code Block |
|---|
@Action
public class Customer_placeOrder {
private final Customer target; // target
...
@Value @Accessors(fluent = true)
public static class PlaceOrderParameters {
@Parameter() @MemberOrder(1)
Product product;
@Parameter() @MemberOrder(2)
int quantity;
public Customer act(Customer customer) { ... } // execution
public boolean hideAct(Customer customer) { ... } // supporting methods
public String disableAct(Customer customer) { ... }
public String disable1Act(Customer customer) { ... }
public Collection<Product> choices0Act(Customer customer) { ... }
public Product default0Act(Customer customer) { ... }
public int default1Act(Customer customer) { ... }
public String validate1Act(Customer customer) { ... }
public String validateAct(Customer customer) { ...}
}
...
public static class PlaceOrderEvent extends ActionDomainEvent<Customer> {}
@Action(domainEvent = PlaceOrderEvent.class) // event publishing
public Customer act(PlaceOrderParameters params) { return params.act(this); } // remainder is just boilerplate
public boolean hideAct(PlaceOrderParameters params) { return params.hide(this); }
public String disableAct(PlaceOrderParameters params) { return params.disable(this); }
public String disable1Act(PlaceOrderParameters params) { return params.disable1(this); }
public Collection<Product> choices0Act(PlaceOrderParameters params) { return params.choices0(this); }
public Product default0Act(PlaceOrderParameters params) { return params.default0(this); }
public int default1Act(PlaceOrderParameters params) { return params.default1(this); }
public String validate1Act(PlaceOrderParameters params) { return params.validate1(this); }
public String validateAct(PlaceOrderParameters params) { params.validate(this); }
} |
...
Mixins and Parameters combined (proposed)
The previous section describes an idiom to work within the new Parameter object programming model. But the next step along the journey would be to formally recognise this pattern. This would amount to collapsing the mixin concept and the parameters concept into the same thing. Said another way, mixins start to become stateful, keeping track of the parameter argument values as well as the target object:
| Code Block |
|---|
@Action
public class Customer_placeOrder {
private final Customer target; // target
...
@Parameter() @MemberOrder(1) // supporting methods support
Product product;
@Parameter() @MemberOrder(2)
int quantity;
public static class PlaceOrderEvent extends ActionDomainEvent<Customer> {}
@Action(domainEvent = PlaceOrderEvent.class) // event publishing
public Customer act() { ... } // execution
public boolean hideAct() { ... } // supporting methods
public String disableAct() { ... }
public String disable1Act() { ... }
public Collection<Product> choices0Act() { ... }
public Product default0Act() { ... }
public int default1Act() { ... }
public String validate1Act() { ... }
public String validateAct() { ... }
} |
Notes:
- here the supporting methods would simply read from the fields of the mixin that represent the parameters of the mixin itself.
- the domain event class is still separate
Mixin and Parameters and Domain Event combined (proposed)
A further possible unification is to make the mixin also act as the domain event. I am not sure this is a good idea... my mental model is that the mixin acts as the "command", representing an intention to perform something, where as the event is a record of a fact that occurred. But maybe this is too theoretical, and actually it would make sense to combine the, If so, it would look something like:yada yada