Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/a-simple-question-tp9462p9464.html
Bonjour François,
sorry for the delay. Here we go:
On May 18, 2007, at 5:41 PM, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD
PHI wrote:
>> In this case, isValid_ should be protected and derived classes would
>> have to manage it.
>
> I agree with you, we could also leave it as it is and provide a
> protected function setQuote() which would set isValid_ to true.
>
>> Using optional wouldn't be so tricky: we could just write SimpleQuote
>> as >(without namespace boost)
>
> I agree again, provided that you add a resetQuote() method to your
> class, then the use of optional would be transparent to the user.
resetQuote() might not be necessary, as we can declare setQuote as
setQuote(optional<Real>). With this declaration,
q.setQuote(42);
would automatically package the Real in the optional, while
q.setQuote(none);
would make q a null quote.
> Still, I have two remaining arguments:
> ->You have to reimplement this machinery in every quote classe.
> ->What would be the added benefit compare to a more traditionnal
> solution ? (like mine)
>
> I know that you will destroy these arguments in a couple of seconds,
> but it is instructive to understand one's error anyway
Well, it's not an error. I just think it's a less than optimal solution
:)
As for your arguments:
1) your solution actually leads to more machinery. Among the quotes we
currently have, only SimpleQuote manages the value directly, so to
speak. For the other quotes, isValid() is implemented, for instance,
like this:
bool ImpliedStdDevQuote::isValid() const {
return !price_.empty() && !forward_.empty() &&
price_->isValid() && forward_->isValid();
}
In your approach, the above becomes:
bool ImpliedStdDevQuote::isValid() const {
isValid_ = !price_.empty() && !forward_.empty() &&
price_->isValid() && forward_->isValid();
return isValid_;
}
i.e., management of the isValid_ data member (directly or via some
method) is forced upon the programmer, which can no longer implement
the interface by just writing the logic (as he does now) but instead
has to worry about the particular implementation of the base class. (*)
2) The added benefit comes from the above. No, let me rephrase this:
the added benefit is the fact that in the current approach, Quote is a
pure interface; the above is a consequence. In your approach, you're
making Quote a somewhat less abstract base class, which is seldom a
benefit. Moreover, you're modeling it after SimpleQuote, which is just
a particular case.
Later,
Luigi
(*) This is the same issue I had with storing a dayCounter_ data member
in TermStructure itself. On the one hand, we saved having to declare it
in quite a few derived classes, but on the other hand we're left with
classes such as ImpliedTermStructure, which leaves it uninitialized.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev