3. mehrere interfaces

mehrere interfaces

  • ?

    Hallo

    ich schreibe grade eine dll die interfaces exportiert.

    dabei erben die objekte z.b. von mehreren interfaces, (keine konkreten klassen).
    macht es sinn ein objekt in mehrere spezialisierte interfaces aufzuteilen oder sämmtliche funktionalität in weniger spezialisierten interfaces zu packen?

    struct iface1
{
    virtual void func1() = 0;
};
struct iface2
{
    virtual void func2() = 0;
};
struct iface3
{
    virtual void func3() = 0;
};
class object : public iface1, public iface2, public iface3
{
//....
};

    vs:

    struct iface
{
    virtual void func1() = 0;
    virtual void func2() = 0;
    virtual void func3() = 0;
};
class object : public iface
{
//....
};

    das erste hätte den vorteil, dass man mehrere unterscheidliche objekte
    je nach verwendungszweck irgentwo speichern kann.

    welches design findet ihr besser?

    0
  • D

    Ich finde, das kann man so nicht beantworten. Dazu ist dein Beispiel nicht konkret genug.

    Falls es möglich ist, dass nicht bloß eine Klasse von deinen drei Interfaces erbt, sondern, dass es auch Klassen gibt, die sinnvoll von nur einem erben, solltest du sie so aufteilen. Falls die drei Interfaces wirklich drei verschiedene Konzepte darstellen dito. Allerdings wäre dann eine Klasse, die alle drei (total verschiedenen!) Konzepte implementiert wohl fragwürdig.

    Fazit: Es kommt auf die konkreten Interfaces an, um zu entscheiden, was besser ist.

    Stefan.

    0
  • ?

    es geht um die klassen einer GUI

    es gibt

    element (position, größe, rahmenbreite...)
    textelement (alles was ein text beinhaltet) // hab kein besseren namen gefunden
    scrollable (alles was eine scrollbar haben kann)
    renderable (man kann es malen)
    stated (alles was mehrere zustände haben kann)
    parentelement (alles was unterelemente hat)

    (viele namen hab ich mir eben aus den ingern gesogen 😉 )

    bei einer gui gibt es ja für alles ein element. um möglichst code-duplication
    zu verhindern, und um elemente unter der selben kategorie abspeichern zu können,
    wäre es hilfreich die interfaces so spezialisiert wie möglich zu machen.

    sowas ähnlich wie das COM-model halt. dort gibt es auch für jede funktionalität
    ein interface.

    so könnte man in einer liste alle farbigen elemente speichern und in einer anderen alle, die auf die maus reagieren, etc.

    0
  • ?

    ein beispiel:

    button ist

    element, renderable, textelement und colored

    ein frame allerdings ist

    element, (renderable vllt), parentelement, scrollable

    es gibt also allerlei mögliche kombinationen auf den interfaces. wie sollte man
    das am besten handhaben? (OOP natürlich)

    0
  • D

    Nach meinen eigenen Worten muss ich wohl dafür sein, dass es in diesem Fall viele Interfaces gibt 😉

    Bei einigen deiner Vorschläge habe ich allerdings meine Zweifel:

    - stated
    Irgendwie kann doch jedes Objekt mehrere Zustände haben? Das sind für mich Objekt-Attibute. button => pressed, window => visible ...

    - colored
    Dasselbe. Farbe ist ein Attribut bestimmter Elemente.

    Stefan.

    0
  • ?

    mit dem stated und colored hast du recht.
    wenn man aber defür ein interface macht, kann man z.b. alle elemente in der lsite
    auf einmal grün färben.

    stated... naja nicht jedes element kann merere zustände haben (dauerzustände wie bei einer checkbox)

    0
  • D

    namenbentuzer schrieb:

    mit dem stated und colored hast du recht.
    wenn man aber defür ein interface macht, kann man z.b. alle elemente in der lsite
    auf einmal grün färben.

    stated... naja nicht jedes element kann merere zustände haben (dauerzustände wie bei einer checkbox)

    Ich weiß nicht.... Ich hab auch schon eine GUI-Lib gemacht, aber auf solche Klassen wäre ich nie gekommen 😉

    Du wirst es wohl selbst am besten wissen.

    Stefan.

    0
Anmelden zum Antworten