第5周 设计原则
5.1 城堡游戏
5.2 消除代码复制
5.3 封装
5.4 可扩展性
5.5 框架加数据
5.6 类型系统
一个已完成的应用程序能够运行，但并不能表明程序内部的结构是否良好。 当维护程序员想要对一个已有的软件做修改的时候，问题才会浮现出来。
在现实中，一个公司通常要维护、扩展和销售一个软件很 多年，很可能今天在商店买到的软件，其最初的版本是在十多年前就开始了的。
在这种情形下， 任何软件公司都不能忍受不良结构的代码。 既然很多不良设计的效果会在试图调整或扩展软件时明显地展现出来，那么就应该以调整 或扩展软件来鉴别和发现这样的不良设计。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
5.1 城堡游戏
认识游戏代码
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
5.2 消除代码复制
程序中存在相似甚至相同的代码块，是非常低级的代码质量问题。
代 码复制存在的问题是，如果需要修改一个副本，那么就必须同时修改所有其他的副本，否则就 存在不一致的问题。
这增加了维护程序员的工作量，而且存在造成错误的潜在危险。很可能发 生的一种情况是一个副本被修改好了，就以为所有要修改的地方都已经改好 了。
因为没有任何明显迹象可以表明另外还有一份一样的副本代码存在，所以很可能会遗漏还 没被修改的地方。
我们从消除代码复制开始。消除代码复制的两个基本手段，就是函数和父类。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
5.3 封装
要评判某些设计比其他的设计优秀，就得定义一些在类的设计中重要的术语，以用来讨论 设计的优劣。
对于类的设计来说，有两个核心术语：耦合和聚合。
耦合这个词指的是类和类之间的联系。
之前的章节中提到过，程序设计的目标是一系列通 过定义明确的接口通信来协同工作的类。耦合度反映了这些类联系的紧密度。
我们努力要获得 低的耦合度，或者叫作松耦合（loose coupling）。
耦合度决定修改应用程序的容易程度。
在一个紧耦合的结构中，对一个类的修改也会导致 对其他一些类的修改。这是要努力避免的，否则，一点小小的改变就可能使整个应用程序发生 改变。
另外，要想找到所有需要修改的地方，并一一加以修改，却是一件既困难又费时的事情。
另一方面，在一个松耦合的系统中，常常可以修改一个类，但同时不会修改其他类，而且 整个程序还可以正常运作。
聚合与程序中一个单独的单元所承担的任务的数量和种类相对应有关，
它是针对类或方法 这样大小的程序单元而言的理想情况下，一个代码单元应该负责一个聚合的任务（也就是说，一个任务可以被看作是 一个逻辑单元）。
一个方法应该实现一个逻辑操作，而一个类应该代表一定类型的实体。
聚合 理论背后的要点是重用：如果一个方法或类是只负责一件定义明确的事情，那么就很有可能在 另外不同的上下文环境中使用。
遵循这个理论的一个额外的好处是，当程序某部分的代码需要 改变时，在某个代码单元中很可能会找到所有需要改变的相关代码段。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
5.4 可扩展性
可扩展性的意思就是代码的某些部分不需要经过修改就能适应将来可能的变化。
用接口来实现聚合
用容器表达每个方向上对应的房间
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
5.5 框架加数据
从程序中识别出框架和数据，以代码实现框架，将部分功能以数据的方式加载，这样能在很大程度上实现可扩展性。
框架加数据
以框架加数据来提高可拓展性，接口函数，
命令解析
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
5.6 类型系统
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
