1700464835
sr.sign（“老三”）；//我叫小三，老爸当然叫老三
1700464836
1700464837
}
1700464838
1700464839
}
1700464840
1700464841
运行结果如下所示：
1700464842
1700464843
这次考试语文最高是75，数学是78，自然是80
1700464844
1700464845
尊敬的XXX家长：
1700464846
1700464847
……
1700464848
1700464849
语文62数学65体育98自然63
1700464850
1700464851
……
1700464852
1700464853
家长签名：
1700464854
1700464855
我是排名第38名……
1700464856
1700464857
家长签名为：老三
1700464858
1700464859
通过继承确实能够解决这个问题，老爸看成绩单很开心，然后就给签字了，但现实的情况是很复杂的，可能老爸听我汇报最高成绩后，就直接乐开花了，直接签名了，后面的排名就没必要看了，或者老爸要先看排名情况，那怎么办？继续扩展？你能扩展多少个类？这还是一个比较简单的场景，一旦需要装饰的条件非常多，比如20个，你还通过继承来解决，你想象的子类有多少个？你是不是马上就要崩溃了！
1700464860
1700464861
好，你也看到通过继承情况确实出现了问题，类爆炸，类的数量激增，光写这些类不累死你才怪，而且还要想想以后维护怎么办，谁愿意接收这么一大摊本质相似的代码维护工作？并且在面向对象的设计中，如果超过两层继承，你就应该想想是不是出设计问题了，是不是应该重新找一条康庄大道了，这是经验值，不是什么绝对的，继承层次越多以后的维护成本越多，问题这么多，那怎么办？好办，我们定义一批专门负责装饰的类，然后根据实际情况来决定是否需要进行装饰，类图稍作修正，如图17-4所示。
1700464862
1700464863
1700464864
1700464865
1700464866
图17-4 增加专门的装饰类图
1700464867
1700464868
增加一个抽象类和两个实现类，其中Decorator的作用是封装SchoolReport类，如果大家还记得代理模式，那么很容易看懂这个类图，装饰类的作用也就是一个特殊的代理类，真实的执行者还是被代理的角色FouthGradeSchoolReport，如代码清单17-6所示。
1700464869
1700464870
代码清单17-6 修饰的抽象类
1700464871
1700464872
public abstract class Decorator extends SchoolReport{
1700464873
1700464874
//首先我要知道是哪个成绩单
1700464875
1700464876
private SchoolReport sr；
1700464877
1700464878
//构造函数，传递成绩单过来
1700464879
1700464880
public Decorator（SchoolReport sr）{
1700464881
1700464882
this.sr=sr；
1700464883
1700464884
}