Ist der semantische Vertrag einer Schnittstelle (OOP) aussagekräftiger als eine Funktionssignatur (FP)?

Einige sagen, wenn Sie SOLID-Prinzipien auf die Spitze treiben, landen Sie in der funktionalen Programmierung . Ich bin mit diesem Artikel einverstanden, aber ich denke, dass einige Semantiken beim Übergang von der Schnittstelle / dem Objekt zur Funktion / zum Abschluss verloren gehen, und ich möchte wissen, wie funktionale Programmierung den Verlust mindern kann.

Aus dem Artikel:

Wenn Sie das Prinzip der Schnittstellentrennung (ISP - Interface Segregation Principle) konsequent anwenden, sollten Sie Rollenschnittstellen gegenüber Header-Schnittstellen bevorzugen.

Wenn Sie Ihr Design in Richtung kleinerer und kleinerer Schnittstellen weiterentwickeln, erhalten Sie schließlich die ultimative Rollenschnittstelle: eine Schnittstelle mit einer einzigen Methode. Das passiert mir sehr oft. Hier ist ein Beispiel:

public interface IMessageQuery
{
    string Read(int id);
}

Wenn ich eine Abhängigkeit von einem annehme, besteht ein IMessageQueryTeil des impliziten Vertrages darin, dass ein Anruf Read(id)nach einer Nachricht mit der angegebenen ID sucht und diese zurückgibt.

Vergleichen Sie dies damit, dass Sie eine Abhängigkeit von der entsprechenden funktionalen Signatur annehmen int -> string. Ohne zusätzliche Hinweise könnte diese Funktion eine einfache sein ToString(). Wenn Sie IMessageQuery.Read(int id)mit einem implementiert haben, ToString()kann ich Sie beschuldigen, absichtlich subversiv zu sein!

Was können funktionierende Programmierer also tun, um die Semantik einer benannten Schnittstelle beizubehalten? Ist es üblich, beispielsweise einen Datensatztyp mit einem einzelnen Element zu erstellen?

type MessageQuery = {
    Read: int -> string
}

Wie Telastyn sagt, vergleichen Sie die statischen Definitionen von Funktionen:

public string Read(int id) { /*...*/ }

zu

let read (id:int) = //...

Sie haben von OOP bis FP nichts wirklich verloren.

Dies ist jedoch nur ein Teil der Geschichte, da Funktionen und Schnittstellen nicht nur in ihren statischen Definitionen erwähnt werden. Sie werden auch herumgereicht . Angenommen, unser MessageQueryCode wurde von einem anderen Code gelesen: a MessageProcessor. Dann haben wir:

public void ProcessMessage(int messageId, IMessageQuery messageReader) { /*...*/ }

Jetzt können wir den Methodennamen oder dessen Parameter nicht direkt sehen , aber wir können es sehr einfach über unsere IDE erreichen. Im Allgemeinen bedeutet die Tatsache, dass wir nicht nur eine Schnittstelle mit einer Methode, sondern eine Funktion von int an string übergeben, dass wir die dieser Funktion zugeordneten Metadaten des Parameternamens beibehalten.IMessageQuery.Readint idIMessageQueryid

Andererseits haben wir für unsere funktionale Version:

let read (id:int) (messageReader : int -> string) = // ...

Was haben wir also behalten und verloren? Nun, wir haben immer noch den Parameternamen messageReader, was wahrscheinlich den Typnamen (das Äquivalent zu IMessageQuery) überflüssig macht. Aber jetzt haben wir den Parameternamen idin unserer Funktion verloren.

Es gibt zwei Hauptwege, um dies zu umgehen:

• Erstens können Sie beim Lesen dieser Unterschrift bereits ziemlich gut erraten, was passieren wird. Indem Sie die Funktionen kurz, einfach und zusammenhängend halten und eine gute Benennung verwenden, können Sie diese Informationen viel einfacher erkennen oder finden. Sobald wir die eigentliche Funktion gelesen haben, ist sie noch einfacher.

• Zweitens wird es in vielen funktionalen Sprachen als idiomatisches Design angesehen , kleine Typen zum Umschließen von Primitiven zu erstellen. In diesem Fall ist das Gegenteil der Fall - anstatt einen Typnamen durch einen Parameternamen ( IMessageQuerybis messageReader) zu ersetzen, können wir einen Parameternamen durch einen Typnamen ersetzen. Könnte zum Beispiel intin einen Typ mit dem Namen gewickelt werden Id:

  type Id = Id of int
  

  Jetzt wird unsere readUnterschrift:

  let read (id:int) (messageReader : Id -> string) = // ...
  

  Welches ist genauso informativ wie das, was wir zuvor hatten.

  Als Randnotiz bietet uns dies auch einen Teil des Compilerschutzes, den wir in OOP hatten. Während die OOP-Version sicherstellte, dass wir IMessageQuerynicht nur irgendeine alte int -> stringFunktion übernommen haben, haben wir hier einen ähnlichen (aber unterschiedlichen) Schutz, den wir Id -> stringanstelle irgendeiner alten verwenden int -> string.

Ich würde nur ungern mit hundertprozentiger Sicherheit sagen, dass diese Techniken immer genauso gut und informativ sind wie die vollständigen Informationen, die auf einer Benutzeroberfläche verfügbar sind, aber ich denke, anhand der obigen Beispiele können Sie sagen, dass wir dies die meiste Zeit tun kann wahrscheinlich genauso gut arbeiten.

Wenn ich FP mache, neige ich dazu, spezifischere semantische Typen zu verwenden.

Zum Beispiel würde Ihre Methode für mich ungefähr so ​​aussehen:

read: MessageId -> Message

Dies kommuniziert viel mehr als der OO (/ java) ThingDoer.doThing()-Stil

Was können funktionierende Programmierer also tun, um die Semantik einer benannten Schnittstelle beizubehalten?

Verwenden Sie gut benannte Funktionen.

IMessageQuery::Read: int -> stringwird einfach ReadMessageQuery: int -> stringoder so ähnlich.

Das Wichtigste ist, dass Namen nur Verträge im weitesten Sinne des Wortes sind. Sie funktionieren nur, wenn Sie und ein anderer Programmierer dieselben Implikationen aus dem Namen ableiten und ihnen gehorchen. Aus diesem Grund können Sie wirklich jeden Namen verwenden, der dieses implizite Verhalten kommuniziert. OO und funktionale Programmierung haben ihre Namen an leicht unterschiedlichen Stellen und in leicht unterschiedlichen Formen, aber ihre Funktion ist dieselbe.

Ist der semantische Vertrag einer Schnittstelle (OOP) aussagekräftiger als eine Funktionssignatur (FP)?

Nicht in diesem Beispiel. Wie ich oben erklärt habe, ist eine einzelne Klasse / Schnittstelle mit einer einzelnen Funktion nicht aussagekräftiger als eine ähnlich gut benannte Standalone-Funktion.

Sobald Sie mehr als eine Funktion / ein Feld / eine Eigenschaft in einer Klasse erhalten, können Sie weitere Informationen über diese ableiten, da Sie deren Beziehung sehen können. Es ist fraglich, ob dies informativer ist als eigenständige Funktionen, die dieselben / ähnliche Parameter oder eigenständige Funktionen verwenden, die nach Namespace oder Modul organisiert sind.

Persönlich glaube ich nicht, dass OO selbst in komplexeren Beispielen wesentlich informativer ist.

Ich stimme nicht zu, dass eine einzelne Funktion keinen "semantischen Vertrag" haben kann. Betrachten Sie diese Gesetze für foldr:

foldr f z nil = z
foldr f z (singleton x) = f x z
foldr f z (xn <> ys) = foldr f (foldr f z ys) xn

Inwiefern ist das keine Semantik oder kein Vertrag? Sie müssen keinen Typ für einen "Foldrer" definieren, insbesondere, weil er foldrdurch diese Gesetze eindeutig bestimmt wird. Sie wissen genau, was es tun wird.

Wenn Sie eine Funktion eines Typs aufnehmen möchten, können Sie dasselbe tun:

-- The first argument `f` must satisfy for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
sort :: forall 'a. (a -> a -> bool.t) -> list.t a -> list.t a;

Sie müssen diesen Typ nur benennen und erfassen, wenn Sie denselben Vertrag mehrmals benötigen:

-- Type of functions `f` satisfying, for all x, y, z
-- > f x x = true
-- > f x y = true and f y x = true implies x = y
-- > f x y = true and f y z = true implies f x z = true
type comparison.t 'a = a -> a -> bool.t;

Die Typprüfung erzwingt nicht die Semantik, die Sie einem Typ zuweisen. Die Erstellung eines neuen Typs für jeden Vertrag ist also nur ein Boilerplate.

Nahezu alle statisch typisierten funktionalen Sprachen haben eine Möglichkeit, Basistypen so zu aliasisieren, dass Sie Ihre semantische Absicht explizit deklarieren müssen. Einige der anderen Antworten haben Beispiele gegeben. In der Praxis benötigen erfahrene Funktionsprogrammierer sehr gute Gründe für die Verwendung dieser Wrapper-Typen, da sie die Kompositionsfähigkeit und Wiederverwendbarkeit beeinträchtigen.

Angenommen, ein Client wollte eine Implementierung einer Nachrichtenabfrage, die von einer Liste unterstützt wurde. In Haskell könnte die Implementierung so einfach sein:

messages = ["Message 0", "Message 1", "Message 2"]
messageQuery = (messages !!)

Mit newtype Message = Message Stringdieser wäre viel weniger einfach sein, so dass diese Implementierung sucht so etwas wie:

messages = map Message ["Message 0", "Message 1", "Message 2"]
messageQuery (Id index) = messages !! index

Das mag nicht so schlimm erscheinen, aber entweder müssen Sie diese Art der Konvertierung überall hin und her machen , oder Sie richten eine Grenzschicht in Ihrem Code ein, in die alles, was darüber liegt Int -> String, konvertiert wird Id -> Message, um zur darunter liegenden Schicht überzugehen. Angenommen, ich wollte Internationalisierung hinzufügen oder in Großbuchstaben formatieren oder den Protokollierungskontext hinzufügen, oder was auch immer. Diese Operationen sind alle kinderleicht mit einem zu komponieren Int -> Stringund nerven mit einem Id -> Message. Es ist nicht so, dass es niemals Fälle gibt, in denen die erhöhten Typeinschränkungen wünschenswert sind, aber die Belästigung sollte den Kompromiss wert sein.

Sie können ein Typ- Synonym anstelle eines Wrappers (in Haskell typeanstelle von newtype) verwenden. Dies ist weitaus häufiger der Fall und erfordert keine allumfassenden Konvertierungen, bietet jedoch keine statischen Typgarantien wie Ihre OOP-Version. nur ein bisschen Verkapselung. Typ - Wrapper wird meist verwendet , wenn der Client nicht erwartet , dass der Wert überhaupt zu manipulieren, es ist einfach zu speichern und weitergeben zurück. Zum Beispiel ein Datei-Handle.

Nichts kann einen Kunden davon abhalten, "subversiv" zu sein. Sie erstellen nur Rahmen, durch die Sie springen können, für jeden einzelnen Kunden. Ein einfacher Schein für einen allgemeinen Komponententest erfordert oft seltsames Verhalten, das in der Produktion keinen Sinn ergibt. Deine Interfaces sollten so geschrieben sein, dass es ihnen egal ist, wenn es überhaupt möglich ist.