Enhancing contracts with AOP: Adding contract design to Java software development with ASPECTJ

Introduction: When Developing enterprise software, Java code often needs to interact with external components. Regardless of whether an application must communicate with a legacy application, an external system, or a third-party library, using an uncontrollable component introduces the risk of unintended results. IBM's IT expert Filippo Diotalevi shows how aspect-oriented programming (AOP) reduces this risk by helping you design and define explicit contracts between components while keeping your code clean and flexible.

Contract design (designed by Contract) (DBC) is a technology in object-oriented software design, which aims to ensure software quality, reliability and reusability. The key consideration in DBC is that this can be achieved through the following approaches:

Specify the communication between components as accurately as possible.

Define the mutual responsibility and expected results in the communication process.

These reciprocal responsibilities are called contracts, and assertions are used to check whether the application satisfies the contract. Simply put, an assertion is a Boolean expression that is inserted into a particular point in the execution of a program, and it must be true. A failed assertion is usually a symptom of a software bug, so it must be reported to the consumer.

DBC is especially useful when dealing with external components or libraries and the need to ensure that the data that the application passes to them and the data received from them is correct. This article presents an abstraction of the infrastructure and an example application that uses aspect-oriented programming (AOP) to implement DBC, which contracts with external components.

Assertions and the Java language

DBC recognizes three basic types of assertions:

Preconditions: The responsibility that a customer must meet in order to properly invoke an external component.

Post condition: The expected result after the external component is executed.

Invariants: Conditions that remain unchanged after an external component has been executed.

The Java language did not originally provide natural support for assertions. The Assert statement is added in version 1.4. However, using DBC in everyday coding can be a challenge. In fact, most of the commonly used methods-adding forward and post assertions directly in the application code-have serious drawbacks in the modularity and reusability of the code. This approach is a vivid example of entangled code: It mixes business logic code with the Non-functional code required for assertions. This code is inflexible because it is not possible to change or delete assertions without changing the application code.

The ideal solution for this problem is to meet four requirements:

Transparency: Pre and post condition codes are not mixed with business logic.

reusability: Most parts of a solution can be reused.

Flexibility: The assertion module can be added, deleted, and modified in a simple way.

Simplicity: You can specify assertions in simple syntax.