Estoy tratando de configurar un azúcar sintáctico similar al concepto de propiedad C#.C++ derive pure abstract w/estructura anidada
He leído esta publicación: C#-like properties in native c++?. Es útil, pero carece del diseño que quiero. También estoy respetuosamente en desacuerdo con varias de las afirmaciones hechas allí de que el concepto de propiedad es malo oo, ya que no veo la diferencia entre un conjunto de métodos titulados get_id() y set_id() y una sobrecarga del operador que expone el mismo concepto, permite que el código esté más limpio cuando se consume la clase, y generalmente desalienta el acceso público a los campos privados, también desacopla la implementación pública del diseño privado.
Sin embargo, el código que he ideado (inspirado por ese enlace) es REALMENTE kludgy y será bastante difícil de mantener. Me pregunto si alguien tiene alguna sugerencia para aclarar esto o, lo que es más importante, sabe una mejor manera de hacerlo.
class someClass
{
public:
struct someProperty_struct{
virtual someProperty_struct& operator=(const int&){return *this;}
virtual operator int(){return 0;}
}someProperty;
};
class derivedClass : someClass
{
int i;
public:
struct intProperty: someClass::someProperty_struct
{
protected:
friend class derivedClass;
derivedClass *outer;
public:
virtual someProperty_struct& operator=(const int& value){
outer->i = value;
return *this;}
virtual operator int(){return outer->i;}
};
derivedClass()
{
intProperty p = intProperty();
p.outer = this;
someProperty = p;
}
};
class consumerClass
{
public:
someClass* data;
consumerClass()
{
data = (someClass*)(new derivedClass());
}
void doSomething()
{
data->someProperty = 7;
int x = data->someProperty;
}
};
EDIT 1: Se me ocurre que no revela nada acerca de mis intenciones con este. Se usará en un programa de programación, y vamos a hacer una gran cantidad de comparación y asignación de todos los datos en las clases. 'someClass' será efectivamente una interfaz sobre los datos (se necesitan muy pocos métodos, muchos datos que deberían ser relativamente transparentes). Se definirá en una biblioteca estática a la que se vinculará el ejecutable. 'derivedClass' será efectivamente una implementación externa, implementada en un DLL que se cargará dinámicamente. La razón para esto es habilitar el "intercambio en caliente" del dll con otro que implementa un backend de archivo diferente. Tenemos planes para implementar backends de almacenamiento xml, sqlite y mysql usando un sistema de complemento para cargarlos.
Básicamente, necesito un diseño que permita que someClass sea una interfaz virtual heredada por derivedClass, que se carga por el método de fábrica, se pasa a través del sistema de complementos y al final usa consumerClass.
Así, después de mucha reflexión, he encontrado el problema: que no has dicho lo que carece de la solución propuesta: en su caso, carece de una forma de especificar un captador costumbre y un regulador de encargo . –
¿Te refieres a mi solución propuesta, o la que está en el enlace al que se hace referencia? El punto de esto es que someClass será virtualmente puro virtual, que luego será derivado e implementado por alguna otra biblioteca, de ahí la necesidad de pura virtualidad y herencia. El getter y setter proporcionado en intProperty en mi implementación es personalizado, y se puede manipular según sea necesario para proporcionar todo tipo de herramientas útiles (en mi caso, planeo usarlo para la carga diferida desde un archivo xml) – lassombra
OK, entonces Entendiste mal. Me preguntaba por qué no usaste la solución de plantilla simple propuesta en la pregunta que mencionaste. Lo que necesita es una propiedad como parte de una interfaz. Eso no es lo que estaba tratando de hacer. Veré si tengo una idea. –