3 ms·

Please explain the anti-pattern you see and the pattern your prefer.

by irickt 14y ago

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.

Please explain the anti-pattern you see and the pattern your prefer.

by irickt 14y ago

Please explain the anti-pattern you see and the pattern your prefer.

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.