Arquitetura para iniciantes ou por que você não precisa inserir uma bandeira no homem-espada

Anotação:

1. Um exemplo da implementação de novas funcionalidades na classe adicionando um "sinalizador".
2. Efeitos.
3. Abordagem alternativa e comparação de resultados.
4. Como evitar a situação: "Excesso arquitetônico"?
5. O momento em que chega a hora de mudar tudo.

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 se fosse bom: nós dois entregamos. Nós entregamos - a partir da palavra agregar valor ou da palavra código engraçado (através de lágrimas).
2. E o ruim: sem Vasily, o projeto 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] {
    //     , ! 
    // ,     .    ,    ,   .   !
}

Otimização prematura é a raiz de todo o mal!

1. A primeira maneira é "ingênua". Nós apenas o vimos. Adicionando uma caixa de seleção. Adicionando responsabilidade. Aula de inchaço.
2. A segunda maneira é herança. Todo mundo conhece um mecanismo poderoso para reutilizar código. Pode-se, por exemplo:
   
   • Herda o novo Herói com o Arco e o Herói de Dubina do Herói (que está segurando uma espada, mas isso não está refletido no nome da classe do Herói agora). E então, nos herdeiros, substitua os métodos alterados. Este caminho é muito ruim (apenas confie em mim).
   • Torne a classe base (ou protocolo) um Herói e remova todos os recursos associados a um tipo específico de arma como herdeiro
     : Herói com uma
     espada: Herói, Herói com um arco: Herói, Herói com
     Dubina: Herói.
     Isso é melhor, mas os próprios nomes dessas classes nos olham de alguma maneira descontentes, ferozmente e ao mesmo tempo tristes e perplexos. Se eles não olharem para alguém assim, tentarei escrever outro artigo, onde, além do chato herói masculino, eles serão ...
3. A terceira maneira é a separação de responsabilidades através da injeção de dependência. Pode ser uma dependência fechada por um protocolo ou um fechamento (como se estivesse fechada por uma assinatura), qualquer que seja. O principal é que a implementação de novas responsabilidades saia da classe 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, acabou, normas. É conveniente ler e expandir, mas todas essas fábricas / protocolos / dependências são um monte de despesas gerais? Um código que não fornece nada em termos de recursos, mas existe apenas para organizar o código. "Código para organizar o código", mgm. É realmente necessário cercar este jardim sempre e em qualquer lugar?

Sim, essa é uma sobrecarga para os recursos que as empresas amam tanto.

A filosofia do homem-espada ou "quando você teve que governar?"

1. Homem + dependência da espada (necessidade de espada);
2. Homem + dependência de um clube (necessidade de um clube).

1. Adicionando uma bandeira e o primeiro "se" (ou "alternar" ou outro mecanismo de ramificação) à bandeira. A situação é ameaçadora, mas suportável: o herói é derramado com lixo radioativo, mas ele o supera.
2. «if» , . . — . , - - .

1. Veja a bandeira?
2. Seja um homem, droga! Apague isso!
3. Injeção de dependência
4. ...
5. Lucro! 11