Chapter 10 Introduction

• Duplicate code is bad.
• Duplicate, or nearly duplicate classes are bad too.
• Inheritance and polymorphism allow us to reduce code duplication in classes.
• But first think about our buildings in Dandyland.
  • They all have a construction cost of different amounts and items.
  • They all have a worker requirement.
  • They all produce something.
  • But some make goods
  • And others change production.
• A first shot at an interface
  • CanBuild() : a static method that takes the warehouse and a building type and returns if there are resources to build that building type.
  • The constructor takes a warehouse and a type.
  • WorkersNeeded() : returns the number of people needed for the building to produce.
  • CanProduce(): takes the warehouse and returns true if it can produce anything.
  • Produce(): takes a warehouse and decreases the inventory of raw goods and increases the inventory of produced goods
  • FoodBonus(): returns the bonus to food production from this building.
  • WoodBonus(): returns the wood production bonus for this building.
  • GoldBonus(): returns the gold production bonus for this building.
• Sort of validating code

  • // defined somewhere
    enum class BuildingTypeT {FARM, LUMBERJACK, MINE, SAWMILL, MINT, KITCHEN, FACTORY}
    
    // in a SectorT
    BuildBuilding(BuildingTypeT type, WarehouseT warehouse) {
       if (BuildingT::CanBuild(type, warehouse) ) {
           BuildingT tmp = BuildingT(type,warehouse);
           myBuildings.push_back(tmp);
       }
    }
    
    DoBuildingProduction(WarehouseT w){
        freePop = population;
        for (auto buildnig: myBuildings) {
          if (building.WorkersNeeded() < freePop) {
              freePop -= building.WorkersNeeded();
              if (building.CanProduce(warehouse)) {
                  building.Produce(warehouse);
                  foodBonus += building.FoodBonus();
                  ...
              }
          }
    } 

• We could implement the building as a single class with a huge if statement all over the place.
  • Each building would hold a BuildingTypeT

  • int WorkersNeeded() {
        swtich(myType) {
            case : BuildingTypeT::FARM: return 10;
            case : BuildingTypeT::LUMBERJACK: return 15;
            ...
        }
    } 

  • This is not terribly satisfying
    • There are going to be some very large routines
    • And as the number of buildings grow, the routines are going to become more complex.
• It would be nice if we could just build a bunch of small classes to do this.

  • int FarmT::WorkersNeeded() {
        return 10;
    } 

  • Each time we needed a new building we just built the new class.
• Please ignore the "how do I have an container of different objects problem"
  • The becomes a non-problem.
• The solution is to build a hierarchy of buildings.
  • The beginning is the base class
    • BuildingT
    • This contains all of the methods and data needed for a "building"
    • Possibly some of these are not implemented.
  • Then we produce a set of derived classes to implement individual buildings.
  • These derived classes will inherit the methods and data of their parents.
  • And they can also possibly add new members of their own.
  • They can implement their own algorithms by overriding methods of the parent class.
• A pointer to any member of the hierarchy can be treated as a pointer to the base class.
• Thus we can build a container of these.
• Look at the code in this directory