想设计一套城建的架构模型，以几个基本的单位举例：Barrack（兵营），Army（士兵），Ship（资源船），Arena（竞技场）
我的想法是：
1：设计两个接口Buildable（可建造的）和Upgradable（可升级的），分别给出相应的skeletal implementation：AbstractBuilding和AbstractUpgrade，封装好Build和Upgrade的模板方法，子类直接用
2：业务逻辑需求，Barrack可以建造也可以升级、Arena只能建造、Ship和Army只能升级。特殊的地方在Barrack这个类，因为它可以利用AbstractBuilding和AbstractUpgrade里面的两个模板方法，但由于无法多继承，可以通过模拟多继承（内部类、聚合）的手段实现。
但是这个架构逻辑感觉很不爽，还有很多种建筑和Barrack一样是既能建造也能升级的，每一个都要通过模拟多继承来达到复用两个skeletal implementation模板方法的目的吗？
第二种构思：
1：把Upgradable做为父接口，Building继承Upgradable，AbstractBuilding继承AbstractUpgrade，这样就AbstractBuilding就有了两个模板方法，Barrack以及类似这种既能建造也能升级的建筑就OK了
2：Arena这种只能建造而不能升级的建筑，需要重写Upgrade方法，实现直接抛个UnsupportedOperationException。。这样做不知道是否合理？
这种架构感觉更不爽，只能建造的建筑都需要重写Upgrade方法。。
第三种构思：
1：新加一个抽象类AbstractUnupgradableBuilding，继承AbstractBuilding，它的作用只有一个，屏蔽Upgrade方法，重写Upgrade直接抛个UnsupportedOperationException。。
同样，这里求问合理性，父类声明了一个方法，子类覆盖屏蔽，这样是否合理？源码中有没有这种例子呢？
2：Arena继承AbstractUnupgradableBuilding，Barrack继承AbstractBuilding，Army继承AbstractUpgrade
好像挺和谐的感觉。。
求问：以上架构有没有更合理的建议？父类声明了一个方法，子类覆盖屏蔽，这样是否合理？请大牛们不吝赐教！
------解决方案--------------------
合理不合理，有时候全看你是否喜欢，当然也要看项目情况，比如规模、扩展性、可维护性……
我个人不喜欢这种子类否定父类方法的做法，主要是不太符合面向对象的思维习惯，因为父类宣布拥有某个特性，结果按照这种方式去应用子类对象的时候却不行。而且这种否定是运行期的，把错误也推迟到了运行期，不利于维护。
至于这种例子，java早期代码里面也有，但是这个做法现在基本淘汰了，因为他反映出面向对象设计时就出问题了。
------解决方案--------------------
如果太多重复重复代码，可以写个default 类，拥有所有借口的 引用，对外提供setXX接口方法，以及各个接口的调用方法。所有都继承这个父类也行！