Problem mit Software Architektur (C++)

Ishildur

@Jockelx
Ja wenn du von Anfang an damit rechnest, dass du beides implementieren willst, wirst du sicherlich keine Probleme bekommen (Weil du es eben beim Klassendesgin bereits berücksichtigst). Aber wenn du nun bspw. beim Design davon ausgehst, dass IVideoService einfach den Video Part der Applikation erledigt (ohne je daran zu denken, dass es ja noch was anderes als bspw. OpenGL) gibt, dann wirst du mit grosser Wahrscheinlichkeit die OpenGL members in den IVideoService reinpacken. Wenn dann später Direct3D dazu kommen soll must du in mühsamer Arbeit, sämtliche Members die in irgendeiner Verbindung mit OpenGL stehen rauspflücken und in eine abgleitete Klasse OpenGlVideoService umschaufeln (die halben Funktionen von IVideoServie laufen mal nicht mehr deswegen), kurz ein bis 2 Tage Refactoring bis der komplette OpenGL Teil aus IVideoService nach OpenGlVideoService ausgelagert wurde. Anschliessend kann man schliesslich die Direct3DVideoService Klasse machen.

Hast du von Anfang an keine Members in IVideoService (einfach aus Prinzip, weil man ja nie wissen kann, was da noch kommt) wirst du solche Scenarien IMHO viel seltener bis gar nicht mehr erleben. OpenGLVideoService wurde (einfach aus Prinzip) als konkrete Implementierung von IVideoService gemacht (und nicht IVideoService selbst). Kommt später Direct3D dazu (woran niemand je gedacht hätte), hast du ein bis 2 Tage Refactoring gespart.

@Dravere

Dann war das ein Dogmatiker

War er! Weisst du es war ja nicht das Problem, dass man seine Erwartungen nicht hätte erfüllen können, sondern vielmehr darum, dass man ein völlig korrektes und fehlerfreies Resultat geliefert hat und dafür ein Ungenügend kassiert hat, weil dieser Person der Programmierstil nicht gefallen hat, bei einem anderen Lehrer hätte dieselbe Lösung vielleicht ein Hervorragend gegeben, während die Lösung mit den Booleans eine Ungenügend gegeben hätte mit der Begründing "Die zur Verfügung stehenden Sprachfeatures wurden nicht optimal ausgenutzt, dies wäre ein perfektes Beispiel für ein Continue gewesen und ich wollte sehen, ob ihr das kennt."

Da kommt mir in den Sinn, ich bekam vor einem halben Jahr in einer Javaprüfung 5 von 25 möglichen Punkten abgezogen, weil ich in Funktionen kein return am Schluss machte... In Funktionen mit dem Rückgabetyp void... Er empfand das als schlechter Stil, eine Funktion müsse immer ein Return haben:

void DoSomething(){
  // my code
  return;
 }

Interessant ist, dass ca. 90% der Lehrer und Professoren, mit denen ich zu tun habe und die uns Studenten (auf eine teilweise äusserst dogmatische und missionarische) Art und Weise IHREN Stil als die einzige und letzte Wahrheit verkaufen, in ihrem Leben noch nicht ein einziges funktionierendes Programm geschrieben haben, dass mehr als ein paar 100 Zeilen umfasst. Aber dennoch ist einfach so gut wie alles falsch bös und schlechter Stil was Andere machen...

Dravere

Ishildur schrieb:

Hast du von Anfang an keine Members in IVideoService (einfach aus Prinzip, weil man ja nie wissen kann, was da noch kommt) wirst du solche Scenarien IMHO viel seltener bis gar nicht mehr erleben. OpenGLVideoService wurde (einfach aus Prinzip) als konkrete Implementierung von IVideoService gemacht (und nicht IVideoService selbst). Kommt später Direct3D dazu (woran niemand je gedacht hätte), hast du ein bis 2 Tage Refactoring gespart.

Man kann nicht ALLES voraussehen beim Programmieren. Wenn du so programmierst, erstellst du für die Aufgabe völlig untaugliche Programme. Programme werden auf einen gewissen Bereich zugeschnitten, dass hat durchaus einen Sinn. Es ist viel sinnvoller, wenn dann tatsächlich einmal Veränderungen kommen, ein gründliches Refactoring durchzuführen. Dass heisst allgemein gleich andere Fehlentscheide aufzuräumen und mit den neuen Vorgaben wieder einen neuen optimierten Weg finden.

Klar, ein wenig in die Zukunft sehen schadet nicht, aber man kann es auch übertreiben. Habe schon des Öfteren gesehen, wie grossartig in die Zukunft geplant wurde mit Erweiterbarkeit und co, und als dann das wirkliche Problem kam, musste man es doch anders lösen, wodurch die ganze Arbeit davor für die Katz war und das Programm bisher leicht schlechter lief oder wartbar war für nichts.

Zu den Professoren sag ich jetzt mal nichts. Bisher hatte ich zum Glück keine solchen krankhaften Dogmatiker, aber gerade an der Universität hatte man zum Teil echt das Gefühl, dass die Professoren 20 Jahre hinten nach sind. Ein allgemeines bekanntes Problem, sieht man auch oft bei Anfängern hier im Forum, dass hinter ihnen ein Professor ohne viel Ahnung steht.

Grüssli

Ishildur

Man kann nicht ALLES voraussehen beim Programmieren.

Hehe da bin ich ja absolut deiner Meinung, daher versuche ich ja auch so zu programmieren, dass unvorhergesehendes nicht ein Refactoring der halben Applikation zur Folge hat (siehe auch: http://en.wikipedia.org/wiki/Coupling_(computer_science))

asc

Ishildur schrieb:

Man kann nicht ALLES voraussehen beim Programmieren.

Hehe da bin ich ja absolut deiner Meinung, daher versuche ich ja auch so zu programmieren, dass unvorhergesehendes nicht ein Refactoring der halben Applikation zur Folge hat...

Die Wahrheit liegt irgendwo dazwischen.

Ja, es kann nach hinten losgehen, wenn man Code ausschließlich auf einen Fall hin programmiert, ohne sich mögliche Änderung auch nur im Keim vorzustellen. Aber alles auf Änderbarkeit hin zu programmieren ist häufig auch der falsche Weg. Den in der Praxis können beide Extreme effektiv sehr viel Zeit kosten.

Im ersten Fall weil ein Refactoring extrem aufwendig wird, im zweiten weil man vielleicht zuviel Zeit in etwas investiert hat, das später entweder nicht relevant ist, oder an einer anderen Stelle eingebaut werden muss.

Ishildur

@asc
Wow! Dem kann ich nichts mehr hinzufügen. Da stimme ich dir zu 100% zu (habe auch beide Situationen bereits am eigenen Leib erfahren). Genau dieser Mittelweg ist halt eine riesen Gratwanderung und in meiner Erfahrung IMMER ein Streitpunkt innerhalb des Teams