Re: [Quantlib-dev] Private versus Protected

[Luigi B. <lui...@gm...>]

On 01/31/05 20:08:39, Chuck Hinman wrote:
> My question is whether there is a good reason for private scope in
> QuantLib classes.

Yes. Subclasses are not allowed to modify the private members of the base =20
class, as doing that might cause the object to be in an inconsistent state.=
 =20
Protected access would give derived classes the right to modify such =20
members besides inspecting them.

> In my specific example my financial analyst trusts nothing and always
> wants to see the intimate details of all calculations to validate correct
> operation of the classes we use from QuantLib and those classes that we
> write. We recently wrote a class to calculate the forward volatilities =20
> for caps using the CapFloor and BlackCapFloorEngine classes. Since these
> classes hide important parts in private scope I couldn=92t inherit from t=
hem
> and display their guts, so I copied the CapFloor and BlackCapFloorEngine
> classes, changed private to protected, inherited from the copies, and
> wrote subclasses with methods to save and display the caplet/floorlet
> values at each iteration and some other intimate details. Copying =20
> QuantLib classes and inheriting from them makes me feel like I am doing =20
> something foolish and shortsighted.

Depending on your compiler, adding

#define private protected

before including the relevant headers might work. But since what you =20
actually need is read-only access, there might be other ways to obtain the =
=20
same result. If the information is not too intimate--i.e., an =20
implementation detail--you might add an inspector method to the base class =
=20
returning the appropriate information; but this might not be viable for all=
 =20
the figures you need. In the next QuantLib version, you'll be able to add =20
to the base class statements such as:

QL_TRACE("caplet value =3D " << capletValue_);

Such statements would display the information in test compilations and do =20
nothing in production code. If you find them useful, we'd be happy to =20
insert them in the code base if you provide us a patch.

Later,
	Luigi