Diskussion:Design by Contract

Ich finde den Artikel sehr wohl verständlich. Derjenige, der ihn auf "unverständlich" gesetzt hat, hat unverständlicherweise darauf verzichtet, einen Grund anzugeben. Wenn noch einer dies liest und auch meint, der Artikel sein verständlich, möge er das "unverständlich" bitte löschen.

---

Das "unverständlich" bezog sich auf die erste Version des Artikels, daher war ich so frei, es zu entfernen.

Verständlichkeit des Artikels

Ich finde, der Artikel ist nicht sehr verständlich geschrieben. Ein paar Kommentare habe ich im Quelltext hinterlassen. --Hades 21:04, 7. Apr 2005 (CEST)

Also ich finde den Artikel gut. Der Artikel beschreibt nicht zu ausführlich und weitgehend klar was Design by Contract ist. Aufgrund von ein oder zwei unverständlichen Nebensätzen den Artikel als überarbeitungsbedürftig einzustufen kann ich nicht nachvollziehen.

"indem die Problematik der missverstandenen Schnittstellen weitgehend ausgeräumt wird."

Was ist den daran bitteschön unverständlich? Der Aufrufer einer Methode erwartet etwas anderes als das was sie tatsächlich tut. Jeder der schonmal halbwegs ernsthaft Software entwickelt hat, kennt solche Fälle.

Was den Artikel noch verbessern würde ist ein einfaches Beispiel.

--Gudi 11:16, 4. Mai 2005 (CEST)

Ich finde den Artikel sehr gut geschrieben. Grundlagen können bei diesem speziellen Thema ja wohl vorausgesetzt werden. Beispiel wäre natürlich klasse.

--Bookrunner 12:53, 13. Mai 2006 (CEST)

Ich pflichte denjenigen bei, die sagen der Artikel sei schwer zu Verstehen. Ein Grund ist wohl, dass er geschrieben ist, als versuche mein Gegenüber mir stammelnd das Prinzip von DBC zu erklären. Mehrere hintereinander folgende Sätze versuchen das besser zu beschreiben, was der Satz davor schon beschreiben sollte. Wenn man keine Vorkenntnisse im Bereich DBC hat, ist es sehr schwer das Prinzip durch diesen Artikel zu verstehen. --85.182.67.201 01:55, 4. Jan. 2007 (CET)

Da hast du Recht. Einiges ist redundant, anderes (vor allem konkrete, im Detail erklärte Praxisbeispiele) fehlt. -- Nichtich 18:54, 10. Feb. 2007 (CET)

Ich empfinde den Artikel auch als recht unverständlich. Ein Beispiel würde definitiv gut tun. Ferner sollte man auch auf die Grenzen der Expressivität von Contracts eingehen, so manche Bedingung lässt sich kaum mit den Boardmitteln ausdrücken, ist formal aber trivial beschreibbar. Darky77 04:17, 17. Feb. 2008 (CET)

Weblinks

Der Link auf http://www.aechmea.de/ scheint nicht mehr aktuell zu sein. Er führt auf eine Webseite mit fast ausschliesslich Werbelinks. -- Silwol 22:30, 19. Nov. 2007 (CET)

Stimmt. Ich habe ihn entfernt. --jpp ?! 09:17, 20. Nov. 2007 (CET)

Abschnitte

Die beiden Abschnitte "Liskov'sches Substitutionsprinzip" und "Unterklassen" behandeln die gleiche Frage und sollten daher zusammengefaßt werden. --Roerd 01:26, 8. Sep. 2008 (CEST)

Abschnitt Zusammenfassung der Vertragsbedingungen von Subklassen

Welchen Wert hat die formale Beschreibung im Abschnitt Zusammenfassung der Vertragsbedingungen von Subklassen? Entweder man ist Informatiker und kennt die Bedeutung des Symbols „→“, dann steht die gleiche Aussage in natürlicher Sprache direkt oben drüber. Oder man ist Laie, dann versteht man sowieso nicht, was der Pfeil aussagen soll. Ich schlage vor, diesen Teil des Abschnitts zu entfernen oder zumindest das Pfeilsymbol kurz einzuführen (und sei es per Link auf Implikation). --j ?! 13:05, 15. Nov. 2008 (CET)

Sprachunterstützung

Srittau, du hast meine Revision (mit der ich die Auflistung unterstützender Sprachen erweiterte) rückgängig gemacht. Als Leser des Artikels will ich wissen, welche Sprachen Design by contract unterstützen. Ich empfinde daher die Auflistung, auch deiner subjektiven Ansicht nach "unbedeutender" Sprachen, als sehr sinnvoll. Gibt es einen rationalen Grund, auf eine solche Auflistung zu verzichten, und wenn ja, welchen? Und wenn ja, warum dann gerade D und Eiffel? --Dauerbaustelle 18:43, 14. Dez. 2009 (CET)

Aus der QS

Hier sollte die Terminologie vereinheitlicht werden, momentan werden Methoden teilweise auch als Unterprogramme, Routinen, Unterroutinen bezeichnet. Vernünftig wäre eine einheitliche Verwendung des Begriffs Methode. --Herbert Klaeren (Diskussion) 10:57, 2. Apr. 2012 (CEST)

Für solche Kleinigkeiten solltest nicht die QS bemühen, sondern es einfach tun... --Sebastian.Dietrich ✉ 20:13, 2. Apr. 2012 (CEST)