Programmierung ohne if-Anweisungen?

Diese ganzen "wenn" vs "Nein, wenn" Sache, die macht mich denken, die Ausdruck Problem¹. Im Grunde, es ist eine Beobachtung, dass die Programmierung mit if-Anweisungen oder ohne if-Anweisungen ist eine Frage der Kapselung und Erweiterbarkeit, und dass manchmal es besser, verwenden Sie if-Anweisungen² und manchmal ist es besser, verwenden Sie die dynamische Disposition mit Methoden - /Funktions-Zeiger.

Wenn wir wollen, zu Modell etwas, es gibt zwei Achsen zu kümmern:

1. Den verschiedenen Fällen (oder Arten) von den Eingängen, die wir benötigen, um mit.
2. Die verschiedenen Operationen, die wir durchführen wollen, um über diese Eingänge.

Einer Weise zu implementieren, die diese Art der Sache ist mit if-Anweisungen /pattern-matching /das Besucher-Muster:

data List = Nil | Cons Int List

length xs = case xs of
  Nil -> 0
  Cons a as -> 1 + length x

concat xs ys = case ii of
  Nil -> jj
  Cons a as -> Cons a (concat as ys)

Die andere Möglichkeit ist die Verwendung von Objekt-Orientierung:

data List = {
    length :: Int
    concat :: (List -> List)
}

nil = List {
    length = 0,
    concat = (\ys -> ys)
}

cons x xs = List {
    length = 1 + length xs,
    concat = (\ys -> cons x (concat xs ys))
}

Seine nicht schwer zu sehen, dass die erste version mit if-Anweisungen erleichtert das hinzufügen neuer Operationen auf den Daten-Typ: erstellen Sie einfach eine neue Funktion und eine Fall-Analyse drin. Auf der anderen Seite, das macht es schwierig, fügen Sie neue Fälle auf unsere Daten geben denn das würde bedeuten, die wieder durch das Programm und ändern Sie alle programmzweige.

Die zweite version ist irgendwie das Gegenteil. Es ist sehr einfach zu fügen Sie neue Fälle, die für den Datentyp: erstellen Sie einfach eine neue "Klasse" und sagen, was zu tun für jede der Methoden, die wir implementieren müssen. Allerdings ist das jetzt schwer zu hinzufügen neuer Operationen der Schnittstelle, da dies bedeutet das hinzufügen einer neuen Methode für alle alten Klassen, die implementiert das interface.

Gibt es viele verschiedene Ansätze, die Sprachen benutzen, um zu versuchen zu lösen die Expression Problem und es einfach zu machen, sowohl neue Fälle und neue Vorgänge zu einem Modell. Es gibt jedoch vor-und Nachteile dieser Lösungen³ also im Allgemeinen denke ich, es ist eine gute Faustregel, um zu wählen zwischen OO und wenn Aussagen, je nachdem, welche Achse Sie wollen, um es einfacher zu erweitern Zeug.

Sowieso, gehen zurück zu Ihrer Frage gibt es paar o Dinge möchte ich hinweisen:

Die erste ist, dass ich denke, dass die OO "mantra" loszuwerden alle if-Anweisungen und ersetzen Sie Sie mit Methode Versand hat mehr damit zu tun, wie die meisten OO-Sprachen nicht typesafe Algebraische Datentypen, es hat zu tun mit "wenn statemsnts" schlecht für die Kapselung. Da der einzige Weg, um Typ-sicher ist, verwenden Sie Methode Aufrufe, die Sie ermutigt zu konvertieren Programme mit if-Anweisungen in Programmen mit der Besucher-Muster⁴ oder noch schlimmer: konvertieren Programme, die sollten mit den visitor-pattern in Programme mit einfachen Methode dispatch, wodurch die Erweiterbarkeit einfach in die falsche Richtung.

Die zweite Sache ist, dass ich nicht bin ein großer fan von Bremsen, die Dinge in die Funktionen, einfach, weil Sie können. Insbesondere finde ich, dass der Stil, wo alle Funktionen haben nur 5 Linien, und rufen Sie Tonnen von anderen Funktionen, ist ziemlich schwer zu Lesen.

Endlich, ich finde dein Beispiel nicht wirklich loswerden von if-Anweisungen. Im wesentlichen, was Sie tun, ist eine Funktion von Ganzzahlen, um einen neuen Datentyp (mit zwei Fällen, eine für Große und eine für Kleine) und Sie dann noch brauchen, um zu verwenden, wenn Aussagen, die bei der Arbeit mit dem Datentyp:

data Size = Big | Small

toSize :: Int -> Size
toSize n = if n < 10 then Small else Big

someOp :: Size -> String
someOp Small = "Wow, its small"
someOp Big   = "Wow, its big"

Gehen wir zurück zu dem Ausdruck problem Sicht, den Vorteil zu definieren, unsere toSize /isSmall Funktion ist, dass wir die Logik der Auswahl, was Fall unsere Nummer passt in einer einzigen Ort, und dass unsere Funktionen können nur auf den Fall, dass nach. Jedoch, dies bedeutet nicht, dass wir entfernt haben, wenn die Aussagen unseres code! Wenn wir die toSize wird eine factory-Funktion, und wir haben Große und Kleine werden Klassen teilen eine Schnittstelle, dann ja, wir werden entfernt haben, wenn die Aussagen von unserem code. Jedoch, wenn aus isSmall gerade gibt einen booleschen Wert zurück oder enum-dann gibt es nur so viele if-Anweisungen, als es vorher waren. (und Sie sollten entscheiden, welche Implementierung zu verwenden, je nachdem, ob Sie möchten, um es einfacher, um neue Methoden oder neue Fälle - sagen wir Mittel - in die Zukunft)

1 - Der name des Problems kommt aus dem problem, wo Sie haben eine "expression" Datentyp (zahlen, Variablen, addition/Multiplikation der Teilausdrücke, etc) und implementieren wollen, die Dinge wie die Bewertung von Funktionen und anderen Dingen.

2 - Oder pattern-matching über Algebraische Datentypen, wenn Sie mehr sein wollen geben sicher...

3 - Sie könnten Zum Beispiel festlegen, müssen alle multimethods auf der "obersten Ebene", wo der "dispatcher" sehen kann. Dies ist eine Einschränkung gegenüber dem Allgemeinen Fall, da die Sie verwenden können, wenn Aussagen (und lambdas) tief verschachtelt innerhalb anderer code.

4 - im Wesentlichen ein "Kirche-Codierung" von einem algebraischen Datentyp

Ich habe noch nie gehört, so ein Konvektion. Ich weiß nicht, wie es funktioniert, sowieso. Sicherlich der einzige Punkt, der mit einem iIsSmall ist, um später die Filiale auf der es (eventuell in Kombination mit anderen Werten)?

Was ich haben gehört, ist ein argument, um zu vermeiden, dass Variablen wie iIsSmall an alle. iIsSmall nur speichern das Ergebnis eines Tests, die Sie gemacht, so dass Sie später verwenden die Ergebnisse, um einige Entscheidung. Also warum nicht einfach testen, den Wert von i an dem Punkt, wo Sie brauchen, um die Entscheidung zu treffen? also, statt:

int i = 5; 
bool iIsSmall = isSmall(i);
...
<code>
...
if (iIsSmall) {
    <do something because i is small>
} else {
    <do something different because i is not small>
}

nur schreiben:

int i = 5
...
<code>
...
if (isSmall(i)) {
    <do something because i is small>
} else {
    <do something different because i is not small>
}

Diese Weise können Sie sagen, an der Verzweigung, was Sie tatsächlich Verzweigung auf, weil es genau dort. Das ist nicht schwer, in diesem Beispiel sowieso, aber wenn der test war kompliziert, du bist wahrscheinlich nicht in der Lage sein zu codieren, das ganze in die variable name.

Es ist auch sicherer. Es besteht keine Gefahr, dass der name iIsSmall ist irreführend, weil Sie verändert den code, so dass es wurde getestet, etwas anderes, oder weil i wurde tatsächlich verändert, nachdem Sie genannt isSmall so, dass es nicht unbedingt kleine nicht mehr, oder weil jemand nahm nur eine dumme variable name, etc, etc.

Offensichtlich funktioniert das nicht immer. Wenn die isSmall test ist teuer, und Sie müssen auf den Zweig, auf dessen Ergebnis viele Male, die Sie nicht ausführen möchten, Sie viele Male. Sie auch nicht wollen könnte, um den code duplizieren, dass viele Male rufen, es sei denn, es ist trivial. Oder möchten Sie vielleicht, um die Rückkehr der Flagge verwendet werden, die von einem Anrufer, der nicht weiß, über i (obwohl dann könnten Sie einfach zurück isSmall(i), anstatt in einer Variablen gespeichert und dann wieder die variable).

Btw, die separate Funktion speichert nichts in deinem Beispiel. Sie können (i < 10) in Zuordnung zu einem bool variable genauso einfach wie in einer return-Anweisung in einer bool Funktion. d.h. Sie könnten genauso gut schreiben bool isSmall = i < 10; - es ist diese, die verhindert, dass der if-Anweisung, nicht die separate Funktion. Code der form if (test) { x = true; } else { x = false; } oder if (test) { return true; } else { return false; } ist immer dumm, benutzen Sie einfach x = test oder return test.