def __dispatch_food_effect(self, food: Foods, player_tank: PlayerTank):
    self.__play_sound('add')
    if food.type == Foods.BOOM:
        for _ in self.__entities.enemy_tanks:
            self.__play_sound('bang')
        self.__total_enemy_num -= len(self.__entities.enemy_tanks)
        self.__entities.clear_enemy_tanks()
    elif food.type == Foods.CLOCK:
        for enemy_tank in self.__entities.enemy_tanks:
            enemy_tank.set_still()
    elif food.type == Foods.GUN:
        player_tank.improve_level()
    elif food.type == Foods.IRON:
        for x, y in self.__home.walls_position:
            self.__scene_elements.add(
                self.__scene_factory.create_element((x, y), SceneFactory.IRON)
            )
    elif food.type == Foods.PROTECT:
        player_tank.protected = True
    elif food.type == Foods.STAR:
        player_tank.improve_level()
        player_tank.improve_level()
    elif food.type == Foods.TANK:
        player_tank.add_health()
    self.__entities.foods.remove(food)
def __dispatch_collisions(self):
    ...
  for player_tank in self.__entities.player_tanks:
  for food in self.__entities.foods:
    collision_result = collide_rect(player_tank, food)
    if collision_result:
    self.__dispatch_food_effect(food, player_tank)
    ...

在原有的项目中，经常有需要传入各式各样的游戏资源路径参数的构造函数，对 TankGame 进行单例模式设计的改进，可以令 TankGame 存储一个 config 保存所有游戏资源的路径数据，这样在有其他类需要访问游戏资源路径参数的时候，就可以通过 TankGame().getConfig 进行访问。类似的，TankGame 也拥有一个 Screen 对象，为当前游戏窗口的唯一引用，这样就不用每个画面类都存一个 Screen 对象。
在原有的项目中，关卡加载、游戏开始、游戏结束的画面类都放在了 interfaces 这个包中，但是 GameLevel 同样作为一个画面，却放在了这个包的外头，而且画面类有固定的行为模式但没有继承关系、没有抽象，且加载资源的时候由于画面之间相互切换，导致一个界面加载了很多次，并且界面创建时需要向构造函数传入各种的游戏配置参数，十分麻烦。对此，进行的改进是：对画面进行抽象，抽象出一个 AbstractView 定义画面的通用行为模式，用一个 ViewManager 单例管理所有的画面的预加载和显示，提升了程序的工作效率
在原有的项目中，玩家坦克和敌方坦克同样是具有一些相同的行为模式（比如移动 move()、射击 shoot()、升降级和死亡），但却没有一个抽象，而且每次对象初始化都要分别传入一堆的资源文件路径，不仅不方便、而且所以改进是 Tank 就是对敌方坦克和玩家坦克的一个抽象，在创建坦克对象时由 Tankfactory 负责，TankFactory 提前装载好 Config，然后在坦克创建的时候只需指定坦克的位置和类型即可完成创建
在原有的项目中，没有区分场景元素 SceneElement 和实体 Entity，当然也没有场景元素组 SceneElementsGroup 和实体组 EntityGroup，每次访问都是对具体的游戏元素组的直接访问，一个类型的游戏元素只能放进只属于自己类型的组，这里就可以将游戏的元素区分为场景元素和实体，所有的场景元素继承抽象的场景元素类，场景元素的创建由场景元素工厂 SceneElementFactory 负责。场景元素组存储所有各类场景元素的聚集，根据传入的场景元素的类型自动判别要操作的聚集目标。实体的分类是基于概念的，但是实体组是根据实体的概念分类管理实体，根据传入的实体的类型自动判别要操作的聚集目标。
在原有的项目中，所有的游戏各个模块的处理都囊括在了主循环当中，显然这是不易于维护的，所以就把各个处理重新分配到了游戏关卡类的各个函数当中，每个函数都有对应一个职责（游戏逻辑、碰撞处理、文字渲染、画面渲染、用户事件接受、游戏终止判断），使得游戏关卡类的过程内聚。