design problem: event extraction function

[nt4u]

Hi,

I am currently working on assignment 5 (I know I'm a bit late, but anyways...) and I have no idea where to put responsibilty for the event extraction function. My design is (partially) the following:
The classes Skip, Assign, FunctionCall extend the class Statement and BooleanExp is a class independent of that. So I can't have a "superclass" where I could put some responsibilty for the event extraction function - also this wouldn't make sense, since Sequence/If/While are Statements that do not use the event extraction.

The event extraction function needs to know which concrete event is present, to decide which abstract events result. So how to design this in Java nicely? When I think about a "computeEventList()" method in Skip/Assign/FunctionCall/BooleanExp, it has to contain a "switch" statement to decide which rule is considered 4 times, which is rather ugly. Another possibilty would be an EventExtractor class, which has subclasses that implement a specialized function for each rule. But inside this EventExtractor I would have to check the type dynamically, to decide what concrete event is present, which I also find is not a nice design.

Do you understand my problem? How did you solve this? (I hope this question is abstract enough to discuss, without talking about the solution to the event extraction function itself)

[DanielSchoepe]

Another possibilty would be an EventExtractor class, which has subclasses that implement a specialized function for each rule. But inside this EventExtractor I would have to check the type dynamically, to decide what concrete event is present, which I also find is not a nice design.

That's how I solved it. Generally, I think that there's no solution for representing "sum types" (such as the one for the various alternatives for statements or expressions) in Java that's even remotely as nice as algebraic data types in ML-like languages. One either has to introduce a lot of superfluous complexity via design patterns including all the boilerplate they usually need, or use nested ifs that check the type dynamically with instanceof. There's no obvious winner here, in my opinion, although my dislike for design patterns may be somewhat uncommon. If you don't share that dislike, I think this issue can be handled by the Visitor pattern though.

For this reason I stopped to care that much about the structural elegance of my code, since I think that many of the concepts we discussed cannot be implemented very nicely in Java anyway. (Being allowed to use some ML- or Lisp-like language would have made this a lot nicer, but I suppose regretting this does nothing except making the whole thing more painful ).