3. Wie ein groesseres Project angehen?

Wie ein groesseres Project angehen?

  • Administrator

    Ich stimme meinen Vorrednern eigentlich auch zu. Für Schnittstellen, bzw. portieren zwischen verschiedenen GUIs (bzw. von der Konsole zu einer GUI) empfehle ich dir ein MVC-Modell. Kannst vielleicht mal im Inet nach MVC suchen, gibt da überall verschiedene Einträge. Eigentlich geht es darum, Daten von der Ausgabe zu trennen. MVC steht schliesslich auch für Model View Controller, also Modell Ansicht Steuereinheit.

    Was ich dir aber auch empfehlen kann, hüpf ins kalte Wasser! Also mir hat das unheimlich geholfen. Ich bin voller optimismus und gross gekotzt an mein erstes grosses Projekt ran. Es hat am Ende funktioniert, aber ich habe viel gelernt und nach einem Jahr support wusste ich dann auch nochmals einiges mehr 😃

    Ansonsten gibt es auch Bücher zur Projektplanung. Da kann man natürlich sehr ins komplexe gehen. Zum Beispiel Gantt-Charts, wann du was und wie fertig haben willst, welcher Arbeit von was abhängt usw. ^^

    Zwei Tipps vielleicht noch: UML und Codebeschriftung 😉

    Ansonsten, das Thema ist eben riesig. Buch kaufen oder einfach mal probieren und lernen 😉

    Grüssli

    0
  • T

    versuch dir bei sowas immer klar zu machen, wo programmlogik steckt, wo daten rumgeschubst werden und wo interaktion mit dem benutzer stattfindet. MVC deckt nur ein teilgebiet davon ab.

    wenn man beispielsweise eine ID auf gültigkeit überprüfen möchte, besteht das ganze aus drei teilaufgaben:

    - beschaffung der ID
    - berechnung der gültigkeit
    - präsentation des ergebnisses

    die berechnung der gültigkeit ist reine programmlogik. das ist ein modul, welches man problemlos völlig abstrakt implementieren kann.

    boolean validate(std::string id);

    das ding kann nichts weiter, als eine id auf gültigkeit zu prüfen. jetzt möchte man die methode natürlich mit daten füttern. woher bekommt man die? zum testen steckt man da vielleicht nen hart kodierten string rein. für seine konsolenanwendung liest man die evtl. aus cin, oder übergibt sie als programm parameter. wenn man das stückchen logik in eine GUI anwendung klebt, kommt die eingabe vielleicht aus einer textbox.

    und ähnlich siehts mit der präsentation aus. die kann in eine datei geschoben werden, oder auf der konsole passieren oder vielleicht ein grüner button im GUI.

    wenn man eine anwendung sauber gestaltet und darauf achtet, logik und I/O immer strikt voneinander zu trennen, dann ist es völlig problemlos möglich, ein und dieselbe anwendung einmal als konsolenanwendung und einmal als GUI anwendung auszuliefern.

    0
  • V

    im allgemeinen finde ich es sinnvoll, wenn nicht nur das ziel fest steht, sondern auch diverse planungen.
    wenn man sich im vornherein gedanken darüber macht, wie man alles an gehn will (stichwort UML), dann ist die implementierung eigentlich nebensache. bei einer guten planung schreibt man seine klassendiagramme, MSCs etc einfach ab und es läuft. allerdings nimmt eben die planung recht viel zeit in anspruch, was einen auch wieder davon ab hält. hatte mal in java n projekt, in dem ich zwei wochen vor "abgabe" mein komplettes internes klassenkonzept über den haufen geschmissen habe. das war nicht ideal und ich hätte es mir mit gescheiter planung sparen können, allerdings hatte ich die schnittstellen so definiert, dass das austauschen des ganzen konzeptes nicht das problem war.

    0
  • P

    Was die Abstrakte Ausgeb angeht: such mal im netz nach "MVC-paradigma" oder "model-viewer-controller" - da findest du eine Idee dessen, was gemeint war. Trenne deine Programmlogik so weit wie moeglich von Ein- und Ausgabe, dann ists am Ende einfacher, letztere zu ersetzen (z.B. Konsole durch GUI)

    0
  • C

    Ein wirkliches gutes Projekt steht schon, bevor die erste Zeile Code implementiert wurde.

    Oder: Wer bei Projekten stets an das Programmieren denkt, der wird nie weit kommen.

    Klassische Arbeitsschritte sind:
    Analyse - Was gibt es bereits, wie wird das gemacht
    Anforderungen - Was muss das Programm können
    Design - Wie muss es das leisten
    Konstruktion - Wie baue ich die Module / Klassen etc auf
    Implementierung
    Testen
    Launch

    Mit guten Tools lassen sich die Design- und Konstruktionsschritte zB direkt als Code-Rahmen für ein Programm ausgeben
    die eigentliche Implementierung ist dann nur Wischi-waschi 😃 weniger Wochen

    0
  • V

    ich würde allerdings während der implementierung halt die einzelnen module / submodule etc jeweils eingängig testen

    0
  • ?

    Wenn du noch nie was mit GUI gemacht hast, dann mach erst mal ein paar GUI Übungsprogramme. Dann siehst du wie das funktioniert und kommst auch ein bisschen von der "Konsolendenkweise" weg.
    Einigermasen vernünftiges Design (MVC,...) wirst du beim ersten mal sowieso nicht gleich hin bekommen. Natürlich ist es gut MVC zukennen, aber ohne verständnis für das was ein UI kann und wie es funktioniert, wirst du es sehr wahrscheinlich nicht verstehen bzw. richtig umsetzen können.

    0
  • G

    Zwischendurch schon mal ein grosse DANKESCHOEN fuer Eure Muehe und die offensichtlich tollen Ratschlaege.

    Ich werd's mir nachher mal in Ruhe durchlesen und mich dann noch mal mit einem Fazit melden.

    Gruss

    Guenther

    0
  • G

    Neben all dem, was ich beim Studium der vielen guten Ratschlaege gelernt und/oder begriffen habe, scheint es mir besonders wichtig zu sein, dass bei meinen naechsten Schritte mein Hauptaugenmerk wirklich auf die strikte Trennung von Logik und I/O gerichtet sein sollte. Etwas, was ich aber 'relativ' einfach umsetzen kann, da ich intuitiv den Grossteil meiner Programmlogik ohnehin schon in jeweils einzelne Funktionen gelegt habe.

    Ich denke aber auch, dass es tatsaechlkich hilfreich sein duerfte, wenn ich mich daneben in den naechsten Tagen mal ein kleines GUI Projekt wage, also einfach nur so zum Test, damit ich's 'mal gesehen habe'. Das sollte mir helfen, das Ganze noch ein wenig besser verstehen zu koennen.

    Aber wie gesagt, nur zum Test und nur mal zwischendurch. Ansonsten werde ich weiter meine Funktionen entwickeln, bei denen ich Ein- und Ausgabe in die main() 'auslagere' und natuerlich hoffen, dass ich dann spaeter wirklich all diese Funktionen ohne grosse Aenderungen in die geplante GUI Version uebernehmen kann.

    Ansonsten heisst es fuer mich 'ueben, ueben, ueben ...', denn bekanntlich ist es die Uebung, die den Meister macht! Und an manchen Tagen laeuft's wirklich schon recht gut. Es gibt aber natuerlich auch Tage, da bin ich leicht am Zweifeln, weil ploetzlich ueberhaupt nichts klappt. So wie gestern, als ich versucht habe ein Programm mit

    g++ -v -o example -lncurses example.cpp

    statt mit

    g++ -v -o example example.cpp -lncurses

    zu uebersetzen und mich dann wundere, dass der Linker immer die fehlende Library anmeckert ... 😃

    Aber nun gut, dass sind die Fehler, aus denen man(n) lernt ...

    Nochmals vielen Dank fuer Eure Hilfe ... 😉

    Guenther

    0
  • T

    das ist der grund, warum es IDEs gibt 😉 wenn man weiss, dass der compiler mit "g++ in.c -o out" aufgerufen wird, hat man genug gelernt und kanns ab da einem IDE überlassen.

    0
  • B

    gboelter schrieb:

    Es gibt aber natuerlich auch Tage, da bin ich leicht am Zweifeln, weil ploetzlich ueberhaupt nichts klappt.

    Die wird es immer geben, passiert mir auch nach ~4 Jahren mit C++ immer wieder mal 🙂

    0
  • V

    weiß net, finde von hand compilieren eh schwachsinnig, außer du hast genau 1 file zu compilieren
    nimm halt zur not einfach make, des is echt schön, kann man so richtig lustige logik einbauen (und makefiles zusammen stöpseln, die keiner mehr lesen kann :D)

    0
  • B

    Finde ich eigentlich gar nicht. Gerade beim "Von-Hand-Kompilieren" lernt man ja diesen Entwicklungsprozess. IDEs sind praktisch ohne Zweifel, verbergen aber auch (wohl oder übel) einen entscheidenen Teil der Programmerstellung.

    Wenns umfangreicher wird, kann man immer noch makefiles schreiben.

    Und wenn man zuviele Objektdateien "rumfliegen" hat, dann kann man diese hübsch mittels ar in eine Statische Bibliothek zusammenführen. So wird der Linkeraufruf (oder die Kombination g++) wieder übersichtlich.

    Fazit: Wenn man "Von-Hand-Kompilieren" kann, schafft man es ohne weiteres die Projektoptionen in der IDE richtig einzustellen, was in der anderen Richtung schon nicht mehr ohne weiteres möglich ist.

    Grüße...

    Heiko

    0
  • V

    ich sach mal so:
    wenn man des ganze mit make kann, gehts genauso...

    0
Anmelden zum Antworten