3月
1
Identify Areas Likely to Change
1.找出看起来容易变化的项目
如果需求做得很好,那么其中就应该包含一份潜在变化的清单,以及其中每一项变化发生的可能性。如果需求中没有包含潜在变化,那么参考下面的“在任何项目中都容易发生变化的区域”;
2.把容易变化的项目分离出来。把第一部中找出的容易变化的组件单独划分成类,或者和其他容易法神变化的组件划分到同一个类中;
3.把看起来容易变化的项目隔离开来。设法设计好类之间的借口,使其对潜在的变化不敏感。设计好类的接口,把变化限制在类的内部,且不会影响类的外部。任何使用将会变化的类的其他类都不会察觉到变化的存在。类的接口承担保护类的隐私指责,即封装变化。
在任何项目中都容易发生变化的区域:
1. 业务规则 很容易成为软件频繁变化的根源。
2. 对硬件的依赖性。
3. 输入和输出。
4. 非标准的语言特性。
5. 困难的设计区域和构建区域。
6. 状态变量
不要使用boolean变量作为状态变量
使用访问器子程序取代对状态变量的直接检查
7. 数据量的限制
找出容易变化的区域的办法:
1. 首先找出程序中可能对用户有用的最小子集。这一子集构成系统的核心,不容易发生改变;
2. 接下来,用微小的步伐增量扩充这个系统。
3. 当考虑功能上的改变时,同样也要考虑质的变化:比如多线程安全,程序本地化等。
4.潜在的改进区域构成了系统中的潜在变化,请依据信息隐藏的原则来设计这些区域。
通过首先定义清楚核心,你可以认清哪些组件属于附加功能,这事就可以把它们提取出来,并把它们的可能改进隐藏起来。
知识来源: 《代码大全2》 P97-99
1.找出看起来容易变化的项目
如果需求做得很好,那么其中就应该包含一份潜在变化的清单,以及其中每一项变化发生的可能性。如果需求中没有包含潜在变化,那么参考下面的“在任何项目中都容易发生变化的区域”;
2.把容易变化的项目分离出来。把第一部中找出的容易变化的组件单独划分成类,或者和其他容易法神变化的组件划分到同一个类中;
3.把看起来容易变化的项目隔离开来。设法设计好类之间的借口,使其对潜在的变化不敏感。设计好类的接口,把变化限制在类的内部,且不会影响类的外部。任何使用将会变化的类的其他类都不会察觉到变化的存在。类的接口承担保护类的隐私指责,即封装变化。
在任何项目中都容易发生变化的区域:
1. 业务规则 很容易成为软件频繁变化的根源。
2. 对硬件的依赖性。
3. 输入和输出。
4. 非标准的语言特性。
5. 困难的设计区域和构建区域。
6. 状态变量
不要使用boolean变量作为状态变量
使用访问器子程序取代对状态变量的直接检查
7. 数据量的限制
找出容易变化的区域的办法:
1. 首先找出程序中可能对用户有用的最小子集。这一子集构成系统的核心,不容易发生改变;
2. 接下来,用微小的步伐增量扩充这个系统。
3. 当考虑功能上的改变时,同样也要考虑质的变化:比如多线程安全,程序本地化等。
4.潜在的改进区域构成了系统中的潜在变化,请依据信息隐藏的原则来设计这些区域。
通过首先定义清楚核心,你可以认清哪些组件属于附加功能,这事就可以把它们提取出来,并把它们的可能改进隐藏起来。
知识来源: 《代码大全2》 P97-99
Defined tags for this entry: 学习

2007年03月03日 13时23分41秒
设计构造块:启发式方法
1. 寻找显示世界中的对象 FFind Real-World Objects 相关:使用对象进行设计的步骤 2. 形成一直的抽象 Form Consistent Abstractions (在子程序接口、类接口的以及包接口的层次上进行抽象) 3. 封装实现的细节 Encapsulate Implementation Details 4. 当继承能简化设计时就继承 Inherit -- When Inheritance Simplifies the Design 5. 信息隐藏 Infor 回复 ()