Netzwerk-Tool ist Fertig!

So, ich hab mir jetzt mal den Sourcecode genauer angesehen. Und zwar nicht in Bezug auf Funktionalität, sondern in Richtung OOP, Aufbau, StylingCodes etc.

Folgende Punkte sind meiner meinung Nach nicht ok. Bewertung:
1 == Sehr gut
5 == Sehr schlecht

1. Wie war das? GUI und Code sollten nicht vermischt werden. Hier gibts eine 5.
2. Code ist für mich unübersichtlich, da verschiedene Einrückungen etc. verwendet werden. Das ergibt eine 3.
3. Namensgebung: Nicht vollständig durchgezogen bzw. wurde kein StyleGuide verwendet. Ein anderer Programmierer tut sich da nicht so einfach. Methodennamen beginnen immer mit einem Großbuchstaben - wurde nicht durchgängig von dir umgesetzt. Hier bekommst du eine 4.
4. Fehlerbehandlung: Gibts nicht. Ausserdem sehe ich da leere catch-Blöcke. Sehr unsauber. Etwas besseres als 5 hast du hier nicht verdient.
5. Du verwendest keine Modifier. Auch wenn es Default-Modidier gibt, sollte dieser immer angegeben werden (public/private etc.)
6. Teilweise sinnloser Code, siehe Button1Click ... - dafür gibts keine Note.

So, jetzt solltest wieder ein wenig daraus lernen. Hoff ich halt.
 
Die deutlichere Variante:

Businesslogik (also Funktionen, Abläufe, etc.) sollten in eigene Klassen, Projekte, etc. ausgelagert werden. Das bedeutet, dass es nicht so laufen soll, dass man im GUI-Designer auf einen Button doppelklickt und dort seinen Code eingibt, der dann die Aufgabe erledigt. An dieser Stelle sollte nur der Aufruf einer Klasse stattfinden, die dann die Arbeit übernimmt und die gewünschten Daten zurückgibt.

Stichwörter
* OOP
* Object Oriented Programming
 
Hallo Alexander12!
Alexander12 hat gesagt.:
Könntest du ein bisserl deutlicher werden?
Er meint das Du dich endlich mal mit der OOP auseinander setzen sollst. (!)
Fasse Aufgabenbereiche in Klassen zusammen. Die GUI darf "NUR" visualisieren.
Alles andere ist absolut unsauber, unwartbar und macht die Wiederverwendbarkeit vorhandenen Codes unmöglich.

MfG, cosmo
 
Hi Leute!

Ich glaub wir sind dem release schon nahe! *freu*

Norbert, das mit dem in Klassen etc. auslagern habe Ich leider noch nicht hinbekommen, habee das meiste halt mal in eigene Methoden in der MainForm geschrieben, die Ich dann im EventHandler aufruf, das ist aber auch das einzige was mir nicht gelungen ist.

Aber Norbert, das ExceptionHandling ist drin, Ich habe das CodeFile angehängt, bewerte den Code nochmal. ;)

Ach, MFC, Hier hast dein Menü und deinen About-Button.

Und ZioPs Stop Button ist auch nicht zu vergessen!

Desweiteren habe Ich einen Filter reingemacht, also dass er nicht jeden *piep* ( :) ) auflistet, sondern nur Rechner.

Sind wir dem Release langsam aber sicher nahe?


MfG Alexander12
 

Anhänge

  • Tool.zip
    10,6 KB · Aufrufe: 53
langsam aber sicher verlier ich die LUST!!

- Das Programm findet bei mir immernoch keine Rechner
- ein Klick auf öffnen bringt eine unsinnige Meldung (Wieso wird was gemacht, wenn nichts markiert ist?)
- Doppelklick auf die Liste bringt die Selbe Meldung
- Für was ist der leere Menüpunkt?
- unnütze bzw. nicht verwendete Variablen (Bsp. errors)

Fazit:
Wie es scheint, hast du meinen Post nicht gelesen.
Demnach bin ich der Meinung, dass du dem Release noch nicht wirklich näher gekommen bist.
 
Hi niggo!

Ich habe deinen Post gelesen, Ich habe das auch nochmal überdacht.

Bei mir funktioniert alles bestens - Ich hänge aber auch nicht an nem Router, deswegen kann Ich dazu nichts sagen, deswegen ists mir auch unerklärlich.

Die Errors beim Öffnen kommen bei mir auch nicht.

Ich bin ratlos und die Deadline rückt näher..


MfG Alexander12
 
Wenn ich morgen Zeit hab, schau ich mal, was du da machst (oder auch nicht). Kann aber sehr gut sein, dass es erst am Freitag wird *überklausurenfluch*

//EDIT:
Was aber nicht heißen soll, dass ich dein Programm schreib. DU kannst ruhig noch weiter probieren, eine Lösung zu finden ;)
 
Zuletzt bearbeitet:
Hallo!

8 Tage vor der Deadline habe Ichs noch geschafft!
Um was gehts hier eigentlich? ist das eine Abschlussarbeit?

Die deutlichere Variante:

Businesslogik (also Funktionen, Abläufe, etc.) sollten in eigene Klassen, Projekte, etc. ausgelagert werden. Das bedeutet, dass es nicht so laufen soll, dass man im GUI-Designer auf einen Button doppelklickt und dort seinen Code eingibt, der dann die Aufgabe erledigt. An dieser Stelle sollte nur der Aufruf einer Klasse stattfinden, die dann die Arbeit übernimmt und die gewünschten Daten zurückgibt.

Stichwörter
* OOP
* Object Oriented Programming
Na ja, viel "Business Logik" hat die Anwendung ja nicht, oder ;-)
Denke bei solch kleinen "Mini"-Applikationen die im RAD Stil entworfen werden und bei denen der Schwerpunkt eher auf dem lernen der API liegt als auf hochtrabend tollem Design ... sollte man es mit der "OOP" nicht übertreiben... ich denke ein Gefühl für Design von Softwaresystemen lernt man mit der Zeit in dem man grössere Projekte Inspiziert und das dort gezeigte einfach mal selbst ausprobiert... wie Erich Gamma einst sagte:
mokey see, monkey do

Gruss Tom
 
Zurück