Arquitectura para principiantes o por qué no necesita insertar una bandera en el hombre espada

Anotación:

1. Un ejemplo de la implementación de una nueva funcionalidad en la clase agregando una "bandera".
2. Efectos.
3. Enfoque alternativo y comparación de resultados.
4. ¿Cómo evitar la situación: "exceso arquitectónico"?
5. El momento en que llega el momento de cambiarlo todo.

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. Como si fuera bueno: los dos cumplimos. Entregamos: desde la palabra entregar valor o desde la palabra código divertido (a través de las lágrimas).
2. Y el malo: sin Vasily, el proyecto de 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] {
    //     , ! 
    // ,     .    ,    ,   .   !
}

¡La optimización temprana es la raíz de todo mal!

1. La primera forma es "ingenua". Acabamos de verlo. Agregar una casilla de verificación. Agregar responsabilidad. Clase de hinchazón
2. La segunda forma es la herencia. Todos conocen un mecanismo poderoso para reutilizar el código. Uno podría, por ejemplo:
   
   • Heredar el nuevo Héroe con el Arco y el Héroe de Dubina del Héroe (que sostiene una espada, pero esto no se refleja en el nombre de la clase Héroe ahora). Y luego, en los herederos, anule los métodos modificados. Este camino es muy malo (solo confía en mí).
   • Convierta a la clase base (o protocolo) en un Héroe, y elimine todas las características asociadas con un tipo específico de arma como herederos
     : Héroe con
     espada: Héroe, Héroe con arco: Héroe, Héroe con
     Dubina: Héroe.
     Esto es mejor, pero los nombres de estas clases nos miran de alguna manera disgustados, feroces y al mismo tiempo tristes y perplejos. Si no miran a alguien así, entonces intentaré escribir otro artículo, donde además del aburrido héroe masculino serán ...
3. La tercera forma es la separación de responsabilidades a través de la inyección de dependencia. Puede ser una dependencia cerrada por un protocolo o un cierre (como si estuviera cerrado por una firma), lo que sea. Lo principal es que la implementación de nuevas responsabilidades debe abandonar la clase principal.

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, resultó, normas. Es conveniente leer y expandir, pero ¿son todas estas fábricas / protocolos / dependencias un montón de gastos generales? Un código que no da nada en términos de características, pero existe solo para organizar el código. "Código para organizar el código", mgm. ¿Es realmente necesario cercar este jardín siempre y en todas partes?

Sí, esta es una sobrecarga para las características que a las empresas les encantan.

La filosofía del hombre espada o "¿cuándo tuviste que gobernar?"

1. Hombre + adicción a la espada (necesidad de una espada);
2. Hombre + adicción a un club (necesidad de un club).

1. Agregar una bandera y el primer "si" (o "interruptor" u otro mecanismo de ramificación) a la bandera. La situación es amenazante, pero soportable: el héroe se vierte con desechos radiactivos, pero lo supera.
2. «if» , . . — . , - - .

1. ¿Ves la bandera?
2. ¡Sé un hombre, maldita sea! ¡Bórralo!
3. Inyección de adicción
4. ...
5. Beneficio! 11