Java面向对象程序设计第五章

城堡游戏

即使类的设计很糟糕，也还是有可能实现一个应用程序，使之运行并完成所需的工作。一个已完成的应用程序能够运行，但并不能表明程序内部的结构是否良好。 当维护程序员想要对一个已有的软件做修改的时候，问题才会浮现出来。比如，程序员试 图纠正已有软件的缺陷，或者为其增加一些新的功能。显然，如果类的设计良好，这个任务就 可能很轻松；而如果类的设计很差，那就会变得很困难，要牵扯大量的工作。 在大的应用软件中，这样的情形在最初的实现中就会发生了。如果以不好的结构来实现软 件，那么后面的工作可能变得很复杂，整个程序可能根本无法完成，或者充满缺陷，或者花费 比实际需要多得多的时间才能完成。在现实中，一个公司通常要维护、扩展和销售一个软件很 多年，很可能今天在商店买到的软件，其最初的版本是在十多年前就开始了的。在这种情形下， 任何软件公司都不能忍受不良结构的代码。 既然很多不良设计的效果会在试图调整或扩展软件时明显地展现出来，那么就应该以调整 或扩展软件来鉴别和发现这样的不良设计。本周将使用一个叫作城堡游戏的例子，这个例子很简单，基本实现了一个基于字符的探险游戏。

程序中存在相似甚至相同的代码块，是非常低级的代码质量问题。代码复制存在的问题是，如果需要修改一个副本，那么就必须同时修改所有其他的副本，否则就存在不一致的问题。这增加了维护程序员的工作量，而且存在造成错误的潜在危险。很可能发 生的一种情况是，维护程序员看到一个副本被修改好了，就以为所有要修改的地方都已经改好 了。因为没有任何明显迹象可以表明另外还有一份一样的副本代码存在，所以很可能会遗漏还 没被修改的地方。我们从消除代码复制开始。消除代码复制的两个基本手段，就是函数和父类。

要评判某些设计比其他的设计优秀，就得定义一些在类的设计中重要的术语，以用来讨论 设计的优劣。对于类的设计来说，有两个核心术语：耦合和聚合。 耦合这个词指的是类和类之间的联系。之前的章节中提到过，程序设计的目标是一系列通过定义明确的接口通信来协同工作的类。耦合度反映了这些类联系的紧密度。我们努力要获得低的耦合度，或者叫作松耦合（loose coupling）。

耦合度决定修改应用程序的容易程度。在一个紧耦合的结构中，对一个类的修改也会导致对其他一些类的修改。这是要努力避免的，否则，一点小小的改变就可能使整个应用程序发生改变。另外，要想找到所有需要修改的地方，并一一加以修改，却是一件既困难又费时的事情。 另一方面，在一个松耦合的系统中，常常可以修改一个类，但同时不会修改其他类，而且整个程序还可以正常运作。

本周会讨论紧耦合和松耦合的例子。 聚合与程序中一个单独的单元所承担的任务的数量和种类相对应有关，它是针对类或方法 这样大小的程序单元而言的理想情况下，一个代码单元应该负责一个聚合的任务（也就是说，一个任务可以被看作是 一个逻辑单元）。一个方法应该实现一个逻辑操作，而一个类应该代表一定类型的实体。聚合理论背后的要点是重用：如果一个方法或类是只负责一件定义明确的事情，那么就很有可能在 另外不同的上下文环境中使用。遵循这个理论的一个额外的好处是，当程序某部分的代码需要 改变时，在某个代码单元中很可能会找到所有需要改变的相关代码段。

优秀的软件设计者的一个素质就是有预见性。什么是可能会改变的？什么是可以假设在软 件的生命期内不会改变的？ 在游戏的很多类中硬编码进去的一个假设是，这个游戏会是一个基于字符界面的游戏，通过终端进行输入输出，会永远是这样子吗？ 以后如果给这个游戏加上图形用户界面，加上菜单、按钮和图像，也是很有意思的一种扩展。如果这样的话，就不必再在终端上打印输出任何文字信息。还是可能保留着命令字，还是会在玩家输入帮助命令的时候显示命令字帮助文本，但是可能是显示在窗口的文字域中，而不是使用System.out.println？

可扩展性的意思就是代码的某些部分不需要经过修改就能适应将来可能的变化。

从程序中识别出框架和数据，以代码实现框架，将部分功能以数据的方式加载，这样能在很大程度上实现可扩展性。