3. Klassenbezeichnungen Versionsnummern vergeben

Klassenbezeichnungen Versionsnummern vergeben

  • C

    Du könntest die Klassen auch so lassen und jede Version in ihren eigenen Namespace verschieben.

    using namespace MyClassVersion_120_1_BETA
    0
  • S

    Die Idee ist wirklich furchtbar. Für Versionskontrolle gibt es CVS, SVN, VSS,...

    Man kommt in Teufelsküche wenn man Ableitung ohne Ist-Ein Beziehung macht.

    0
  • U

    tfa schrieb:

    endline schrieb:

    TravisG schrieb:

    abgesehen davon finde ich es irgendwie hässlich, sprachfeatures zur projektverwaltung zu verwenden.

    Nicht wirklich.

    Wirklich sehr hässlich.
    Warum benutzt du kein VCS wie CVS oder Subversion?

    sein 'trick' hat aber den vorteil, dass man in einem programm alle versionen der klassen benutzen kann. ist vielleicht manchmal ganz nützlich...
    🙂

    0
  • ?

    ich versteh das trotzdem noch nicht. so lange ich hier grade überlege, so fällt mir bei gescheitem namensdesign kein fall ein, bei dem man nach änderungen (änderungen bedeuten ja normalerweise, dass man zusätzliche features braucht oder alte abgeändert werden müssen) den namen ändern müsste.

    darf ich um ein beispiel bitten?

    0
  • A

    Ich bin ratlos, wie deine Klassenversionierung dem OCP dient. Das Visitor- und das Dekorator-Pattern koennen dir helfen ein Design das dem OCP folgt zu entwerfen, deine Versionierung nur bedingt. Sollen die versionierten Klassen dieslbe Klassifizierung sein oder doch eine echte Generalisierung? In beiden Faellen halte ich das was Du tust fuer nicht richtig. Wenn sie dieselbe Klassifizierung darstellen, dann sollten sie auch austauschbar sein, also von einander nicht unterscheidbar. Das sind sie aber. Im Falle einer echten Generalisierung verdient die neue Klasse auch einen eigenen Namen weil sich ihre Zustaendigkeit von der der Basisklasse unterscheidet.

    0
  • E

    TravisG schrieb:

    ich versteh das trotzdem noch nicht. so lange ich hier grade überlege, so fällt mir bei gescheitem namensdesign kein fall ein, bei dem man nach änderungen (änderungen bedeuten ja normalerweise, dass man zusätzliche features braucht oder alte abgeändert werden müssen) den namen ändern müsste.

    Ich bin gegen Aenderungen, aber fuer Erweiterungen. Das ist ja das Wesen des Opne-Closed Prinzips.

    Beispiel: Eine Klasse, die eine Xml-Konfiguration laden soll...

    //Hier kommt die Beschreibung der Klasse hin
//Laed folgendes:
// - einen Connection-String zu einer Datenbank
// - eine Tabellendefinition (um speaeter eine neue 
//   Tabelle in der Datenbank zu erzeugen)
class XmlConfigParserV1
{
public:
    virtual string parseConnectionString()=0;
    virtual TableDefinition parseTableDefinition()=0;
};

// Kann noch mehr laden..
class XmlConfigLoaderV2 : public XmlConfigParser
{ 
public: 
    virtual string parseFurtherInformation()=0;
};

    Das waren jetzt nur abstrakte Klassen, bei denen meistens nur neue Methoden hinzukommen. Wenn ich aber wegen einer neuen Implementierung ableite, dann meine ich es eichentlich auch mit der Ist-ein-Beziehung. In der Implementierung der neuen Ableitung wird dann halt einiges besser oder gar mehr gemacht.

    Von CVS, SVN, VSS habe ich noch nichts gehoert. Muss ich mir mal ansehen.
    Danke fuer die Kritik. Mir ist aufgefallen, dass ich die oeffentliche Vererbung doch manchmal missbraucht habe, wegen Code-Wiederverwendung (aus eigener Faulheit).

    0
  • B

    endline schrieb:

    TravisG schrieb:

    ich versteh das trotzdem noch nicht. so lange ich hier grade überlege, so fällt mir bei gescheitem namensdesign kein fall ein, bei dem man nach änderungen (änderungen bedeuten ja normalerweise, dass man zusätzliche features braucht oder alte abgeändert werden müssen) den namen ändern müsste.

    Ich bin gegen Aenderungen, aber fuer Erweiterungen. Das ist ja das Wesen des Opne-Closed Prinzips.

    Beispiel: Eine Klasse, die eine Xml-Konfiguration laden soll...

    //Hier kommt die Beschreibung der Klasse hin
//Laed folgendes:
// - einen Connection-String zu einer Datenbank
// - eine Tabellendefinition (um speaeter eine neue 
//   Tabelle in der Datenbank zu erzeugen)
class XmlConfigParserV1
{
public:
    virtual string parseConnectionString()=0;
    virtual TableDefinition parseTableDefinition()=0;
};

// Kann noch mehr laden..
class XmlConfigLoaderV2 : public XmlConfigParser
{ 
public: 
    virtual string parseFurtherInformation()=0;
};

    Und warum kommt die neue Methode nicht einfach zur "alten" Klasse dazu 😕

    0
  • S

    Undertaker schrieb:

    sein 'trick' hat aber den vorteil, dass man in einem programm alle versionen der klassen benutzen kann. ist vielleicht manchmal ganz nützlich...
    🙂

    Und manchmal nicht:
    du musst client code ändern wenn du eine neue version brauchst.

    die frage ist doch: bricht eine neue funktionalität in der klasse die kompatibilität zu bestehenden code. wenn das der fall ist, dann sind 2 klassen ok - aber wenn man funktionalität dazutut ändert man eher selten bestehende funktionalität.

    wenn man nun nur neue funktionalität hinzu tut, wozu eine neue klasse? Denn was mache ich, wenn ich in meinem client code der Version2 verwendet irgendwann ein feature von Version3 brauche?

    gerade das beispiel mit dem XML parser ist doch ideal ohne vererbung lösbar. einfach parseFurtherInformation in die originale Klasse packen.

    0
  • E

    gerade das beispiel mit dem XML parser ist doch ideal ohne vererbung lösbar. einfach parseFurtherInformation in die originale Klasse packen.

    Was mir dabei nicht gefaellt, ist, dass man staendig an der originalen Klasse rumpfuscht. Sprich hinzutut, wegmacht usw.

    Dann doch lieber doch kleine, "minimalistische" Module, die aufeinander aufbauen und die man je nach Bedarf benutzt.

    0
  • C

    Shade Of Mine schrieb:

    Die Idee ist wirklich furchtbar. Für Versionskontrolle gibt es CVS, SVN, VSS,...

    Man kommt in Teufelsküche wenn man Ableitung ohne Ist-Ein Beziehung macht.

    Jetzt wo du es sagst... spätestens wenn man während der Laufzeit die Version wechseln will hat man Probleme.

    0
  • ?

    Chris++ schrieb:

    Shade Of Mine schrieb:

    Die Idee ist wirklich furchtbar. Für Versionskontrolle gibt es CVS, SVN, VSS,...

    Man kommt in Teufelsküche wenn man Ableitung ohne Ist-Ein Beziehung macht.

    Jetzt wo du es sagst... spätestens wenn man während der Laufzeit die Version wechseln will hat man Probleme.

    ja, nennt man strategy pattern, aber dann kann man sich auch vernünftige namen einfallen lassen anstatt
    Sortierverfahren1, Sortierverfahren2, ... 🙄

    0
  • S

    ich-- schrieb:

    Chris++ schrieb:

    Shade Of Mine schrieb:

    Die Idee ist wirklich furchtbar. Für Versionskontrolle gibt es CVS, SVN, VSS,...

    Man kommt in Teufelsküche wenn man Ableitung ohne Ist-Ein Beziehung macht.

    Jetzt wo du es sagst... spätestens wenn man während der Laufzeit die Version wechseln will hat man Probleme.

    ja, nennt man strategy pattern, aber dann kann man sich auch vernünftige namen einfallen lassen anstatt
    Sortierverfahren1, Sortierverfahren2, ... 🙄

    Äh, mit Strategy hat das Design vom OP nichts zu tun.

    Strategy ist nicht tief, sondern breit. Das Design hier ist Tief aber nicht Breit.

    0
  • R

    wenn es ein eine bibliothek ist, ist das vorgehen wegen des fragile-base-class problems durchaus nützlich um die abi zu erhalten

    wenn es allerdings ein programm ist, dann hat das dort nix zusuchen - da kann man alles selber kompiliern, und macht somit nicht die binaries anderer kaputt

    0
Anmelden zum Antworten