9 ms·

Maybe I'm not "getting it", but what is the difference between: After(@useCase, "askForName", => @gui.showAskForName()) vs. @useCase.askForName()

Maybe I'm not "getting it", but what is the difference between: After(@useCase, "askForName", => @gui.showAskForName()) vs. @useCase.askForName() @gui.showAskForName() ?

andrzejkrzywda 14y ago
In runtime, this is exactly the result. As code modules, those two things are separated. The usecase doesn't need to know about the gui and vice versa. In theory, they can even be reusable. We combine those two things in the glue code. Thanks to the glue code, it's the usecase which drives the other things. The usecase makes sense even without thinking about a specific GUI solution. I'm not sure where we could put the second piece of code you mention. Any suggestion?
- vidarh 14y ago
  I find it amusing that you are trying so hard to avoid naming this MVC. The "glue code" contains the code that would typically be a controller. The difference is that you do it by modifying the model and view, and that is the problem to me: You are making non-local modifications to the code, which means that while you are separating it in source, you are not keeping a separation in the running code. You make it extremely hard to reason about the system. This is already a problem in large event/notification driven systems, but this takes it to the extreme by removing the hint to look for non-local behaviour by having the equivalent to the notification imposed by an external actor. If you want to improve on a notification driven system, in my opinion you don't do that by making the extension points less obvious. And if you first are going to do that, at the very least do it in very obviously named functions, and don't modify passed in objects by make copies. But to me, those are workarounds to ameliorate a situation that's already undesirable. E.g. if you're making copies and modifying the copies and keeping those internal to the glue class you might as well go back to implementing an actual controller.
vidarh 14y ago
The difference is that After() modifies @useCase to that gui.showAskForName() always gets called after askForName on that object. Putting that kind of behaviour in a constructor in that way to me reads like a horrible anti-pattern.
- irickt 14y ago
  Please explain the anti-pattern you see and the pattern your prefer.
  - vidarh 14y ago
    A very non-obvious modification of objects that are passed in as arguments to the constructor. Looking purely at the code calling the constructor, there is no good indication that the behaviour of the objects I pass in will fundamentally change. If you are going to mutate arguments like that, I would at the very least expect naming that made it far more obvious, but much preferrable would be to not do it at all. They are implementing the observer pattern in a way that obscures the fact that notification happens in the implementation of an external class (the Glue) class, and so a consumer of the classes that are modified have no immediate reason to suspect that calling methods will trigger behaviour on other objects. In a small system you can expect people to know the whole implementation, but in a larger project, this is a recipe for surprises where people have no idea which methods have side effects because they can't read the implementations of a class itself to find out if it does. If I saw code like this in projects I manage, I'd have someone rewrite it. The are good use cases for aspect oriented programming, but they tend to involve cases where the aspect that is extracted is orthogonal to the normal operation of the object. E.g. logging.
    - andrzejkrzywda 14y ago
      You are right that there is a danger in the fact that the object being passed into the AOP advices can be changed. Usually, I'm avoiding this kind of situations. It can be terrible to debug. In our teams, we have a rule that the calls to Before/After/Around can only happen in the Glue code. Obviously, we also make sure that everyone involved is familiar with AOP and knows what is the architecture. As for the use cases for AOP, I know it's not a common practice to use it. Orthogonal concerns are the best fits, but not the only ones. There was an interesting research project at IBM, called Hyper/J. It was a little bit of inspiration for the AOP usage in the hexagonal.js architecture. Here is a good paper on Hyper/J (and the idea of Multi-Dimensional Separation of Concerns) http://helios.mm.di.uoa.gr/~anya/pms521_papers/p734-ossher.pdf http://helios.mm.di.uoa.gr/~anya/pms521_papers/p734-ossher.p... Thanks for your comment, it was very valuable.

Maybe I'm not "getting it", but what is the difference between: After(@useCase, "askForName", => @gui.showAskForName()) vs. @useCase.askForName() @gui.showAskForName() ?

andrzejkrzywda 14y ago

In runtime, this is exactly the result. As code modules, those two things are separated. The usecase doesn't need to know about the gui and vice versa. In theory, they can even be reusable. We combine those two things in the glue code. Thanks to the glue code, it's the usecase which drives the other things. The usecase makes sense even without thinking about a specific GUI solution. I'm not sure where we could put the second piece of code you mention. Any suggestion?

vidarh 14y ago
I find it amusing that you are trying so hard to avoid naming this MVC. The "glue code" contains the code that would typically be a controller. The difference is that you do it by modifying the model and view, and that is the problem to me: You are making non-local modifications to the code, which means that while you are separating it in source, you are not keeping a separation in the running code. You make it extremely hard to reason about the system. This is already a problem in large event/notification driven systems, but this takes it to the extreme by removing the hint to look for non-local behaviour by having the equivalent to the notification imposed by an external actor. If you want to improve on a notification driven system, in my opinion you don't do that by making the extension points less obvious. And if you first are going to do that, at the very least do it in very obviously named functions, and don't modify passed in objects by make copies. But to me, those are workarounds to ameliorate a situation that's already undesirable. E.g. if you're making copies and modifying the copies and keeping those internal to the glue class you might as well go back to implementing an actual controller.

vidarh 14y ago

The difference is that After() modifies @useCase to that gui.showAskForName() always gets called after askForName on that object. Putting that kind of behaviour in a constructor in that way to me reads like a horrible anti-pattern.

irickt 14y ago
Please explain the anti-pattern you see and the pattern your prefer.
- vidarh 14y ago
  A very non-obvious modification of objects that are passed in as arguments to the constructor. Looking purely at the code calling the constructor, there is no good indication that the behaviour of the objects I pass in will fundamentally change. If you are going to mutate arguments like that, I would at the very least expect naming that made it far more obvious, but much preferrable would be to not do it at all. They are implementing the observer pattern in a way that obscures the fact that notification happens in the implementation of an external class (the Glue) class, and so a consumer of the classes that are modified have no immediate reason to suspect that calling methods will trigger behaviour on other objects. In a small system you can expect people to know the whole implementation, but in a larger project, this is a recipe for surprises where people have no idea which methods have side effects because they can't read the implementations of a class itself to find out if it does. If I saw code like this in projects I manage, I'd have someone rewrite it. The are good use cases for aspect oriented programming, but they tend to involve cases where the aspect that is extracted is orthogonal to the normal operation of the object. E.g. logging.
  - andrzejkrzywda 14y ago
    You are right that there is a danger in the fact that the object being passed into the AOP advices can be changed. Usually, I'm avoiding this kind of situations. It can be terrible to debug. In our teams, we have a rule that the calls to Before/After/Around can only happen in the Glue code. Obviously, we also make sure that everyone involved is familiar with AOP and knows what is the architecture. As for the use cases for AOP, I know it's not a common practice to use it. Orthogonal concerns are the best fits, but not the only ones. There was an interesting research project at IBM, called Hyper/J. It was a little bit of inspiration for the AOP usage in the hexagonal.js architecture. Here is a good paper on Hyper/J (and the idea of Multi-Dimensional Separation of Concerns) http://helios.mm.di.uoa.gr/~anya/pms521_papers/p734-ossher.pdf http://helios.mm.di.uoa.gr/~anya/pms521_papers/p734-ossher.p... Thanks for your comment, it was very valuable.