Stellen Sie sich vor, Sie würden herausfinden, ob sich zwei Formen schneiden. Ein Schnittpunkt zweier Formen kann entweder eine andere Form oder nichts sein. Wenn es keine intersects(Shape) -Methode in Shape gibt, dann wäre, glaube ich, die richtige objektorientierte Lösung:
In% JDK ist Optional eine Klasse final , keine Schnittstelle. Um Probleme wie diese richtig zu lösen, schreibe ich meine eigene Maybe -Schnittstelle, die wie folgt aussehen wird:
Welche Vorbehalte gibt es, wenn ich mich an diese Lösung halte, wenn ich optionales Verhalten brauche? Diese Aufgabe scheint auch ziemlich universell zu sein. Erfinde ich das Rad hier neu und stelle meine eigene Maybe -Schnittstelle vor?
Ich sollte hinzufügen, dass der ganze Aufwand bei einer separaten Klasse und Schnittstelle darin besteht, das Verhalten mit statischen Methoden zu umgehen.
int s berechnen. Manchmal ist es nicht definiert. Würden Sie also Maybe<Integer> implementieren? Und dann eine andere Implementierung für z.B. nCr ( x , y )?
Das klingt falsch, oder? Das Problem ist, dass du den Ursprung der Sache (Schnittpunkt, Macht, wähle) an die Sache selbst bindest. Aber ein Schnittpunkt von zwei Shape s ist nichts anderes als ein Shape wieder (oder gar nichts, was schön dargestellt werden kann mit Optional . Oder noch besser mit null ; Nenn mich einfach Old School ).
Der OO-Ansatz ergibt hier keinen Sinn, da es kein neues Objekt gibt. 2 2 ist genau dasselbe wie nCr (4, 1) und beide sind genau von der gleichen Art wie 4.
Eine andere Sache ist, dass Sie den Konstruktor ShapesIntersection aufrufen müssen. Dies ist eigentlich ein statischer Aufruf, also können Sie stattdessen auch eine statische Hilfsmethode schreiben.
Die Erweiterung von Shape um einige IntersectableShape könnte sinnvoll sein. Es gibt Fälle, in denen einige Operationen für solch eine Sache üblich sind, siehe z.B. FluentIterable , aber ich bezweifle, dass Sie das machen würden viele Kreuzungen.
Sie erfinden das Rad hier neu. Der Grund dafür, dass "Optional" endgültig ist, liegt darin, dass es eigentlich keinen Grund gibt, sie zu ändern, und dass die interne Semantik eine konsistente Nutzung erfordert.
Das eigentliche Problem ist die Logik Ihres Konstruktors. Sie sollten keinen Konstruktor verwenden, um die Logik der Schnittmenge zu bestimmen. Was Sie wollen, ist eine (statische?) Methode, die die Berechnung für Sie durchführt und das entsprechende Optional zurückgibt.
%Vor% Beachten Sie, dass die Optional.empty() und Optional.of(....) sind Factory-Methoden, die entsprechende Methoden erstellen Instanzen des Optional. Java 8-Streams, -Funktionen und andere unterstützende Strukturen verwenden eine Reihe von statischen Factory-Methoden, um Instanzen dieser ansonsten endgültigen Klassen zu erstellen.