sns一个小实例,浅谈接口与继承的差异.doc

★实例： ◎◎需求： 设计一个图书馆管理系统（部分），可以借出图书和ＣＤ，但是不能借出期刊。 ◎◎设计： 方案一（请见图片１）： Book和CD具有的类型BorrowableItem，Jounal具有类型NonBorrowableItem。这似乎是完美合理的，而且是图书馆系统常用的解决方案。 这个解决方案可以工作，但这不是非常优美的，它混合了类Library的两种不同的考虑： 馆藏对象； 借出对象 方案二（请见图片１）： 针对方案一的问题，我们对该模型稍微进行改进，引入了新类LibraryItem，在继承层次上添加额外的层次。在继承层次中，我们把“可借出”协议放在独立的层次上。这是这类问题的通用解决方案。 问题是：Book和CD具有可借出的这种能力，但是却存在问题：BorrowableItem具有可以完全说明类Book和CD的能力吗？ 可借出能力可能只是它们行为的某个特征的方面，而这种行为碰巧在图书馆系统的语境中具有共性。从语义上看，把BorrowabelItem看作类Book和CD同Library交互所扮演的特定角色更加合适，而不是把BorrowabelItem看作类Book和CD的超类。 方案三（请见图片１）： 该方案中，我们引入了接口提供更加优美的解决方案。 基于接口解决方案的好处如下： Library中的每个物品都是LibraryItem――这很直观； 我们把“可借出性”分离为独立的接口Borrowable，只要需要，我们可以把它用于LiraryItem； 我们具有更少的类――5个类和1个接口，方案二却有7个类； 我们具有更少的关联――1个组合关系，3个继承关系，方案二却有2个组合关系，5个继承关系； 我们具有更加简洁的继承层次，2层； 总之，基于接口的解决方案更加简洁、灵活并且语义更好。 /////////////////////////////////////////////////////////////////////// 比如假定你需要把Book和Journal的详细资料输出为ＣＳＶ文件。我们设计的解决方案如下： 引入类CSVExporter执行XML输出； 引入接口CSVExportable，它定义了每个可输出物品同类CSVExporter工作的协议； 我们可在Book和Jounal类中引入CSVExporter接口来实现文件输出需求。 /////////////////////////////////////////////////////////////////////// 借助该解决方案，我们可以独立管理可馆藏性（组合关系）、可借出性（接口Borrowable）和可输出性（接口XMLExportable）。 ★总结： ◆接口实现的语义是“实现由…指定的契约”。 ◆继承的语义是“是一种…”。 一些类通常不应该通过继承进行关联，使用接口指定这些类的通用协议会使解决方案更加简洁、灵活和优美。