designfrage bzgl. ableiten oder nicht



  • ja schon... hab ich auch schon dran gedacht...

    aber die klassen würden sich dann lediglich in der konvertierung von Image zu Muster unterscheiden, ich find dazu is ne Ableitung vom Interface überttrieben



  • Maxi schrieb:

    die klassen würden sich dann lediglich in der konvertierung von Image zu Muster unterscheiden, ich find dazu is ne Ableitung vom Interface überttrieben

    Hallo Maxi,

    eine Frage dazu: Ist zum Zeitpunkt der Konvertierung von Image nach Muster bekannt, um welches Tier - bzw. Bauchmuster - es sich handelt?

    Edit: Rechtschreibung



  • hm, so wie sich das anhört, musst du deinem pattern nur mitgeben, auf welche farben es sich stürzen soll. wenn es immer zwei farben sind, dann kannst du das in dein pattern einfach per konstruktor einbauen.

    class cPattern
    {
     cPattern(Color a, Color b);
    ...
    
    cPattern p(Color(0xff0000), Color(0x000000));
    


  • p.s.: wenn _nicht_ bekannt ist, auf welche farben sich das pattern stürzen soll, dann ist das nicht eine frage der programmstruktur, sondern des verwendeten algorithmus. in diesem fall müsstest du aus dem bild die zwei (oder mehr) dominanten farben herausfiltern und dann entsprechend das pattern anpassen.



  • @Werner: Ja, das ist bekannt, ich weiß, was für ein Tier das Muster ist

    @blubb: Es können auch mal 3 Farben oder mehr sein, die ein Muster ausmachen, deswegen geht dsa mit dem Konstruktor so nicht. Welche Farben rausgeholt werdne müssen, ist aber bekannt.

    Was haltet ihr davon, wenn ich mir eine extra Konvertierungsklasse schreibe, welche aus cImage ein cPattern macht? Die könnte ich dann interface-mäßig machen und je nachdem, um welches bild es sich handelt das richtige konvertierungsobjekt anfordern und die Arbeit von diesem Objekt machen lassen.



  • Maxi schrieb:

    @Werner: Ja, das ist bekannt, ich weiß, was für ein Tier das Muster ist

    Was haltet ihr davon, wenn ich mir eine extra Konvertierungsklasse schreibe, welche aus cImage ein cPattern macht?

    Letzteres ist dann nicht notwendig. Es reicht eine Funktion pro Tier zu schreiben. Etwa in dem Stil:

    cImage unkeBild;
        cImage molchBild;   
        cPattern patternUnke = machePatternVonUnke( unkeBild ); 
        cPattern patternMolch = machePatternVonMolch( molchBild);
    

    Die 'machePatternVon*()'-Funktionen haben alle die gleiche Signatur, tuen aber intern was anderes.

    Gruß
    Werner

    Edit: Copy-Paste-Fehler



  • wenn die farben bekannt sind, dann kannst du sie ja einfach in einen dynamischen container (std::vector) packen.

    class cPattern
    {
    std::vector<Color> colors;
    ...
    void addPatternColor(Color color){ colors.push_back(color); }
    ...
    

    dann muss natürlich die methode, die das pattern generiert, auf beliebige anzahl von farben umgestellt werden.

    wenn du das nicht willst, würd ich tatsächlich einfach aus cPattern nen interface machen und die entsprechenden implementationen für jedes tier davon ableiten.

    class cPattern
    {
     virtual void generatePattern(const cImage &image) = 0;
    ...
    
    class cPatternUnke : public cPattern
    {
     void generatePattern(const cImage &image){ ... }
    

    (die const referenzen kannste auch ignorieren, bilder als referenz zu übergeben ist aber sinnvoll. sind ja doch meist recht gross)



  • also, das mit den farben in std::vector geht nicht, es kommt nicht nur auf die farben an, sondern auch wie die zueinander liegen usw, von daher geht das so nicht.
    DAs mit den Konvertierungsfunktionen find ich auch nicht so gut, denn dann müsste das Muster selber wissen, was für eins es ist. Aber nur das Hauptprogramm weiß gerade, welche Musterarten gerade verarbeitet werden. Daher find ich meine Lösung mit der Konvertierungsklasse doch schon noch am besten. Mit dem Interface-Versuch muss ich mich nochmal befassen, ob das damit eleganter zu lösen wäre.



  • Maxi schrieb:

    DAs mit den Konvertierungsfunktionen find ich auch nicht so gut, denn dann müsste das Muster selber wissen, was für eins es ist.

    .. nein, das Muster müßte nicht wissen, was für eines es ist. Wie kommst Du darauf?

    😕
    Werner



  • weil das Muster in seinem Konstruktor aus dem Bild das Muster erstellt.

    Das jetzt ncoh zu ändern wäre sehr aufwändig


Anmelden zum Antworten