Methoden für die Zukunft sinnvoll?

[Gelöschtes Mitglied 65838]

Ich hab zb eine Klasse mit setMyHandler dann könnte man theoretisch zusätzlich
removeMyHandler auch noch implementieren obwohl man es im Moment gar nicht braucht

sollte man das machen der Vollständigkeit halber oder is das sinnlos


Im Studium hat man gelernt "eine liste braucht die insert methode und die delete methode ansonsten ist es keine Liste" obwohl ich delete nie im programm aufgerufen habe

 

[kneitzel]

Die Frage ist, was Dein Ziel ist.

Wenn Dein Ziel ist, eine Liste zu schreiben, dann gehört das alles so dazu.

Aber eine Funktionalität, die nicht angefordert ist, wird in der Regel nicht geschrieben. Wenn die Anforderung irgendwann kommen sollte, dann kann man es immer noch umsetzen. Aber erst einmal ist das Ziel (bei agilem Vorgehen), dass man die Anforderungen zeitnah umsetzt.

"In der Regel" deshalb, weil wir halt Anforderungen manchmal so beschreiben, dass die Funktionalität gleich vollständig implementiert wird so wir es als für die Zukunft wichtig erachten. (Sprich: Wenn die Klasse projektübergreifend verwendet werden soll und daher in einer Library landet.)

 

[LimDul]

Eine "Schnitstelle/API" muss vollständig implementiert sein, damit sie fertig ist. Aber, und das ist der springende Punkt, was ist die Definition der Schnittstelle/API?

Definiere ich die Schnittstelle als "Ich kann Dinge hinzufügen" - dann ist sie fertig, wenn ich Dinge hinzufügen kann, entfernen gehört nicht dazu. (Vielleicht soll es auch gar nicht gehen)

Und da besteht in der Praxis die Diskrepanz zwischen Theorie und Praxis. In der Theorie aka Studium hat man oft mit theoretischen Konstrukten zu tun, wo z.B. klar ist, was dazu gehört, damit es fertig ist. Bei einer Liste ist klar, dass man da Dinge hinzufügen und entfernen können muss. Weil das Konstrukt Liste einfach allgemein ist. Aber in der Praxis ist das nicht mehr so klar. Wenn ich eine Datenstruktur baue um gewisse Daten zu behandeln, muss ich mir überlegen, welche Operationen muss ich darauf ermöglichen, welche werden gebraucht. Und genau die müssen dann implementiert und der Rest muss nicht (und sollte teilweise auch nicht) implementiert werden. Und da ist eben nicht mehr so trivial wie in der Theorie, weil es da dann oft spezielle Anforderungen gibt.

 

[temi]

Eine API sollte immer wohlüberlegt designet werden. Problematisch ist es vor allem, wenn Funktionen in die Schnittstelle gepackt wurden, die später als unbrauchbar/unnötig wieder entfernt werden sollen. Clientcode, der die Schnittstelle verwendet, kann dadurch unbrauchbar werden, wenn er eben diese Funktionen verwendet. In diesem Zusammenhang sollte vor allem auf Convenience-Funktionen verzichtet werden (und auf Methoden, die man in Zukunft "vielleicht" irgendwann mal braucht). Solche Convenience Funktionen können später bei Bedarf z. B. durch statische Utitlity-Klassen ergänzt werden. Siehe im JDK die Klasse "Collections", die verschiedene Convenience Methoden für Kollektionen bereit stellt.

Ansonsten hängt es natürlich in erster Linie von den Anforderungen an die bestimmte Klasse ab.

Im Studium hat man gelernt "eine liste braucht die insert methode und die delete methode ansonsten ist es keine Liste" obwohl ich delete nie im programm aufgerufen habe

Wenn es dein Ziel ist eine Liste zu schreiben, deren Elemente man nicht entfernen können darf, dann sollte es die Möglichkeit dazu auch nicht geben. Die o.g. Collections-Klasse bietet auch eine Methode eine UnmodifiableList<> zu erzeugen. Da darf man dann weder Hinzufügen, noch Entfernen können. Das Beispiel hinkt etwas, denn, wenn du List<> implementieren willst (was auch unmodifiable List tut), dann muss es auch deren Methoden geben, sie dürfen halt nichts tun.

 

[Gelöschtes Mitglied 65838]

ok