Jetzt ergibt sich also das Problem, das im alten Oberflächencode die alte Stringklasse verwendet wird und bei einem Aufruf der Businesslogic diese aber die neue Klasse erwartet.

Nun sind wir auf der Suche nach einer Möglichkeit, einen Operator zur Verfügung zu stellen, die diese Konvertierung automatisch durchführt.

Noch zur Veranschaulichung hier das ganze in Codeform:

class OldString
{..
};

class NewString
{..
};

// Umgestellte Businesslogic
class MyObject
{
...
void SetName (const NewString& name);
...
};

// Alter Oberflächencode
class MyGui
{
...
void ChangeName();
};

void MyGui::ChangeName()
{
OldString name = ReadName(...)

MyObject ob;

// OldString wird übergeben, NewString wird aber erwartet
ob.SetName (name);
}

Das Ziel ist, dass der alte Oberflächecode ohne eine Änderung weiterhin funktioniert.
Natürlich gäbe es theoretisch die Möglichkeit, in NewString einen Konstruktor zur Verfügung zu stellen, der OldString erwartet - dies geht aber nicht, da es keine selbstgeschriebene Klasse ist (sonst wärs ja zu einfach ;)).

Hat hier vielleicht jemand eine Idee?

//a: in der Zielklasse:
class src;

class tgt
{
public:
  tgt(const src& obj);//Umwandlung per Ctor
};

//b: in der Quellklasse
class tgt;

class src
{
public:
  operator tgt();//Umwandlung per Cast-Operator
};

//c: explizite Umwandlung
class src;
class tgt;

tgt as_tgt(const src& obj);//explizite Umwandlung

Beispiel:

class StringWrapper
{
    NewString localString_;

public:
    StringWrapper(const OldStrong& rhs)
    : localString_(rhs.c_string)
    { }

    //Funktionen die gebraucht werden und delegiert werden sollen
    std::size_t inline size() const
    {
        return localString.size();
    }
};

Sowas in der Richtung.

PS: "Konvertierung" :p

Da haben wir gleich zwei Lösungsansätze zu überlegen

*g* "Konversion" -- tja das passiert, wenn man einfach von Englisch auf Deutsch "konvertiert"