类的组织
总体思路:
自底向上为:Weapon -> Warrior -> HeadQuarter | City -> main函数
每个司令部含有一个Warrior的vector,每个Warrior含有一个Weapon的vector。
每个City包含两个Warrior*,代表某一时刻在该城市发生战斗的两个Warrior。
Weapon类是一个interface class,派生出Arror,Sword,Bomb三个子类。
Weapon类的作用就是让武士调用发动一次攻击,并记录该攻击造成的武器磨损情况,不处理攻击对敌方与我方造成的影响
不同Weapon的多态体现在攻击力与磨损上,磨损的处理使用虚函数,攻击力的处理提供一个成员变量即可。
Warrior类也是一个 interface class, 派生出Dragon,Iceman,Ninja, Wolf, Lion五个派生类。
Warrior类的核心作用是前进(MoveForward函数)与发动一次攻击(OneAttack函数), 此外还需要收缴武器,对武器排序,报告自身情况等辅助函数。
不同Warrior的多态就比较多了:
有些是独有的行为,如逃跑(LionEscape)与偷武器(WolfSteal),这种多态的处理方法之一是将基类指针 dynamic_cast为派生类指针然后调用其方法。另一种是基类提供一个空函数体的virtual函数,由相应的派生类重写。动态类型转换的代价昂贵,这里使用方法二。
此外还有Dragon欢呼,Ninja使用Bomb不扣血等简单的多态,对这种多态的实现并不提供虚函数了,使用统一的函数 + if 判断即可。
作为Interface class, Weapon类与Warrior类均为抽象基类,其派生类的构造使用create函数。
HeadQuarter类包含多个Warrior, 每个Warrior都唯一归属一个HeadQuarter实现。
它是city类与Warrior类之间的桥梁,其主要方法为makeWarriors(制造武士) 和 logExistence(将武士登记到对应的城市,因此它也需要及时更新武士的状态)。
City类既是城市类,也是战斗类(同时包含红蓝武士的城市会发生战斗)。
City类是一个核心类,由它来调用武士的行为。不过由于题目输出的要求,LionEscape事件与 MoveForward 事件通过全局函数实现。核心方法就是doWolfSteal和doWar。
HeadQuarter类与City类的使用在main函数中。
题目链接
Gitee代码
避坑
- 尽量避免类成员变量名与局部变量的名称相同。debug很难。
- 所有类的命名风格尽量一致。不要像作者一样出现 id 与 kind 交替使用的情况。命名上要多使用前缀do,the,num,log,_一类,避免绞尽脑汁想变量名的情况。
- 尽量用智能指针。因为 new 与 delete往往不在同一个函数,delete的处理非常困难。
- 大项目不要只用单个文件。多文件组织很利于更新维护,甚至有时debug打眼一看就知道是哪个文件出的问题。
- 尽量封装。我创作之前看过一些作者的写法,恨不得全是public成员或者友元类。其实如果类的组织方式合理,少有必要声明友元。对大多数成员的处理只需要成员函数即可,完全可以声明为private。
- 大胆将接口与实现分开。例如本文提供了doWar()作为接口, War()作为实现。这种方式编译依存性低。
- 尽量使用指针和引用代替对象。传值方式能不用就不用。如果两个类之间有 has - a 的关系,那么使用指针更好。
- 大胆用extern。 本文使用extern的情况是需要main函数指定初始生命值与初始攻击力。
- 大胆用虚基类 + 多态的组合。
- 如果一个类所处的层次较低,尽量使它实现的功能最少化。例如本文的weapon类,只需向warrior类提供一个实现方法,不必指明它对武士的影响。
- vector 与 string。如果实在想不出替代的数据结构,用这两个性能其实就很好了。
- 调试、调试、调试。本文调试用了一天多的时间。调试还是逐步递进好,先找出错的大概位置,再精准的监视变量值。很多时候都是先搭出一个大致的框架,在调试的时候才能更好的明白项目需求。