Ich glaube halt, dass es in den meisten Fällen schlechtes Design ist, wenn so etwas notwendig wird. Sei es, dass es bessere Patterns gibt oder gewisse Regeln einfach verletzt werden. Und dies bedeutet nicht, dass es generell falsch ist, solche Checks zu nutzen.
Davon kann man aber nicht ausgehen wenn es eine public-Methode ist. Das kann man vll. wenn man selbst an einem 30 Klassen Projekt sitzt und alles im Kopf hat. Wenn es dann aber mit der Klassenanzahl stark aufwärts geht und/oder noch mit mehreren Leuten entwickelt wird behältst du nie und nimmer im Kopf wer alles die speichern-Methode aufruft (es sei denn du hast ein überragendes Gedächtnis wie z.B. Sheldon Cooper ;)) und vll. unglücklicherweise null übergibt oder die auf andere Art und Weise missbraucht. Der Parameter kann auch durch irgendwelche Wechselwirkungen auf null gesetzt werden bevor er übergeben wird. Ich bin also noch nicht davon überzeugt das ein DbC-Stil „schlechtes“-Design sei.
Natürlich geht das auch mit öffentlichen Methoden. Sogar sehr erfolgreich.
Und bitte nicht dieses „das geht sicher in einem kleinen Projekt“. Ich bin nun lange genug im Geschäft. Aktuell in einem mehrjährigen Projekt mit weit über 20 Entwicklern im Durchschnitt (über mehr als 5 Jahre). Sind die Methoden sprechend und die Klassen vernünftig geschnitten, sind Methoden meist selbsterklärend.
Es gibt immer Tests, die den Code und den Aufruf einer Methode im speziellen dokumentieren.
Und wenn man dennoch „aus Versehen“ null übergibt, sollte der NPE-Stracktrace ebenfalls sprechend sein.
Ich finde sogar, dass solche Tests den Code verdrecken. Jede unnötige Zeile ist eine Zeile, die veralten kann. Gut, Du bist anderer Auffassung, was nötige Zeilen sind, aber jeder hat ja nun ein Anrecht auf seine persönliche Meinung. 
[QUOTE=Sym]Natürlich geht das auch mit öffentlichen Methoden. Sogar sehr erfolgreich.
Und bitte nicht dieses „das geht sicher in einem kleinen Projekt“. Ich bin nun lange genug im Geschäft. Aktuell in einem mehrjährigen Projekt mit weit über 20 Entwicklern im Durchschnitt (über mehr als 5 Jahre). Sind die Methoden sprechend und die Klassen vernünftig geschnitten, sind Methoden meist selbsterklärend.
Es gibt immer Tests, die den Code und den Aufruf einer Methode im speziellen dokumentieren.
Und wenn man dennoch „aus Versehen“ null übergibt, sollte der NPE-Stracktrace ebenfalls sprechend sein.
Ich finde sogar, dass solche Tests den Code verdrecken. Jede unnötige Zeile ist eine Zeile, die veralten kann. Gut, Du bist anderer Auffassung, was nötige Zeilen sind, aber jeder hat ja nun ein Anrecht auf seine persönliche Meinung. ;)[/QUOTE]
Richtig ich bin da anderer Meinung. Mag sein das du lange im Geschäft bist, das sagt jedoch nichts über deine Fähigkeiten oder die Qualität des Codes aus den du produzierst. Es freut mich auch wenn deine Klassen und Methoden hübsch benannt sind, nur trägt das hier nichts zum Thema bei. Oder heißen deine Methoden etwa „tolleMethodeDerenErsterParameterNichtNullSeinDarfUndDerenZweiterParameterImIntervallVon0Bis5LiegenMuss“?
Tests können übrigens auch veralten, das scheinst du irgendwie vergessen zu haben. Zudem werden diese in Extraklassen verwaltet und bei einer Anpassung müssen dann gleich mehrere Stellen geändert werden anstelle nur die Argumenttests in der Methode. Ich verwende beide Ansätze (Unit-Test, DbC soweit in Java möglich) in Kombination und erachte das als zielführender bzgl. einer robusten, früh fehlererkennenden Software und das auch zur Laufzeit. 
Richtig, Du weißt überhaupt nichts über meine Qualitäten im Bereich Softwareentwicklung und -architektur.
Vergessen habe ich übrigens nichts. Das Tests veralten können, halte ich für ziemlich übertrieben, da sie zumindest noch grün laufen und somit produktiven Code testen.
Aber irgendwie klingt das für mich ziemlich nach “Deine Ansicht ist aber falsch”, “Du hast hübsche Methodennamen” und “in Deinem 30 Klassenprojekt”. Heute war viel Stress. Den brauche ich nicht noch am Feierabend. Vielleicht lese ich Deine Worte auch falsch, trotzdem: Viel Spaß ohne mich in diesem Thread.
[QUOTE=Sym]Richtig, Du weißt überhaupt nichts über meine Qualitäten im Bereich Softwareentwicklung und -architektur.
Vergessen habe ich übrigens nichts. Das Tests veralten können, halte ich für ziemlich übertrieben, da sie zumindest noch grün laufen und somit produktiven Code testen.
Aber irgendwie klingt das für mich ziemlich nach “Deine Ansicht ist aber falsch”, “Du hast hübsche Methodennamen” und “in Deinem 30 Klassenprojekt”. Heute war viel Stress. Den brauche ich nicht noch am Feierabend. Vielleicht lese ich Deine Worte auch falsch, trotzdem: Viel Spaß ohne mich in diesem Thread.[/QUOTE]
Die Antwort sollte nicht so wie beschrieben klingen. Du vertrittst deinen Standpunkt, wenn er so für dich in der Praxis funktioniert ist das okay. Nur aus meiner Sichtweise heraus fehlen bisher die überzeugende Argumente weshalb er richtig/besser ist, mehr nicht.
Deine Argumente sind
[ol]
[li]Du gehst davon aus das kein Unfug übergeben wird.[/li][li]Die Dokumentation einer Methode sollte aus der Signatur hervorgehen[/li][li]Eine NPE ist schnell auffindbar[/li][li]Du hoffst das ein Objekt in keinen halbgaren Zustand gerät[/li][li]Überprüfungen von Vorbedingungen weisen auf schlechtes Design hin[/li][li]Tests veralten nicht[/li][li]Argumentprüfungen sind zu viel Code.[/li][/ol]
Ich argumentiere
[ol]
[li]Bei public-Methoden kann man sich nicht sicher sein wer diese wie verwendet, deshalb muss man sich gegen unsachgemäße Verwendung absichern.[/li][li]Die Methodensignatur enthält nur wenig Informationen über die Einschränkungen denen die übergebenen Parameter unterliegen müssen und ist somit unzureichend als Dokumentation.[/li][li]Die Prüfung von Vorbedingungen verringert Code-Bloat bei Unit-Tests, lässt einfache Unit-Tests sogar entfallen, und man kann sich bei den Tests auf das Wesentliche konzentrieren[/li][li]Vor-/Nachbedingungen funktionieren auch zur Laufzeit und Exceptions können sprechendere Messages erhalten als eine NPE irgendwo aus dem Code.[/li][li]Die Überprüfung von Vorbedingungen verhindert frühzeitig die Ausführung von z.B. kritischem Code der vll. viel weiter unten noch schlimmer explodiert.[/li][li]Mit vernünftigen Vor-/Nachbedinungen und Invarianten ist es sehr schwierig ein Objekt in einen ungültigen Zustand zu versetzen[/li][li]Tests sind Code und können genauso veralten wie anderer Code auch[/li][li]Unit-Tests testen meist nur eine kleine statische Wertemenge beschränkt auf einen bestimmten Aspekt.[/li][li]Ein grüner Unit-Test ist kein Garant für die Korrektheit des Tests. Ich denke jeder hat sich schon einmal auf Unit-Tests bei einem Refactoring verlassen und ärgerte sich danach. Wenn nicht, Glück gehabt.[/li][li]Mit Hilfe von z.B. Klasseninvarianten kann man besser über das benötigte Locking bei Multithreading nachdenken (gemeinsame Invarianten => gemeinsames Lock)[/li][li]Unit-Tests und Methoden des DbC unterstützen sich und führen zu einer noch robusteren Software und erleichtern das Beheben von Fehlern.[/li]
[/ol]
Hi,
Dann habe ich das wohl in den falschen Hals bekommen. Ich bin leider gerade auf dem Sprung, deshalb nur kurz. Ich habe nicht behauptet, dass es ok sei, ein Objekt in einen halbgaren Zustand zu bringen. Natürlich muss man hier prüfen. Allerdings sprechen solche Prüfungen häufig für ein schlechtes Design und wären mit einer anderen Struktur so meist nicht notwendig.
Bis später