Spring Practice Chapter 5

Front 1

What is a crosscutting concern?

Back 1

A crosscutting concern is a functionality that spans multiple modules of an application.

eg. logging, authentication

Front 2

What is a core concern?

Back 2

core business requirements

Front 3

What are the two main problems caused by non-modularised crosscutting concerns?

Back 3

1) code tangling. Having to handle multiple concerns as well as the core calculation logic at the same time. This will lead to poor code maintainability and reusability.

2) Code Scattering. Repeat the same statements (i.e. logging) multiple times in multiple modules to fulfill a single requirement. Later, if the logging criteria change, you would have to modify all of the modules. Moreover, it is also hard to ensure that the logging requirement
will be implemented consistently. If you have missed a logging statement somewhere,
the overall system logging will be inconsistent.

Front 4

What design pattern can you use to assist with implementing crosscutting concerns?

Back 4

You can apply a design pattern called proxy to separate crosscutting concerns from core concerns.
Proxy is one of the 23 GoF (Gang of Four) object-oriented design patterns, which belong
to the “structural pattern” category.
The principle of the proxy design pattern is to wrap an object with a proxy and use this
proxy to substitute for the original object. Any calls that were made to the original object will
go through the proxy first.

Front 5

What is a dynamic proxy?

Back 5

It supports creating a proxy dynamically for any object.

Dynamic proxies are implemented with the Java Reflection API, so they can be used in a
more general way than static proxies. For this reason, dynamic proxy is one of the core technologies
used by Spring for its AOP implementation.

Front 6

What is an advice?

Back 6

The crosscutting action to take at a particular execution point is
encapsulated in an advice

Front 7

What types of advices does Classic Spring AOP support?

Back 7

1) Before Advice (before method execution)

2) After returning advice (After the method returns a result)

3) After throwing advice (After the method throws an exception)

4) Around advice (Around the method execution)

Front 8

How are advices written using the classic Spring AOP approach?

Back 8

Advices are written by implementing one of the proprietary advice interfaces

Front 9

In classic Spring AOP, what interface do you implement to use before advice?

Back 9

MethodBeforeAdvice

Front 10

What interface do you need to implement for after returning advice?

Back 10

AfterReturningAdvice

Front 11

What interface do you need to implement to handle throwing advice?

Back 11

ThrowsAdvice