Aop@work: Design pointcuts to avoid pattern-intensive

Availability and maintainability in "JUnit Cook ' s Tour"

Introduction: In "Junit:a Cook's Tour" article, the author Erich Gamma and Kent Beck discussed the JUnit design. They point out that, like key abstractions in many mature frameworks, TestCase also has a high pattern density, easy to use and difficult to modify. In the fourth installment of the Aop@work series, Wes Isberg the Cook's Tour, explaining how to use AOP pointcut design instead of object-oriented design to some extent to avoid the pattern-dense patterns that make mature designs difficult to modify.

Even the best Java™ programs will age over time. In order to meet new requirements, design is evolving, and key objects assume various pattern roles until they become difficult to use or difficult to modify, eventually having to refactor or rewrite the system. Aspect-oriented programming (AOP) provides a number of more elegant ways to combine features to provide services that reduce interactions, reduce workloads, and prolong the life of your design and code.

This article will analyze the design presented by Erich Gamma and Kent Beck in the article "Junit:a Cook's Tour" (see Resources). For each of the Java schemas they propose, a AspectJ alternative is given, stating whether this scenario meets the following standard design objectives:

Functional: Is the service provided powerful and useful?

Availability: Can customers easily get service?

Scalability: Is it easy to expand or adjust when a program changes?

Binding (decomposition): Can you collaborate with other parts?

Protection: How to secure the API in the face of run-time errors or cascading errors?

Understandable: is the code clear and easy to understand?

In every step of the design, both Gamma and Beck are faced with a dilemma, such as usability and maintainability, understanding and bonding. In all of these options, they take a simple, usable route, even if it means abandoning the secondary goal. As a result, their design makes it easy to write unit tests. But I still have to ask, if the use of AOP, can avoid a part of the design trade-offs?

This may not seem reasonable enough to ask, some too demanding. JUnit has done its job well, and the trade-offs in the design are understood by many developers and are considered normal practices. To see if AOP can do better, I have to ask myself some questions, such as whether I can add more features that are better suited to customers who need more services but do not meet JUnit's minimum requirements. I am not doing this to change JUnit, but to achieve primary goals without abandoning secondary design goals.

All of the examples in this article use AspectJ, but they are also available for other AOP methods, and these examples are easy to understand even if you are just touching AspectJ. (In fact, reading Cook's Tour or understanding design patterns may be more helpful than if you've used AspectJ or JUnit.) ）