Architecture for beginners or why you do not need to insert a flag in the sword man

Annotation:

1. An example of the implementation of new functionality in the class by adding a "flag".
2. Effects.
3. Alternative approach and comparison of results.
4. How to avoid the situation: “Architectural overkill”?
5. The moment when the time comes to change everything.

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. As if good: we both deliver. We deliver - from the word deliver value or from the word funny (through tears) code.
2. And the bad one: without Vasily, the kapets project.

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

Premature optimization is the root of all evil!

1. The first way is “naive”. We just saw him. Adding a checkbox. Adding Responsibility. Swelling class.
2. The second way is inheritance. Everyone knows a powerful mechanism for reusing code. One could, for example:
   
   • To inherit the new Hero with the Bow and Hero from Dubina from the Hero (who is holding a sword, but this is not reflected in the name of the Hero class now). And then in the heirs, override the changed methods. This path is very bad (just trust me).
   • Make the base class (or protocol) a Hero, and remove all the features associated with a particular type of weapon as heirs
     : Hero with a
     sword: Hero, Hero with a bow: Hero, Hero with
     Dubina: Hero.
     This is better, but the names of these classes themselves look at us somehow displeased, fiercely and at the same time sad and perplexed. If they don’t look at someone like that, then I’ll try to write another article, where in addition to the boring masculine Hero they will be ...
3. The third way is the separation of responsibility through dependency injection. It can be a dependency closed by a protocol or a closure (as if closed by a signature), whatever. The main thing is that the implementation of new responsibilities should leave the main class.

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, it turned out, norms. It’s convenient to read and expand, but are all these factories / protocols / dependencies a bunch of overheads? A code that does not give anything in terms of features, but exists only to organize the code. "Code for organizing the code", mgm. Is it really necessary to fence this garden always and everywhere?

Yes, this is an overhead for features that business loves so much.

The philosophy of the sword-man or “when did you have to rule?”

1. Man + addiction to the sword (need for a sword);
2. Man + addiction to a club (need for a club).

1. Adding a flag and the very first “if” (or “switch”, or other branching mechanism) to the flag. The situation is threatening, but bearable: the hero is poured with radioactive waste, but he overcomes it.
2. «if» , . . — . , - - .

1. See the flag?
2. Be a man, damn it! Erase it!
3. Addiction injection
4. ...
5. Profit! 11