2010-04-07 24 views
5

No encontré un mejor título para la pregunta. Permítanme explicarlo mejor ahora:¿Cómo anular los métodos anidados de objetos C++?

El proyecto en el que estoy trabajando se va a conectar a un servidor remoto, cifrar la sesión y enviar/recibir paquetes de datos. Me gustaría que sea lo suficientemente modular, así que pensé que sería bueno usar 3 clases distintas. Estos serían:

1) Una clase contenedora de socket con algunos métodos virtuales como OnReceivedData() y OnConnected().

2) Una clase heredada del contenedor de socket, implementando el cifrado de los datos antes de su envío y descifrando los datos a su llegada.

3) El objeto principal en sí mismo, que debe anular cualquiera de las clases anteriores dependiendo de su necesidad de ser encriptado o no, por lo que podría recibir la notificación de eventos OnReceivedData() y OnConnected() y actuar en función de eso.

Así que el problema es ¿CÓMO hago que mi programa sepa que primero tiene que llamar al evento en el objeto de cifrado y luego llamar al mismo evento en el objeto principal? Porque supongo que si anulo el engarce socket con el cifrado y luego anulo el cifrado con el objeto principal, probablemente solo llame al método del objeto principal (llamaría a OnReceivedData() directamente en el objeto principal, no pasaría por el descifrado objeto primero, ¿verdad?).

¿Esto se llama herencia múltiple?

Por cierto, si usted piensa que es un mal diseño del proyecto, agradecería cualquier mejor enfoque. Gracias por tomarse su tiempo para leer esto.

+0

Mi sugerencia, intente utilizar patrones de diseño, como un patrón 'Builder' o' Factory'. –

Respuesta

2

No se llama herencia múltiple (esto es cuando una clase hereda de varias súper clases). Se llama anulación de método. En su 'On' OnReceivedData, puede llamar explícitamente al 'super' método calificando su nombre, EncryptedBaseClass::OnReceivedData().

Esto puede ser complicado. Lo que recomendaría es que invierta la propiedad y deje que la clase de encriptación contenga una referencia a la clase de socket, en línea con el decorator pattern (Tener un decorador de encriptación). Esto resolverá los problemas de anulación al tiempo que le proporciona la funcionalidad que busca.

4

No convierta el objeto de cifrado en un descendiente. Conviértalo en decorador o proxy. El objeto principal no debería necesitar saber si está encriptando cosas. En cambio, tendrá un objeto de transferencia de datos (la clase de socket) que envía y recibe datos, y si ese objeto de transferencia de datos pasa a ser algo que encripta los datos antes de pasarlos al objeto de socket real, que así sea. Eso no es una preocupación del objeto principal.

Con un proxy, la clase de encriptación tendría la misma interfaz que el objeto de socket. Sería wrap el objeto socket, y el objeto principal hablaría con el socket a través del objeto de cifrado. Si no quiere el cifrado, asigne el objeto socket al objeto principal directamente y omita el intermediario.

Con un decorador, el objeto principal hablaría directamente con el objeto de socket, pero el objeto de socket ejecutaría todo a través del objeto de cifrado antes de enviarlo a lo largo del cable. Si no hay decorador configurado, entonces el objeto de socket enviaría los datos directamente en su lugar.

Los decoradores y los proxies están cubiertos por los patrones de diseño de Fowler, que incluyen ejemplos en C++.

Cuestiones relacionadas