Funktionales Paradigma Design

Question

Ich wurde gebeten, das Design des Systems zu erfassen, das implementiert wird, indem funktionale Programmierungsprinzipien in C# angewendet werden. Voraussetzung hierfür ist, dass der Entwurf eher formalisiert wird als informelles Englisch. Außerdem ist die Verwendung von UML verboten.

Ich habe mich entschieden, F # für diese Zwecke zu verwenden, habe aber Schwierigkeiten, die Abstraktionsstufe hoch zu halten, ohne in die Neuimplementierung von allem mit F # zu gehen.

So habe ich einige Fragen:

1. Gibt es eine architektonische Rahmen/Praxis, wie funktionales Design zu beschreiben?

2. Wie kann ich Methoden ohne Implementierungsdetails verfügbar machen?

3. Wie Sie Komponentenschnittstellen in F # erstellen?

4. In OO haben Sie normalerweise verschiedene Ansichten für die Architektur (zum Beispiel 4 + 1). Gibt es so etwas für funktionales Design?

Answer 1

Für 1: Nicht, dass ich mir bewusst bin, aber ich bin nicht eine Architektur Art von Entwickler

für 2: Unten finden Sie eine Technik, die ich und wie viel nutzen.

let memoize (f : 'K -> 'V) : 'K -> 'V = 
    let dict = Dictionary<'K, 'V>() 
    fun k -> 
    match dict.TryGetValue k with 
    | true , v -> v 
    | false, _ -> 
     let v = f k 
     dict.[k] <- v 
     v 

Für 3: Was meinen Sie mit Komponentenschnittstellen?

Für 4: 4 + 1 sollte für funktionale Sprachen gültig sein, und es scheint auch sprachunabhängig zu sein.

Im Allgemeinen finde ich, dass funktionales Design mehr auf Funktionen höherer Ordnung, Trennung von Daten und Verhalten, Vorzug von Unveränderlichkeit gegenüber Veränderlichkeit und Aufhebung von Nebenwirkungen "nach oben" ausgerichtet ist (die IO Monade ist ein Beispiel dafür).

Answer 2

TLDR dreht sich alles um Zusammensetzung.

Alles, was Sie benötigen, um HKT zu verwenden (denken Sie an sie als Generic Generics) ist vor allem ein großer Vorteil für Bibliotheksdesign, wenn Sie für reine funktionale Programmierung geht es grundlegend anders als die GO4 Denkweise oder das neue Modewort der Woche für Unternehmensprogrammierung.

Lerne Haskell, lerne über Monaden, Funktoren, Applikate, Monoide usw. (Hab keine Angst, du hast sie über 9000 Mal benutzt, ohne es zu merken) Dann schau in Sachen wie die Freie Monade, vergiss deine Kesselplatte, Objektive, Typklassen und MTL-Stil Transformatoren und danach wirst du ein viel besserer Bibliotheksprogrammierer sein.