besser ist es nicht den Code durchzugehen und versuchen daraus OO zu machen, sondern die bewusst werden, was das Programm im einzelnen genau machen soll.

D.h. neuplanen und dann deinen "C-Code" ggf. als implementation einbauen.

Aber das wird eine recht mühsame und langwierige Arbeit werden. Du musst dir überlegen, ob sich das lohnt. Vor allem musst du den Code auch so anpassen, dass es mit den Scopes, Modulen (Header-/Implementierung getrennt), Speicherklassen etc. aufgeht und nicht einfach alles global ist. Also plane vorher eine ausführliche Konzeption, sonst wirst du relativ schnell an den Punkt kommen, wo du nicht mehr weiter weisst.

Eine gute Möglichkeit wäre denke ich:

1. Ganz unten anfangen und erstmal Klassen rausfaktorisieren, solange bis da nixmehr ist was "eine Klasse sein sollte"

2. Den ganzen Code durchgehen und typische C-Dinge (strxxx Funktionen, printf, FILE*, Arrays) durch die entsprechenden C++-Dinge zu ersetzen (std::string, streams, container). Hier räumst du auch mit Dingen auf wie Callback Funktionen, void*, C-Style-Casts, Error-Codes etc.

3. Den ganzen Code durchgehen und gucken wo du diverse Patterns anwenden könntest um den bestehenden Code zu vereinfachen.

System.Information.User //Auslesen Benutzer Informationen
System.Status;  //Gibt den Zustand der Systems aus
...

Ich entwerfe erstmal die Struktur der Namespaces, damit kann man einfacher und zielgerichteter zugreifen.

Was meint Ihr, wie sieht es mit den verschachtelten Namespaces aus, wird die Datei nicht zu unübersichtlich je mehr Namespaces vorhanden sind?

Hallo, ich habe ein Projekt das ich früher mal erstellt habe, nur leider ist der Code nicht Objekt Orientiert, eher Imperativ, schritt für schritt, eher im C Stil. Nun möchte ich diesen Code in Klassen schreiben bzw. auslagern, könnt ihr mir paar Tipps geben wie man sowas strukturiert??

erstmal solltest du dir überlegen, in wie fern ein objektorientiertes design dir zum vorteil gereichen könnte. dir sollte klar sein, dass die meisten codes probleme aus der realen welt lösen sollen und kein selbstzweck sind. lässt sich das problem am besten objektorientiert modellieren, dann ist ein objektorientiertes program wahrscheinlich eine gute wahl. wird dagegen die objektorientierte analyse schwierig, dann ist womöglich ein anderer ansatz erfolgversprechender. die frage sollte sein, wie zufrieden oder unzufrieden du mit dem bisherige resultat bist und was ein oo-design verbessern könnte. einem funktionierenden programm ein zwanghaftes oo-korsett zu verpassen ist nur zeitraubendes 'verschlimmbessern'.

hustbaer schrieb:

2. Den ganzen Code durchgehen und typische C-Dinge (strxxx Funktionen, printf, FILE*, Arrays) durch die entsprechenden C++-Dinge zu ersetzen (std::string, streams, container). Hier räumst du auch mit Dingen auf wie Callback Funktionen, void*, C-Style-Casts, Error-Codes etc.

und 'mature code', der womöglich schon einige bugfixes hinter sich hat, gegen neue macken austauschen? echt noobish, ey. so'ne antwort hätt ich von dir nie erwartet.

hustbaer schrieb:

2. Den ganzen Code durchgehen und typische C-Dinge (strxxx Funktionen, printf, FILE*, Arrays) durch die entsprechenden C++-Dinge zu ersetzen (std::string, streams, container). Hier räumst du auch mit Dingen auf wie Callback Funktionen, void*, C-Style-Casts, Error-Codes etc.

und 'mature code', der womöglich schon einige bugfixes hinter sich hat, gegen neue macken austauschen? echt noobish, ey. so'ne antwort hätt ich von dir nie erwartet.

Wenn man das Programm schon angreift, wieso nicht?
Dass bei einem gröberen Umbau viel gehobelt wird und auch ein paar Späne fallen werden ist ja wohl zu erwarten.
Wenn ich den ganzen "C-Scheiss" drinlassen will, wieso dann überhaupt was ändern. Gerade die ganzen String-Funktionen, Container, Algorithmen etc. von C++ sind es doch die es einem erleichtern korrekten, fehlerarmen Code zu schreiben. Wenn ich das Projekt in Zukunft noch warten muss dann zahlt es sich schnell aus mal ein paar neue Bugs beim Umbau zu riskieren, denn dafür kann ich später viel einfacher und effektiver (weniger Fehler) arbeiten.