=?windows-1252?Q?Abstract_classes_=93interfaces=94_and_const_methods?=
On 5 ???, 03:22, "Thiago A." <thiago.ad...@gmail.com> wrote:
I don't have a concrete sample, but I started to think about this in
the context of remote object access (Like DCOM)
I like the interface model in this situation because doesn't matter if
you have a local or a remote object you can keep the same code.
The object pointed by the interface will refer to the recipient and
the function itself is the message.
When the object is remote the interface is talking with a proxy of the
real object like an invisible postman. Also in the server side we are
going to have another postman to translate the message and delivery to
the real object.
When the object is local we talk with the real object directly using
an interface contract.
Should the postman itself have the same contract?
Should interfaces be declared without const?
I think not necessarily. If I understand it right, the postman's
responsibility would be facilitate communication between local and
remote side and it should have generic methods like SendMessage, which
don't have anything with particular interfaces. And if postman is
completely independent of particular interface there is no need to
avoid const in that interface. Something like:
struct Interface { virtual int GetSize() const = 0; };
struct Proxy : Interface
{
Postman* postman;
virtual int GetSize() const
{
int result;
postman->SendMessageAndGetReply("GetSize", &result);
return result;
}
};
struct Postman
{
template <class ReplyType>
void SendMessageAndGetReply(char const *messageID, ReplyType* reply)
{
...
GetReplyFromCache(reply);
...
}
...
};
If the interface is declared with const, we can implement the postman
using mutable data members. He can update the delivery time for
instance, or cache something.
Such things look too common to be reimplemented for each remote
interface and if we put them into separate class there will be no more
need for mutable data members in it.
If the interface is declared without const we are penalizing final
objects and they might be or not accessed through the interface
directly.
Also, the second postman can work just as an adapter.
struct Interface { virtual int GetSize() = 0; };
struct Recipient { const int Size() const { return 1; } };
struct Postman2 : public Interface
{
Recipient * m_p;
virtual int GetSize() { return m_p->Size(); }};
Calling const function from non const object pointer is natural.
But this is not true for virtual functions.
And there is no benefit in declaring GetSize without const on this
side also, is there? And even if you need some state for the server
side postman (probably you do), it doesn't make sense to replicate
this postman for every interface as well.
I have seem more non const virtual functions. I guess the implementers
don't want to be too rigid in their contracts. (This also reminds me
exception specification contracts)
For instance, let's take a "Draw" function in a "Shape" class. It can
be const or not. Having such mutable virtual function the
implementers could decide if they prefer to implement as a const or
non const Draw. However, it would be possible to call const version
from non const (less restrictive) function.
When you implement interface method you already has a public contract
you want to obey and whether your implementation changes it's state or
not becomes implementation detail which should not be made public. If
Shape::Draw is non-const, then why in the first place you want to make
Circle::Draw const? What if somebody try to call Circle::Draw through
pointer to Circle? Will he need to cast it to Shape to make it
possible? This looks overcomplicated and I don't saw any real benefit
in it yet.
Maybe this discussion could be broken in different cases, but I am
especially curious about this context of remoting object access.
In a remoting environment should the messages take const in account?
Why not? There is nothing very special in remoting.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]