Niclas Hedhman wrote: > And we have the 'answer' to the "Getters are Evil!" debate that has > been brought up the last couple of years.
Correct! Getters/setters are fine, BUT only as the internal contract. This is where private mixins, with properties/associations, are the key I think. >> No, you are right. Destination and itinerary are internal. You would >> have something like CargoRole#changeDestination() -> >> Cargo#destination.set(), where Cargo is a private mixin. > > So, in practical terms; We should view the Context from a behavioural > model, where we effectively use Composite interfaces with backing > NoopMixin and the 'map' to internal state happening in Concerns?? Well, you can back them with real mixins, that's fine, but they don't have any state. The state is entirely defined by the internal contract, i.e. private mixins. >>> Use case 3: >>> Cargo#deliveryHistory() >>> In ddd sample, DeliveryHistory is a place holder for cargo events. >>> No database table is representing DeliveryHistory and >>> Delivery history is immutable. >> Sounds like a Query to me! > > Not necessary. Having an EventHistory for an object can make sense, > without being query or queryable. Depends on what the use-cases really > are. In this case, I think it is used to pull up the "path to > customer" view (like UPS/FedEx has as the default view for a > TrackingNumber), and no reason to have that being assembled by a > relatively expensive Query. True. The cool thing about our Query API is that we can do it either way. Either implement it as a Query with a where-clause that describes what events to include, or do it as a ListAssociation which is then exposed by wrapping it in a Query->iterable. For the user it is all the same. If the EventHistory contains thousands of entries you want the query-version, or if it is short then an internal ListAssociation is probably a better choice. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
