Richtiges Design

Reth

Hallo zusammen,

die Frage mag blöd klingen, aber ich überlege gerade Folgendes:

Ich möchte einer Klasse Methoden zum Hinzufügen von animierten Objekten geben. Diese unterscheiden sich in Hintergrund und bewegliche Objekte.

Macht man da 2 public Methoden

addBackGround(...);

und

addMovable(...);

oder macht man eine Methode

addAnimation(.., BOOL backGround);

?

Da ich sehr javalastig bin, tendiere ich eher zu erstem Ansatz, wobei intern natürlich auf eine private Methode zurückgegriffen wird, da der Code sonst fast dupliziert wäre.

Gibts da in C++ Konventionen?

Danke schon mal
Ciao

branleb

wenn du eh eine gemiensame private methode machen willst
würd ich dir empfehlen zweiters da es weniger code is und flexibler..
allerdings selbre würde ich zu ersterem tendiren ohne private methode.. code duplizierren geht heutzutage mit STRG+C / STRG +V

Mfg SHade37337

cin

wie wärs mit 2 verschiedenen klassen, die von Objekt abgeleitet wurden. Somit ist es möglich über eine Array/Vector alle Objekte durchzuiterieren und gleichzeitig sparst du dir lästige

void Draw()
{
  if(Background)
  {
    DrawBackground();
  }
  else
  {
    DrawAnimation(aktuellesBild++);
  }
}

abfragen.

Reth

shade37337 schrieb:

wenn du eh eine gemiensame private methode machen willst
würd ich dir empfehlen zweiters da es weniger code is und flexibler..
allerdings selbre würde ich zu ersterem tendiren ohne private methode.. code duplizierren geht heutzutage mit STRG+C / STRG +V

Mfg SHade37337

Ist aber schlechter wartbar!

Ciao

Reth

cin schrieb:

wie wärs mit 2 verschiedenen klassen, die von Objekt abgeleitet wurden. Somit ist es möglich über eine Array/Vector alle Objekte durchzuiterieren und gleichzeitig sparst du dir lästige
void Draw()
{
  if(Background)
  {
    DrawBackground();
  }
  else
  {
    DrawAnimation(aktuellesBild++);
  }
}
abfragen.

Das läuft doch aber auch auf 2 Hinzufügemethoden hinaus, oder?

addBackGround();
addAnim();

In draw() wird dann abgefagt, was gezeichnet werden soll.

Ciao

cin

class DrawObject
{
public:
  virtual void Draw()=0;
};

class DrawBackground : public DrawObject
{
public:
  void Draw(){...};
};

class DrawAnimation : public DrawObject
{
public:
  void Draw(){...};
};

class DrawManager
{
private:
    std::vector<DrawObject*> ZeichenObjekte;
public:
    void Draw()
    {
      //for(n=0...)
        ZeichenObjekte[n].Draw();
    }
    void AddDrawObject(DrawObject* obj)
    {
        ZeichenObjekte.push_back(obj);
    }
};

DrawManager.AddDrawObject(new DrawBackground("bild1.bmp",210,20));
DrawManager.AddDrawObject(new DrawBackground("bild2.bmp",30,400));
DrawManager.AddDrawObject(new DrawAnimation("ani1.bmp",210,20,21));

So meinte ich das eigentlich. Um die Abfrage, ob du jetzt Hintergrund-Objekte hinzufügst, oder eben andere, kommst du natürlich nicht drumherum, aber diese Abfrage sollte sich auf ein Minimum reduzieren. In diesem Beispiel ist es dem "DrawManager" zum Beispiel vollkommen egal, was für ein Typ er jetzt zeichnet.

life

auch wenns nicht wirklich schön ist, kannstes zur Not auch so machen:

class Background {
    public: 
        static const bool backGround = true;
  //....
}

class AniObj{
    public: 
        static const bool backGround = false;
  //....
}

....
template<class T>
void add(T obj)
{
    if(T::backGround)
        //blabla
    else
        //blabl
    //blaba
}

dann haste zumindest kein performanceverlust durch if Abfrage und auch keine Codedublizierung..

Konfusius

du kannst auch addAnimation() privat implementieren und dann addBackground() und addMovable() als public-inline-methoden hinzufügen.

walljumper

vieleicht hilf dir das

http://www.robsite.de/daten/tutorials/NotizCPP.zip

da gehts hauptsächlich um guten stil.

Marc++us

shade37337 schrieb:

wenn du eh eine gemiensame private methode machen willst
würd ich dir empfehlen zweiters da es weniger code is und flexibler..
allerdings selbre würde ich zu ersterem tendiren ohne private methode.. code duplizierren geht heutzutage mit STRG+C / STRG +V

Code wird niemals dupliziert.

STRG+C / STRG+V ist ein schlechter Ratgeber für jeden Entwickler, besser Kopf einschalten.

Siehe auch Refactoring | ISBN: 3827322782