Im Moment will ich meinen Stil, wie ich Programmlogik aus dem Hauptteil rausziehe, damit es veränderbar ist, verbessern, C++ typischer schreiben und performanceteschnisch das Optimum raus holen. Dazu würd ich mich über eure Erfahrungen und Tipps freuen.

So, weil sich unter meinem Problem wohl keiner was vorstellen kann hier ein kleines Beispiel (das ist nur erfunden, um das Prinzip zu erklären. Bei meinen Programmen ist es viel komplexer):
Eine Klasse benötigt bestimmte Informationen. Diese werden, je nach Anwendung, verschieden generiert und auch wieder gespeichert (in einer Instanz allerdings immer nur eine Art). Einmal werden sie über das Internet angefragt, ein anderes Mal aus einer XML gelesen oder manchmal direkt generiert.
Kleine Übereinstimmungen haben diese Wege, wie z.B. die Erstellung eines Datums aus einem String wird immer im gleich durchgeführt. Ansonsten benötigen alle Arten Grund verschiedene Implemenatationen.
Erster Ansatz: Die Datums-Erstellung in eine Methode packen und für jede Art des Einlesens/Speicherns eine Methode machen.
Ist irgend wie unübersichtlich, da es sehr viel Code wird. Aber ok, das ist hinnehmbar.
Größer Wermutstropfen ist allerdings, dass wenn irgend wer die Funktionalität gebrauchen könnte aber eine neue Art der Daten Aufbewahrung hat. Dann müsste er neue Methoden anlegen, andere die diese gar nicht brauchen schleppen das dann auch im Code mit.
Wirklich "leicht erweiterbar" ist das dann nicht.

Bin so auf eine andere Art gekommen, wie ich dies lösen kann:
Ich habe mir ein "Interface" (bzw. abstrakte Klasse) gebaut, in der ich die Methode zur Generierung des Datums zur Verfügung stelle, da es fast alle Implementationen brauchen.
Dann werden noch 2 virtuelle Methoden erwartet, einmal getData und setData. Dafür gibt es allerdings noch keine Implementationen.
In meinem Hauptprogramm, welches die Daten braucht, erwarte ich im Konstruktor ein Objekt dieses Interfaces.
Wenn ich die Daten brauche, ruf ich einfach getData von diesem Objekt auf.

Für die verschiedenen bekannten Umsetzungen der Datenverwaltung lege ich konkrete Klassen die das Interfaces implementieren an und erstelle daraus libs. Wenn später noch wer eine neue Umsetzung hat, kann er selber auch von diesem Interface ableiten und eine lib machen.

Somit braucht keiner an der Klasse der Datenverarbeitung rum schrauben, die bleibt ja immer gleich.
Aber trotzdem kann jeder das machen, was er will.

Diesen Ansatz habe ich von Java (da kann man z.B. so verschiedene Sortieralgorithmen mitgeben).
An sich bin ich auch zufrieden aber ob das wirklich C++-Konform ist bezweifel ich doch irgend wie. Deshalb würd ich gern wissen, wie man hier das normal macht und was ihr mir empfehlen würdet.

Da es bei manchen Programmen schon auf Performance ankommt bekam ich vorkurzen den Tipp, dass Templates um einiges stärker wie generische Klassen in Java sind (mit denen ich es imemr verglich) und man damit auch sowas machen kann wie ich will, also dass man damit die Methoden auch bereitstellen kann. Da es dabei dann zur Kompile-Zeit vorhanden ist, kann es aber direkt rein geschrieben werden und wird somit schneller.
Über google habe ich aber leider keine Beschreibung für diese Art wie ich es will gefunden, die mir was brachte. Bzw. bei der ich die das Problem sofort umsetzen konnte.
Habe nur irgend wo gelesen, dass es dann keine libs sein dürfen (müsste ich zwar das wieder umstellen und den Leuten erklären aber das wäre kein Problem). Ist das über Templates gut? Wenn ja, wie setz ich das genau um, dass es von der Funktionalität so ist, wie meine Lösung von oben.

vielen lieben Dank

Diesen Ansatz habe ich von Java (da kann man z.B. so verschiedene Sortieralgorithmen mitgeben).
An sich bin ich auch zufrieden aber ob das wirklich C++-Konform ist bezweifel ich doch irgend wie. Deshalb würd ich gern wissen, wie man hier das normal macht und was ihr mir empfehlen würdet.

Das ist völlig okay und gutes Design in C++. Nennt sich (Runtime-)Polymorphismus und ist einer der Grundpfeiler des objektorientierten Designs. Warum sollte das in C++ nicht richtig sein? dafür gibts doch virtuelle Funktionen!

Eine andere Möglichkeit des Polymorphismus ist der Compiletime Polymorphismus in C++, den es in Java so nicht gibt. Dazu werden Templates benutzt. Deine Basisklasse wäre dafür das eigentliche Klassentemplate. Das Template-Argument wäre dann eine Policy-Klasse, die bestimmt, wie die Daten gelesen/geschrieben werden. Google im netz mal nach Policy-based design

Da es bei manchen Programmen schon auf Performance ankommt bekam ich vorkurzen den Tipp, dass Templates um einiges stärker wie generische Klassen in Java sind (mit denen ich es imemr verglich) und man damit auch sowas machen kann wie ich will, also dass man damit die Methoden auch bereitstellen kann. Da es dabei dann zur Kompile-Zeit vorhanden ist, kann es aber direkt rein geschrieben werden und wird somit schneller.

richtig. Zur Laufzeit wirds schneller, kann aber zur Compilezeit deutlich länger dauern. Das läuft dann entweder so wie ich oben beschrieben hab, oder über Template-Spezialisierungen.

Habe nur irgend wo gelesen, dass es dann keine libs sein dürfen

Dass was keine Libs sein dürfen? Das Problem ist folgendes: Die Definitionen Templates müssen zur Compilezeit vorliegen, können also nicht in libs versteckt werden. Ansonten spricht nichts gegen libs.

Übung macht den Meister. Konkretere aber noch allgemeingültige Ratschläge fallen mir spontan nicht ein. Ich habe als Java->C++ Umsteiger zunächst im Streben nach Flexibilität relativ viele "Interfaces" (abstrakte Basisklassen) gebaut und dann gemerkt, dass da ein für C++ Verhältnisse recht unbrauchbares Design herauskam. Das wurde aber mit der Zeit besser.

Mehr auf Templates statt virtuelle Funktionen zu setzen, ist eigentlich keine schlechte Idee. Dann kann man immer noch "polymorphe Wrapper" bauen und da rein stecken, wenn man Laufzeitpolymorphie braucht.