Objektorientierte Analyse und OOP-Unterschiede im wirklichen Leben

Question

Ich versuche in der Regel, TDD mit nicht viel Analyse (keine Diagramme) zu tun, bevor ich mit der Codierung beginne. In der Regel ertappe ich mich dabei, wie ich eine Klasse in andere Klassen aufteile, um Bedenken zu trennen. Ich frage mich, ob eine tiefere Analyse das verhindern würde. Ich denke, dass die meisten OO-Analysen einige dieser Fälle nicht vorhersagen können. Was meinen Sie dazu?

Answer 1

Für mich ist die Aufteilung der Klassen normalerweise Teil eines Lernprozesses. Entweder über den Problembereich oder über den Prozess der Programmierung. Und normalerweise mache ich das während des Programmierens. Manchmal bringe ich einen oder zwei Kollegen an ein Whiteboard, um Dinge zu besprechen.

TDD sollte es Ihnen ermöglichen, sich auf das Problem zu konzentrieren, das Sie zu lösen versuchen. Die Tatsache, dass Sie beim Lösen des Problems etwas über dessen Struktur lernen, ist ein wesentlicher Bestandteil von TDD. Führen Sie keine umfangreichen Analyse-/Entwurfsprozesse im Vorfeld durch.

Answer 2

"Normalerweise muss ich eine Klasse in andere Klassen aufteilen, um die Anliegen zu trennen. Ich frage mich, ob eine tiefere Analyse dies verhindern würde. Ich denke, dass ein Großteil der OO-Analyse einige dieser Fälle nicht vorhersagen kann."

Ich habe in dieser Hinsicht ähnliche Erfahrungen gemacht. TDD hilft Ihnen, Klassen besser zu entwerfen, was ich in A&D nicht bekomme.

Ich habe jedoch festgestellt, dass eine vorherige Analyse ebenfalls sehr hilfreich ist. Es ist so, als würde man mit der Analyse das Fundament legen und dann während der Codierung ein detailliertes Design erstellen.

Bestimmte Dinge müssen einfach aus einer größeren Perspektive betrachtet werden.

Answer 3

Wenn ich ein Programmierungs-/Designprojekt beginne, habe ich meistens nicht nur eine gute Vorstellung davon, was ich anfangs tun möchte, sondern auch davon, in welche Richtung sich die Anforderungen wahrscheinlich entwickeln werden. Dies beeinflusst die Wahl der anfänglichen Funktionen (was wiederum die testgetriebene Entwicklung vorantreibt) und kann mir einen Vorwand geben, Klassen in eine Richtung aufzuteilen, von der ich denke, dass sie später nützlich sein wird.

Wenn Sie einfach anfangen, Testfälle wahllos aus der riesigen Liste von Funktionen auszuwählen, die Sie in Betracht ziehen, dann wird auch die Richtung der Entwicklung Ihrer ersten Klassen eher zufällig sein. Daher denke ich, dass es zu den Aufgaben eines erfahrenen Entwicklers gehört, die Richtungen zu Beginn sorgfältig auszuwählen - nicht unbedingt mit einer Menge formaler Analysen, aber zumindest mit dem Instinkt dafür, welche Funktionen architektonisch wichtig sein werden, wenn das Projekt wächst.

Einer der Hauptpunkte von XP und TDD ist, dass Sie nicht zu viel Zeit auf Funktionen und Richtungen verwenden wollen, die nicht von Ihren ursprünglichen Anforderungen gefordert werden, da der Kunde seine Meinung ändern wird, wenn er sieht, was Sie bis jetzt getan haben, also wollen Sie nicht zu viel Zeit damit verbringen, darüber nachzudenken. Aber ein Teil der Entwicklung Ihrer Fähigkeiten und Ihres Instinkts als Entwickler besteht darin, dass Sie Ihre Fähigkeit trainieren und ausbauen, vorherzusagen, welche unentdeckten Funktionen sich später als wichtig herausstellen könnten.

OTOH, das Versprechen von XP und Refactoring ist, dass Sie Probleme in der anfänglichen Faktorisierung des Problems beheben können, wenn die Anforderungen Sie in diese Richtung drängen. Ich denke, das ist wahr, aber Sie werden trotzdem einen wertvolleren Beitrag leisten, wenn Sie diese Entscheidungen beim ersten Mal richtig treffen können. Und es wie Glück aussehen zu lassen - "Die Tests haben mich gezwungen, es so zu faktorisieren" - ist Teil der Fähigkeit.

Answer 4

Ich denke, dass die Vorplanung eines Großteils der Klassenstruktur (und auch der verschiedenen Schnittstellen) für objektorientiertes Design/Programmierung extrem wichtig ist. Es gibt kaum ein Buch zu diesem Thema, in dem nicht zuerst das Design mithilfe der UML und anderer Modellierungsmethoden spezifiziert wird, bevor man sich an den Code macht.