How would you design this in a way that prevents doing that from the users of the library?
Interface de textura separada da implementação:
class API_DLL ObjectTag
{
uuid mUUID;
public:
uuid getUUID()
{
return mUUID;
}
};
class API_DLL Texture: public ObjectTag // Texture interface visible in client code
{
public:
virtual ~Texture() = 0;
virtual void DoTextureThings() = 0;
};
template<typename T>
class EditableObjectTag: public T // EditableObjectTag not exposed to client code
// defines save functionality
{
public:
void setUUID(uuid id) { mUUID = id; }
};
class YourTexture: public EditableObjectTag<Texture> // YourTexture not exposed
// to client code
{
void DoTextureThings() override { ... }
};
Sua função de carga:
API_DLL std::vector<std::unique_ptr<Texture>> LoadTextures()
{
std::vector<std::unique_ptr<Texture>> result;
result.emplace_back(new YourTexture{ bla, bla, bla });
return result;
}
O código do cliente agora pode trabalhar com texturas, sem se importar que uma textura seja uma classe abstrata, e a interface Texture não menciona nada sobre a configuração de valores no objeto:
void ClientCode()
{
auto textures = LoadTextures();
textures[0]->DoTextureThings();
// textures[0]->setUUID(someUUID); -> fails to compile
}
Nota : a classe EditableObjectTag é um design baseado em aspectos: adiciona uma interface editável no seu argumento de modelo.