Boost logo

Boost :

From: vesa_karvonen (vesa_karvonen_at_[hidden])
Date: 2002-02-12 17:01:48

--- In boost_at_y..., Persson Jonas <Jonas.Persson_at_s...> wrote:
> A simpler solution to that problem would be:
> struct interface {
> return_type method(param_type param) {
> pre(param);
> return_type ret=method_impl();
> post(ret);
> return ret;
> }
> protected:
> virtual return_type method(param_type param) = 0;
> };

Yes, and I've used the above technique earlier. It can be handy if
you just want to make sure that all implementations check the
contracts always and you are the designer of the interface.

The main problem with it is that it makes it more difficult to choose
which implementations check contracts. Depending on your performance
requirements, this can be either an insignificant detail, or a source
of much grief. The decorator/layer approach makes it possible to
enable or disable contract checking either on object or class level

Another problem is that two method()s are now required: method() and
method_impl(). This creates problems for programmers who do not care
about contracts, but want to subclass the interface. More
documentation may be needed for those "casual users".

The above technique also requires modifying an existing interface
when contract support is added later. This may not always be possible
or desirable.

The above technique also means that clients of the interface must now
include (in their translation units) slightly more code, because the
declarations of the contract checking functions must be present. In
other words, both the method() and method_impl() functions must be
declared in a translation unit that uses the interface. Using the
decorator/layer approach, only the (pure) interface method() needs to
be in a translation unit that merely uses the interface.

> That would also allow subclasses to refine the conditions:
> struct subclass : interface {
> return_type method(param_type param) {
> looser_pre(param);
> return_type ret=interface::method_impl(param);
> stricter_post(ret);
> return ret;
> }
> };

The same effect can be achieved by subclassing the contract

BTW, contract decorators can easily be implemented from an ordinary
forwarding decorator by using the contract layer.

Boost list run by bdawes at, gregod at, cpdaniel at, john at