Architektur für Anfänger oder warum Sie keine Flagge in den Schwertkämpfer einfügen müssen

Anmerkung:

1. Ein Beispiel für die Implementierung neuer Funktionen in der Klasse durch Hinzufügen eines "Flags".
2. Auswirkungen.
3. Alternativer Ansatz und Vergleich der Ergebnisse.
4. Wie vermeide ich die Situation: „Architektonischer Overkill“?
5. Der Moment, in dem die Zeit kommt, alles zu ändern.

class Hero {
    func strike() {
        //   1
    }
    //   
}

class Hero {
    enum WeaponTypes {
        case sword:
        case club:
    }
	
    var weaponType: WeaponTypes?

    func strike() {
        guard let weaponType = weaponType else {
            assertionFailure()
            return	
        }
        //  : switch  Swift  if- -    !
        switch (weaponType) {
            case .sword: //     
            case .club:  //     
        }
    }
    //  
}

1. Als ob gut: Wir liefern beide. Wir liefern - vom Wort liefern Wert oder vom Wort lustiger (durch Tränen) Code.
2. Und der schlechte: ohne Vasily das Kapets-Projekt.

var weight: Stone {
    return meatbagWeight + pantsWeight + helmetWeight + swordWeight
}

var weight: Stone {
    //   guard let weaponType
    let weightWithoutWeapon = meatbagWeight + pantsWeight + helmetWeight
    switch (weaponType) {
        case .sword: return weightWithoutWeapon + swordWeight
        case .club:  return weightWithoutWeapon + clubWeight
    }
}

var spells: [Spells] {
    //   guard let weaponType 
    // ,   let spellsWithoutWeapon: [Spells]
    switch (weaponType) {
        case .sword:
            //  let swordSpells: [Spells]
            return spellsWithoutWeapon + swordSpells
	case .club:
            //  let clubSpells: [Spells]
            return spellsWithoutWeapon + clubSpells
    }
}

func strike() {
    //guard let weaponType
    switch (weaponType) {
        case .sword: //        weaponGrade
        case .club:  //        weaponGrade
    }
}

var weight: Stone {
    // guard let weaponType
    let weightWithoutWeapon = meatbagWeight + pantsWeight + helmetWeight
    switch (weaponType) {
        case .sword: return weightWithoutWeapon + swordWeight / grade
	case .club:  return weightWithoutWeapon + pow(clubWeight, 1 / grade)
    }
}

var spells: [Spells] {
    //     , ! 
    // ,     .    ,    ,   .   !
}

Vorzeitige Optimierung ist die Wurzel allen Übels!

1. Der erste Weg ist "naiv". Wir haben ihn gerade gesehen. Kontrollkästchen hinzufügen. Verantwortung hinzufügen. Schwellungsklasse.
2. Der zweite Weg ist die Vererbung. Jeder kennt einen leistungsstarken Mechanismus zur Wiederverwendung von Code. Man könnte zum Beispiel:
   
   • Erbe den neuen Helden mit dem Bogen und den Helden von Dubina vom Helden (der ein Schwert hält, aber dies spiegelt sich jetzt nicht im Namen der Heldenklasse wider). Und dann überschreiben Sie in den Erben die geänderten Methoden. Dieser Weg ist sehr schlecht (vertrau mir einfach).
   • Machen Sie die Basisklasse (oder das Protokoll) zu einem Helden und entfernen Sie alle Merkmale, die mit einem bestimmten Waffentyp verbunden sind, als Erben
     : Held mit
     Schwert: Held, Held mit Bogen: Held, Held mit
     Dubina: Held.
     Das ist besser, aber die Namen dieser Klassen selbst sehen uns irgendwie unzufrieden, heftig und gleichzeitig traurig und ratlos an. Wenn sie jemanden so nicht ansehen, werde ich versuchen, einen weiteren Artikel zu schreiben, in dem sie zusätzlich zu dem langweiligen männlichen Helden ...
3. Der dritte Weg ist die Trennung der Verantwortung durch Abhängigkeitsinjektion. Es kann sich um eine Abhängigkeit handeln, die durch ein Protokoll geschlossen wird, oder um eine Schließung (als ob sie durch eine Signatur geschlossen wäre). Die Hauptsache ist, dass die Umsetzung neuer Verantwortlichkeiten die Hauptklasse verlassen sollte.

class Hero {
    let weapon: Weapon //   , ..    

    init (_ weapon: Weapon) { //     
        self.weapon = weapon
    }
	
    func strike() {
        weapon.strike()
    }

    var weight: Stone {
        return meatbagWeight + pantsWeight + helmetWeight + weapon.weight
    }

    var spells: [Spells] {
        //   
        return spellsWithoutWeapon + weapon.spells
    }
}

protocol Weapon {
    func strike()
    var weight: Stone {get}
    var spells: [Spells] {get}
}

class Sword: Weapon {
    func strike() {
        // ,     Hero  switch   .sword
    }

    var weight: Stone {
        // ,     Hero  switch   .sword
    }

    var spells: [Spells] {
        // ,     Hero  switch   .sword
    }
}

let lastHero = Hero()

class HeroFactory {
    static func makeSwordsman() -> Hero { // ,  static -  
        let weapon = Sword(/*  */)
        return Hero(weapon)
    }

    static func makeClubman() -> Hero {
        let weapon = Club(/*  */)
        return Hero(weapon)
    }
}

Ok, es stellte sich heraus, Normen. Es ist bequem zu lesen und zu erweitern, aber sind all diese Fabriken / Protokolle / Abhängigkeiten eine Menge Overhead? Ein Code, der keine Funktionen enthält, sondern nur zum Organisieren des Codes vorhanden ist. "Code zum Organisieren des Codes", mgm. Ist es wirklich notwendig, diesen Garten immer und überall einzuzäunen?

Ja, dies ist ein Overhead für Funktionen, die Unternehmen so sehr lieben.

Die Philosophie des Schwertkämpfers oder "Wann mussten Sie regieren?"

1. Mann + Schwertabhängigkeit (Notwendigkeit eines Schwertes);
2. Mann + Sucht nach einem Verein (Notwendigkeit eines Vereins).

1. Hinzufügen eines Flags und des allerersten "if" (oder "switch" oder eines anderen Verzweigungsmechanismus) zum Flag. Die Situation ist bedrohlich, aber erträglich: Der Held wird mit radioaktivem Abfall übergossen, aber er überwindet ihn.
2. «if» , . . — . , - - .

1. Sehen Sie die Flagge?
2. Sei ein Mann, verdammt! Lösche es!
3. Suchtinjektion
4. ...
5. Gewinn! 11