public BusinessSummary buildSummaryObject() {
BusinessSummary businessSummary = new BusinessSummary();
for(BusinessObject businessObject : businessObjects) {
State state = businessObject.getState();
businessSummary.incrementState(state);
}
return businessSummary;
}

or:

public BusinessSummary buildSummaryObject() {
BusinessSummary businessSummary = new BusinessSummary();
for(BusinessObject businessObject : businessObjects) {
businessSummary.add(businessObject);
}
return businessSummary;
}

maybe even:

public BusinessSummary buildSummaryObject() {
BusinessSummary businessSummary = new BusinessSummary();
businessSummary.add(businessObjects);
}

Consider this is similar to @Moandji approach, but isn’t a chatty comm i.e.

BusinessSummary.add(List objs) {
for(BusinessObject businessObject : objs){
businessObject.writeTo(businessSummary); // tell bo to write to self, so then bo tells self to increment … instead of just telling self to increment based on businessObject.getState()
}
}

For me its the business summary that should we caring about what information we are using for the summary, so I don’t see why BusinessObject needs to be tied back to BusinessSummary.

Then, your interaction is more like the two classes passing requests and bits of information back-and-forth and BusinessSummary’s API is less coupled to the various State instances. (excuse the short-hand pseudo-code below)

BusinessSummary.add(List objs) {
for(BusinessObject businessObject : objs){
businessObject.writeTo(businessSummary); }
}

BusinessObject.writeTo(BusinessSummary bs) {
bs.increment(this.state);
}

BusinessSummary.increment(State state) {
if (State.State1 == state) {etc…
}

I think the advantage here is that all the BusinessSummary really knows how to do is increment its State counter. All the rest is convenience methods.

ciao
jens

BTW: Your blog, your tactical insights are very inspiring!