Spring-DI / DelegatedConstructor / Factory für Dummies

[Stevie]

Ich kann in diesem Bezug nur auf dieses Dokument von Miško Hevery verweisen. Dort wird anhand von simplen Beispielen (zwar in Java aber sollte kein Problem sein) erklärt, wie man bestimmte Dinge in seinem Code vermeidet (allem voran das Erstellen von neuen Objekten - simple Dinge wie z.B. Listen außen vor) und dadurch einfach zu wartenden und testbaren Code erstellt. Auch die in dem Dokument verlinkten Artikel sind sehr interessante Lektüre.

Auch lohnt es sich, diesen Vortrag von ihm zum gleichen Thema anzuschauen

[stahli]

Ok danke erst mal.

Mit dem Thema Testing tue ich mich etwas schwer. Ich habe mal zwei deutsche Seiten dazu gefunden:
http://sageniuz.wordpress.com/2010/0...ktoren-teil-1/
http://msdn.microsoft.com/de-de/magazine/dd263069.aspx
Ich denke, dass solche Tests nur sehr begrenzten Sinn machen. Jedenfalls sind die Probleme, die mir so unterkommen meist sehr komplexen Umständen geschuldet, die sich nicht mit ein paar Testobjekten reproduzieren lassen.
Mal reagiert die VCL etwas anders als erwartet (was z.B. irgendwelche Nachrichtenbehandlungen betrifft) oder in meinem Framework werden irgendwann Objekte nicht wie erwartet behandelt. Jedenfalls treten die Fehler meist nur durch eine intensive Userbedienung auf. In den Fällen dürfte ein Unittesting nicht helfen.
Das nur mal am Rande.

Interfaces zu nutzen und vielleicht auch Spring merke ich mir aber auf jeden Fall mal vor.
Muss mich aber erst noch ein bissl mehr damit beschäftigen.

In meiner Turniersoftware merke ich jetzt zumindest allmählich, dass pure Objekte noch nicht wirklich das Wahre sind. Diese irgendwo zentral zu erzeugen und dann mit Interfaces weiter zu arbeiten, stelle ich mir (inzwischen) sehr übersichtlich vor. Ich werde das Projekt jetzt erst mal zum Ende bringen und später mal eine Überarbeitung andenken.

[s.h.a.r.k]

Zitat von stahli:

Mal reagiert die VCL etwas anders als erwartet (was z.B. irgendwelche Nachrichtenbehandlungen betrifft) oder in meinem Framework werden irgendwann Objekte nicht wie erwartet behandelt. Jedenfalls treten die Fehler meist nur durch eine intensive Userbedienung auf. In den Fällen dürfte ein Unittesting nicht helfen.

Klingt irgendwie komisch... Egal, wie die Nachrichtenbehandlung abläuft, es müsste immer das selbe Ergebnis folgen, egal, wie intensiv die Userbedienung ist. Selbst, wenn du Threads mit einbaust, muss dein Konzept immer die gleichen Ergebnisse liefern, ebenso muss dein Framework immer gleich mit Objekten umgehen, eben auf abstrakte Art und Weise. Die Besonderheiten sollten imho von den Objekten selbst gehandhabt werden.

[stahli]

Es ging mir um Fehler, die bei der Weiterentwicklung meiner datensensitiven Komponenten und meines Frameworks aufgetreten sind. Entweder haben die VCL-Controls (von denen ich ableite) teilweise nicht wie erwartet funktioniert oder ich habe den Ablauf meines Frameworks an irgendeiner Stelle problematisch verändert.
Diese Probleme hätte wohl kein Unit-Testing entdeckt - denke ich. Und Probleme, die ich mit einem Unit-Testing finden könnte, habe ich eigentlich nicht und wenn, sind sie eigentlich schnell zu bereinigen.

[Stevie]

Zitat von stahli:

Es ging mir um Fehler, die bei der Weiterentwicklung meiner datensensitiven Komponenten und meines Frameworks aufgetreten sind. Entweder haben die VCL-Controls (von denen ich ableite) teilweise nicht wie erwartet funktioniert oder ich habe den Ablauf meines Frameworks an irgendeiner Stelle problematisch verändert.
Diese Probleme hätte wohl kein Unit-Testing entdeckt - denke ich. Und Probleme, die ich mit einem Unit-Testing finden könnte, habe ich eigentlich nicht und wenn, sind sie eigentlich schnell zu bereinigen.

Du arbeitest allein an deinem Sourcecode. Stell dir vor, es gibt ein Team von Entwicklern und es gibt bestimmte Spezifikationen für die unterschiedlichen Module und Klassen. Baut sich nun jeder Entwickler seine Button1 Projekte, um zu testen, ob die Klassen und Methoden das machen, was sie sollen? Ob nun TDD betrieben wird, oder erst drauflos gecodet wird und hinterher der Unittest geschrieben wird, ist dafür erstmal unerheblich. Was, wenn nun Funktionialität hinzukommt, sich Spezifikationen ändern, jemand Dinge refactored oder ein unbedarfter Azubi auf den Code losgelassen wird? Willst du deine komplette zig Millionen LoC schwere Anwendung durchtesten, um herauszufinden, ob alles noch funktioniert?

[stahli]

Ok, in Bezug auf die Teamarbeit ist das gewissermaßen schon nachvollziehbar. Damit habe ich aber (leider oder zum Glück?) keine Erfahrungen.
Die Testfälle zu organisieren ist aber sicher auch nicht trivial und kostet viel Zeit und Arbeit.

Da ich immer im eigenen Saft schmore und mit meinem eiegntlichen Projekt voran kommen will, habe ich leider wenig Zeit mich mit für mich neuen Grundlagen zu befassen. Im nächsten Leben werde ich mal bei Dir Azubi und lerne das gleich richtig.

[Uwe Raabe]

Zitat von stahli:

Da ich immer im eigenen Saft schmore und mit meinem eiegntlichen Projekt voran kommen will, habe ich leider wenig Zeit mit frü mich neuen Grundlagen zu befassen.

Dann geht es dir wie dem Bauern, der keine Zeit hat, einen Zaun zu bauen, weil er die Kühe einfangen muss...