Spring AOP and Design by Contract

[JVelilla]

There are plans to give support to DBC(style-Eiffel) in Spring AOP.

Thanks Javier

[Cybernet Sauvignon]

I don't know, are you asking or you want to inform us about a new feature which is planned?

Do you mean pre-, post-conditions and invariants?
It can be very nice to have something like that.

I don't know whethere this is the right place to discuss new features and their's design but here my opinion:

The code doing pre-,post-conditions can be just ordinary methods. We must somehow mark the DBC methods which should be called before, after each other non-DBC method.
We can borrow the method, how to specify them, from Spring's Tx manager.
Because the DBC is highly implementation specific and I suppose the info should be as near to code as possible, I prefer using meta info (attributes) and use AutoProxying to automagically wrap the specified beans in DBC wrappers.

Sample code:

public class SimplePojo {
	public void doSomething() {
		...
	}

	/** @@postcondition */
	public void callMeBefore() {
		if (/*something goes wrong*/)
			throw new DBCException(...);
	}

	/** @@invariant */
	public void checkInvariant() {
		...
	}
}


AppCTX:

<beans>
	<bean id="autoproxy" class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
	</bean>
    <bean id="attributes" class="org.springframework.metadata.commons.CommonsAttributes">
    </bean>
    <bean id="DBCAdvisor" class="org.springframework.dbc.interceptor.DBCAttributeSourceAdvisor">
	</bean>

Note the DBCAdvisor.

Is someone worknig on it?

CS

[Rod Johnson]

We don't have any plans for now, but it would be a good feature. The idea of using ordinary methods makes sense. Alternatively, a fancier implementation could interpret Strings using Groovy, bsh or the like: e.g.

assert someField != null

where the strings are expressions about the target object.

Jon Tirsen did some cool DBC stuff for Nanning ages ago, but I suspect that they were proprietary to his then employer and he never open sourced it.

This seems like a perfect candidate for someone to contribute (hint, hint)...

[JVelilla]

The code doing pre-,post-conditions can be just ordinary methods. We must somehow mark the DBC methods which should be called before, after each other non-DBC method.
We can borrow the method, how to specify them, from Spring's Tx manager.
Because the DBC is highly implementation specific and I suppose the info should be as near to code as possible, I prefer using meta info (attributes) and use AutoProxying to automagically wrap the specified beans in DBC wrappers.

how to implement this properly with inheritance againts the Liskov Substitution Principle
i.e precondition implement contravariance (weaker )
i.e postcondition implement covariance (stronger)

[Cybernet Sauvignon]

Well,

this is just a contract specification (and it does not allow to specify the contract for an interface). I can imagine another form, e.g. whole contract defined using metainfo (this appear much better to me now .
But all these does not prescribe how to implement the contract enforcement. This is probably good candidate for a strategy (configurable).
One of this strategies is quite good described in http://jcontractor.sourceforge.net/ (see section "What about contracts and inheritance?")

What do you think about it?

CS