动力节点Java笔记 设计原则与框架思想.pdfVIP

动力节点 Java 笔记 设计原则与框架思想 前言 即使类的设计很糟糕 ，也还是有可能实现一个应用程序 ，使之运行并完成所需的 工作。一个已完成的应用程序能够运行 ，但并不能表明程序内部的结构是否良好。 当维护程序员想要对一个已有的软件做修改的时候 ，问题才会浮现出来。比如 ， 程序员试 图纠正已有软件的缺陷 ，或者为其增加一些新的功能。显然 ，如果类 的设计良好 ，这个任务就 可能很轻松 ；而如果类的设计很差 ，那就会变得很困 难 ，要牵扯大量的工作。 在大的应用软件中 ，这样的情形在最初的实现中就会 发生了。如果以不好的结构来实现软 件 ，那么后面的工作可能变得很复杂 ，整 个程序可能根本无法完成 ，或者充满缺陷 ，或者花费 比实际需要多得多的时间 才能完成。在现实中 ，一个公司通常要维护、扩展和销售一个软件很 多年 ，很 可能今天在商店买到的软件 ，其最初的版本是在十多年前就开始了的。在这种情 形下 ，任何软件公司都不能忍受不良结构的代码。 既然很多不良设计的效果会 在试图调整或扩展软件时明显地展现出来 ，那么就应该以调整 或扩展软件来鉴 别和发现这样的不良设计。 知识点 ： 面向对象程序设计的一些基本原则 ： 除代码复制 ： 相同的代码抽取封装成一个函数 消除代码复制的两个基本手段 ，就是函数和父类。 1.封装 ：降低耦合 正宗 OOP的方案 “让双方都不了解双方 ，只知道你能干嘛 ，你能给我什么 ， 你给我就好 ，我懒得自己拿” （当修改一个类时 ，另一个类不需要联动修改 ，别让一个类大量使用另一个 类的成员变量 ，别让两个类都有大量的代码和某个类的成员变量相关 ） 1. 程序设计的目标是一系列通 过定义明确的接口通信来协同工作的 类。 2. 耦合度反映了这些类联系的紧密度。 3. 我们努力要获得 低的耦合度 ，或者 叫作 [松耦合 （loose coupling ）]。 4. 耦合度决定修改应用程序的容易程度。 5. 在一个松耦合的系统中 ，常常可以修改一个类 ，但同时不会修改其 他类 ，而且 整个程序还可以正常运作。 6. 聚合与程序中一个单独的单元所承担的任务的数量和种类相对应 有关 ，它是针对类或方法 这样大小的程序单元而言的理想情况下 ，一 个代码单元应该负责一个聚合的任务（也就是说 ，一个任务可以被看作 是 一个逻辑单元 ）。 7. 一个方法应该实现一个逻辑操作 ，而一个类应该代表一定类型的实 体。 8. 聚合 理论背后的要点是重用 ：如果一个方法或类是只负责一件定 义明确的事情 ，那么就很有可能在 另外不同的上下文环境中使用。 自己的成员不要让别人来操作 ，对方需要什么 ，自己学会一个方法给他 ，别让别 人懂那么多东西 封装把流浪在外地的代码带回家管理 ：降低耦合的一个体现就素其他类不会 直接用到我的成员变量 ，他需要利用我的成员变量干嘛 ，我就干嘛 ，不让外人来 捣鼓我的东西 ，最后把结果告诉外人就行。 2.可扩展性 ： 可扩展性的意思就是代码的某些部分不需要经过修改就能适应将来可能的变化。 当添加一个可以归为同一类的类型时 ，如在一群子类中再添加一个平行子类 ， 保证其他原有的使用到这些子类对象的代码不需要变动以不变 ，应将来的 万变 优秀的软件设计者的一个素质就是有预见性。什么是可能会改变的 ？什么是可 以假设在软 件的生命期内不会改变的 ？在游戏的很多类中硬编码进去的一个 假设是 ，这个游戏会是一个基于字符界面的游戏 ，通 过终端进行输入输出 ，会 永远是这样子吗 ？以后如果给这个游戏加上图形用户界面 ，加上菜单、按钮和 图像 ，也是很有意思的一种扩展 聚合： -- 开放接口 自己能实现的自己说了算自己实现 ，然后告诉对方结果。 例如房间的门打开的方法 ，房间自己帮别人打开就行 ，置于我用手打开还是 脚打开都自己话事 ，你不用管 ，反正门是给你打开了 ，不用你动手。 用接口实现聚合给类实现新的方法 ，把具体细节彻底隐藏在该类中 ，只暴 露结果的函数接口供外界使用 ，而如何实现该方法从此于外界无关。 以后若改动优化接口里面的实现逻辑代码 ，外部调用该接口的代码无需改动 灵活性：-- 硬编码，我们不约哦 用容器实现灵活性替换掉硬编码 === HashMapKey ，