Interface-Design: Alternative zu template virtual
Verfasst: 25.07.2018, 17:16
Hallo,
ich suche einen Rat bei einer Architektur-Fragestellung in meinem C++ Projekt.
In einem Simulationscode müssen Matrizen aufgebaut werden. Die Matrizen sind tatsächlich Bandmatrizen und könnten daher sowohl in einer speziellen Bandmatrix-Datenstruktur als auch in einer Sparse-Struktur gespeichert werden. Die Objekte, die die Matrix befüllen, bekommen einen Zeilen-Iterator auf die jeweilige Matrix-Datenstruktur und können diese so befüllen. Beide Datenstrukturen haben in dem einen oder anderen Kontext Vorteile, weshalb beide nutzbar sein sollen. Die Objekte müssen auch ein Interface implementieren, damit der Simulator sie einheitlich verwenden kann.
Das sieht momentan so aus:
Die Weiterleitungen an das Template
sind momentan hinter einem Makro versteckt, weil ich viele Implementierungen von IUnit habe und Tipparbeit sparen möchte. Außerdem ist das Refactoring einfacher.
Dieses Pattern habe ich noch an einigen anderen Stellen mit anderen Klassen und ich finde es nicht besonders schön. Ich habe diesen Ansatz gewählt, weil die Matrizen groß sind und ich ein Interface für die Iteratoren wegen des Overheads vermeiden möchte.
Ideal wären template virtual Funktionen, die es natürlich aus verständlichen Gründen nicht gibt. Ich könnte alles in Templates umwandeln und von dem Interface abrücken, aber das ist wegen der Kompilierzeiten inakzeptabel und verhindert außerdem, dass ich IUnits dynamisch als Plugin laden kann.
Gibt es eine andere / bessere Lösung für dieses Problem?
Wenn Ihr diese Lösung gar nicht schlimm findet, bin ich auch für diese Info dankbar.
Viele Grüße
NeuroCoder
PS: Warum gibts hier eigentlich kein Code-Highlighting oder zumindest die Option meine Einrückung nicht zu schlucken?
ich suche einen Rat bei einer Architektur-Fragestellung in meinem C++ Projekt.
In einem Simulationscode müssen Matrizen aufgebaut werden. Die Matrizen sind tatsächlich Bandmatrizen und könnten daher sowohl in einer speziellen Bandmatrix-Datenstruktur als auch in einer Sparse-Struktur gespeichert werden. Die Objekte, die die Matrix befüllen, bekommen einen Zeilen-Iterator auf die jeweilige Matrix-Datenstruktur und können diese so befüllen. Beide Datenstrukturen haben in dem einen oder anderen Kontext Vorteile, weshalb beide nutzbar sein sollen. Die Objekte müssen auch ein Interface implementieren, damit der Simulator sie einheitlich verwenden kann.
Das sieht momentan so aus:
Code: Alles auswählen
class IUnit
{
public:
virtual void assemble(SparseMatrixIterator& it) const = 0;
virtual void assemble(BandMatrixIterator& it) const = 0;
};
class SomeUnit : public IUnit
{
public:
virtual void assemble(SparseMatrixIterator& it) const { assembleImpl(it); }
virtual void assemble(BandMatrixIterator& it) const { assembleImpl(it); }
protected:
template <typename iter_t>
void assembleImpl(iter_t& it) { /* ... */ }
};
Code: Alles auswählen
virtual void assemble(SparseMatrixIterator& it) const { assembleImpl(it); }
virtual void assemble(BandMatrixIterator& it) const { assembleImpl(it); }
Dieses Pattern habe ich noch an einigen anderen Stellen mit anderen Klassen und ich finde es nicht besonders schön. Ich habe diesen Ansatz gewählt, weil die Matrizen groß sind und ich ein Interface für die Iteratoren wegen des Overheads vermeiden möchte.
Ideal wären template virtual Funktionen, die es natürlich aus verständlichen Gründen nicht gibt. Ich könnte alles in Templates umwandeln und von dem Interface abrücken, aber das ist wegen der Kompilierzeiten inakzeptabel und verhindert außerdem, dass ich IUnits dynamisch als Plugin laden kann.
Gibt es eine andere / bessere Lösung für dieses Problem?
Wenn Ihr diese Lösung gar nicht schlimm findet, bin ich auch für diese Info dankbar.
Viele Grüße
NeuroCoder
PS: Warum gibts hier eigentlich kein Code-Highlighting oder zumindest die Option meine Einrückung nicht zu schlucken?