views:

58

answers:

2

Hi all, I didn't figure out a better title for the question. Let me explain it better now:

The project I am working on is going to connect to a remote server, encrypt the session and send/receive data packets. I'd like to make it modular enough, so I thought it'd be nice to use 3 distinct classes. These would be:

1) A socket wrapper class with some virtual methods such as OnReceivedData() and OnConnected().

2) An inherited class of the socket wrapper, implementing the encryption of data before it is sent and decrypting data on its arrival.

3) The main object itself, which should override any one of the above classes depending upon its need to be encrypted or not, so it could receive the OnReceivedData() and OnConnected() events notification as well and act based upon it.

So the problem is HOW do I make my program to know it has to first call the event on the encryption object and then call that same event on the main object? Because I guess if I override the socket wraper with the encryption and then override the encryption with the main object, it will probably just call the main object method (it would call the OnReceivedData() directly on the main object, not passing through the decryption object first, right?).

Is this called multiple inheritance?

BTW if you think it is a bad project design, I would appreciate any better approaches. Thank you for taking your time to read this.

+2  A: 

It is not called multiple inheritance (this is when one class inherits from multiple super classes). It is called method overriding. In your 'main' OnReceivedData, you can explicitly call the 'super' method by qualifying its name, EncryptedBaseClass::OnReceivedData().

This can become messy. What I would recommend is that you invert the ownership and let the encryption class hold a reference to the socket class, in line with the decorator pattern (Having an encryption decorator). This will resolve your override problems while still provide you with the functionality that you seek.

disown
+4  A: 

Don't make the encryption object a descendant. Make it a decorator or proxy. The main object shouldn't need to know whether it's encrypting things. Instead, it will have a data-transfer object (the socket class) that sends and receives data, and if that data-transfer object happens to be something that encrypts the data before passing it along to the real socket object, so be it. That's no concern of the main object.

With a proxy, the encryption class would have the same interface as the socket object. It would wrap the socket object, and the main object would talk to the socket through the encryption object. If you don't want encryption, then assign the socket object to the main object directly and skip the middle-man.

With a decorator, the main object would talk directly to the socket object, but the socket object would run everything through the encryption object before sending it along the wire. If there is no decorator set, then the socket object would send the data directly instead.

Decorators and proxies are covered in Fowler's Design Patterns, which includes examples in C++.

Rob Kennedy