What are Crosscuting contracts? What is the relationship with Design by contract?

Design by contract (DbC) is an approach to design (ie, preconditions, post-conditions and invariant) between clients and suppliers.

Languages like Eiffel (created by Professor Bertrand Meyer , who also coined the term DbC) have native support to DbC. In Eiffel we can specify contracts for routines and classes by clauses like require , ensure and invariant (for more information see Eiffel Software: Building bug-free OO software: An Introduction to Design by Contract ™ ). In languages such as Java, native support is limited to assertions .

Techniques of Programming oriented to aspects (AOP) aim to decouple crosscuting concerns (cross-features) of the main functionality of the system. For example, application aspects such as logging, transactional control, and security can be modulated with AOP, thus reducing the code breakdown needed to ensure these features through the application.

There are several libraries that try to emulate the notion of contracts through AOP, for example, the OVal tries to emulate contracts in Java through AspectJ .

In academic circles there are open discussions on the nature of contracts. One of them concerns crosscuting contracts , ie contracts that encompass multiple methods / classes. There is of course an intersection between AOP and DbC.

Several respected authors acknowledge the existence of crosscuting contracts . This is one of the lines of research, for example, of Professor Henrique Rebêlo that created the tool AspectJML for crosscuting contracts specification.

Crosscuting contracts allow, in theory, greater reuse of code. That said, there are controversies about the suitability of aspects for the implementation of DbC. For example, this 2005 publication co-authored by Meyer puts the marriage between DbC and AOP in check . In turn, this 2014 publication (whose first author is Rebelo), tries to reconcile trade-offs between languages with native support to DbC and AOP.