Re: Something like a final method
Alf P. Steinbach wrote:
Note that James' code is essentially the same as blaarg's.
And what it means that
o.getStatus()
may perform a virtual or a non-virtual call depending on the type of 'o'.
The code I presented does not suffer from that problem.
I dont't see any problem here.
And as noted above (not the case with the code I presented) it means that
2a. one can not see by local inspection of call whether a call is
non-virtual
or not, and worse,
Well, using an interface all calls are virtual, of course.
2b. if you have the wrong static type for an object, e.g.
AbstractBase& where the dynamic type is DerivedWithCustomStatus,
then a
cast is needed to get the correct virtual call.
No. The method is never overridden except for the interface
implementation. Otherwise I would not have asked for 'final'.
Finally, (not the case with the code I presented)
3. by adding the status implementation directly in AbstractBase that
implementation is forced as baggage on derived classes using another
implementation,
This is intended. Status is part of the services of AbstractBase.
In fact the two interface implementations (and their derived classes)
are something like the envelopes and letters as you mentioned. Any
envelope has a immutable strong reference to a letter and adds some
features around an abstract letter. But the envelope is also allowed to
override a few properties of the letter, including the status for
visualization (now this is a proxy pattern). Previously these classes
were used in distinct code locations and did not have any common
interface (except for the one used for intrusive reference counting).
Now I have code locations that do not need to know whether they
currently use the proxy (and envelope) or the object itself. This is
another kind of usage that only addresses the proxy pattern and needs a
common interface. But exactly the same functions are used inside the
letter's class tree widely, and now they became non-inline.
Marcel