What is the right pattern?

Question

What is the correct way to resolve:

Class A {

methodDoSomeOperation() {

  ClassB b.someOperation(.....);
....

 }


ClassB {

someOperation(....) {


 if (this.someCondition) then{
   ClassC c.anotherOperation(....)
  } else {
 ClassD d....
 }
}

 }

Methods c.anotherOperation takes a long time. I would like receive notification regarding what was selected: c.anotherOperation(....) or d..... for display in a user interface before invoking c.anotherOperation .

Something like:

someOperation(....) {


if (this.someCondition) then{
 //notify ClassA what was selected and continue
 ClassC c.anotherOperation(....)
 } else {
 ClassD d....
 }
}

Obviously it is possible to invoke some method in ClassA but this creates strong coupling and confusing logic. Is it possible use some features of Spring?

Answer 1

Could it be that your looking for a Decorator Pattern ? This would apply if each class added/aggregated their part.

Or even a Chain of Responsibility ? This may be more applicable since each class would optionally do their processing. Assuming Classes A, B, and C are Processing objects, they would have logic defining what sorts of operations they would work on, thus optionally performing their particular processing, and then passing on to the next processing object. Considering that you seem to be chaining A, B, and C together, each performing their part, this appears to apply best to your description. Then to get an indication of which Processing objects did their part, you could define a Context and pass it along the chain, and each Object would fill in their part.

Answer 2

Would you consider some form of the Observer pattern? Whatever the class that is closer to the UI(May be class A?) can be registered as an observer to the Class B. this can be done upfront or as part of the call to the B.SomeOperation() by adding a parameter. Then when you do the check B.someCondition, you can call the registered observer an then call the long running operation on C.

Answer 3

Do you want to give the user the opportunity to cancel c.anotherOperation() before it starts? If so then someOperation() doesn't actually call it. Instead it causes an ok/cancel dialog to be displayed, and the ok choice is treated by the UI as a command that leads to c.anotherOperation(). (Maybe by way of ClassA and ClassB again, depending on what their responsibilities are.)