Re: Boost Documentation Template questions

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 
granularity.

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 
layer/decorator.

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