designfrage bzgl. ableiten oder nicht

Maxi

Hallo!

Ich schreib grad an einem Projekt, welches aus Bildern bestimmte Farbmuster extrahiert, speziell für Bauchmuster von Tieren wie Kröten oder so.

Das Programm soll prinzipiell für viele verschiedene Musterarten funktionieren.
Ich habe eine Klasse cImage, welche das reine Bild enthält aus dem dann das Muster gemacht werden soll.

Unter Muster muss man sich z.b. sowas vorstellen. Kammmolche (art eidechsen) haben ein bauchmuster aus roten und schwazren flecken. Dsa Originalbild vom Bauch wird also in cImage gespeichert. Weiterhin hab ich eine Klasse cPattern, welche dann das Muster dieses Bildes speichern soll. (In diesem Fall wäre das ein Array aus 1 und 0, je nachdem, ob ein punkt als rot oder als schwarz angesehen werden kann, denn nicht alle kammmolche haben das selbe rot und das selbe schwazr als bauchfarbe. cPattern soll die Information sozusagen binärisiert (rot oder schwarz) abspeichern.)

Das funktioniert auch bis hierhin wunderbar. Man erstellt so ein Muster indem man dem Konstruktor von cPattern das cImage-Objekt übergibt, der Rest geschieht austomatisch.

Jetzt hab ich aber das Problem, dass andere Musterarten (z.B. unken) andere Farben auf dem Bauch haben, daher funktioniert das, was für den kammmolch gefunzt hat nicht bei den unken.

Jede Musterart hat also spezielle Bildungsvorschriften, wie sie aus dem orig-bild zu bilden sind. Das ist aber auch der einzige Unterschied von den Mustern, der Rest is gleich.

Meine Frage is jetzt, wie mach ich das am besten, dass ich je nachdem, was das für ein Bild ist, den richtigen Musterkonvertierungskonstruktor (oder ähnliches) auswählen kann.
Ich könnte für jedes Muster eine Unterklasse cKMPattern, cUnkePattern usw. bilden, aber das erscheint mir zu kompliziert, weil ja wirklich nur diese Konvertierung anders ist.
Was meint ihr dazu, habt ihr andere/bessere Ideen, wie man sowas machen kann?

Gruß, Maxi

Ich hab zwar nicht ganz verstanden was dein Programm macht, aber mach halt ein Interface mit den Funktionen die du brauchst und implementier es dann mit speziellen Klassen. Diese werden dann z.B. von ner Factory geliefert.

Maxi

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

Werner Salomon

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.

Maxi

@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.

Werner Salomon

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)

Maxi

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.

Werner Salomon

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

Maxi

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

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