Architecture pour débutants ou pourquoi vous n'avez pas besoin d'insérer un drapeau dans l'épée

Annotation:

1. Un exemple de l'implémentation de nouvelles fonctionnalités dans la classe en ajoutant un "flag".
2. Effets.
3. Approche alternative et comparaison des résultats.
4. Comment éviter la situation: "Overkill architectural"?
5. Le moment où vient le temps de tout changer.

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. Comme si c'était bon: nous livrons tous les deux. Nous livrons - du mot livrer la valeur ou du mot code drôle (à travers les larmes).
2. Et le mauvais: sans Vasily, le projet des kapets.

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] {
    //     , ! 
    // ,     .    ,    ,   .   !
}

L'optimisation prématurée est la racine de tout Mal!

1. La première façon est «naïve». Nous venons de le voir. Ajout d'une case à cocher. Ajout de responsabilité. Cours de gonflement.
2. La deuxième voie est l'héritage. Tout le monde connaît un mécanisme puissant pour réutiliser le code. On pourrait par exemple:
   
   • Héritez le nouveau héros avec l'arc et le héros de Dubina du héros (qui tient une épée, mais cela ne se reflète pas dans le nom de la classe de héros maintenant). Et puis dans les héritiers, remplacez les méthodes modifiées. Ce chemin est très mauvais (croyez-moi).
   • Faites de la classe de base (ou protocole) un héros et supprimez toutes les fonctionnalités associées à un type d'arme spécifique en tant qu'héritiers
     : héros avec une
     épée: héros, héros avec un arc: héros, héros avec
     Dubina: héros.
     C'est mieux, mais les noms de ces classes nous regardent en quelque sorte mécontents, farouchement et à la fois tristes et perplexes. S'ils ne regardent pas quelqu'un comme ça, alors j'essaierai d'écrire un autre article, où en plus du héros masculin ennuyeux, ils seront ...
3. La troisième voie est la séparation des responsabilités par l'injection de dépendance. Il peut s'agir d'une dépendance fermée par un protocole ou d'une fermeture (comme si elle était fermée par une signature), peu importe. L'essentiel est que la mise en œuvre de nouvelles responsabilités quitte la classe principale.

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, ça s'est avéré, des normes. Il est pratique de lire et d'étendre, mais toutes ces usines / protocoles / dépendances sont-ils un tas de frais généraux? Un code qui ne donne rien en termes de fonctionnalités, mais n'existe que pour organiser le code. "Code pour organiser le code", mgm. Faut-il vraiment clôturer ce jardin toujours et partout?

Oui, c'est une surcharge pour les fonctionnalités que les entreprises aiment tant.

La philosophie de l'épéiste ou «quand avez-vous dû régner?»

1. Homme + addiction à l'épée (besoin d'une épée);
2. Homme + addiction à un club (besoin d'un club).

1. Ajout d'un drapeau et du tout premier «si» (ou «commutateur» ou autre mécanisme de branchement) au drapeau. La situation est menaçante, mais supportable: le héros est déversé de déchets radioactifs, mais il le surmonte.
2. «if» , . . — . , - - .

1. Tu vois le drapeau?
2. Soyez un homme, bon sang! Efface le!
3. Injection de toxicomanie
4. ...
5. Bénéfice! 11