4月
13
4月
12
新的环境，新的要求，也需要新的能力去配合。
现在开始，从靠近Javascipt和用户体验的角色退回到PHP开发。
从目前的工作内容来看，有喜亦忧。从程序上面编写来说，完全的面向对象思想和语法，这将促进自己在思维习惯上的扩展。但操作内容与数据太接近，主要处理后台的数据管理和分析等，比较单调和乏味。也背离了自己在半年多来对用户体验的研究优势。
经过了几天的熟悉，实际感觉与期待中的距离还比较远。对代码的熟悉基本上使用代码走查的方式进行，注释也少，文档基本等于0。好在其函数名称起的都不错，属于自说明型的。这个减少了不少的阅读压力。
从自己未来的方向来讲，也有些迷茫，不是找不到方向，而是目前可以选择的太多，我不知道自己该去如何把握。
不想了，先学习吧。从知识面的广度上想想，开卷总是有益的。
现在开始，从靠近Javascipt和用户体验的角色退回到PHP开发。
从目前的工作内容来看，有喜亦忧。从程序上面编写来说，完全的面向对象思想和语法，这将促进自己在思维习惯上的扩展。但操作内容与数据太接近，主要处理后台的数据管理和分析等，比较单调和乏味。也背离了自己在半年多来对用户体验的研究优势。
经过了几天的熟悉，实际感觉与期待中的距离还比较远。对代码的熟悉基本上使用代码走查的方式进行，注释也少，文档基本等于0。好在其函数名称起的都不错，属于自说明型的。这个减少了不少的阅读压力。
从自己未来的方向来讲，也有些迷茫，不是找不到方向，而是目前可以选择的太多，我不知道自己该去如何把握。
不想了，先学习吧。从知识面的广度上想想，开卷总是有益的。
3月
9
在卓越网购买了两本书，前天下的订单，晚上付款，今天上午拿到手上了。
一本Head First Design Patterns, 一本是代码大全（第二版），两本书前段时间都看了会电子版，不过眼睛太累了，还是纸质的要舒服，“养眼”：）
一本Head First Design Patterns, 一本是代码大全（第二版），两本书前段时间都看了会电子版，不过眼睛太累了，还是纸质的要舒服，“养眼”：）
Defined tags for this entry: 学习
3月
4
＊ 为显示世界中的对象建模
＊ 为[[抽象]]的对象建模
＊ 降低[[复杂度]]
＊ 隔离复杂度
＊ 隐藏实现细节
＊ 限制变动的影响范围
＊ 隐藏全局数据
＊ 让参数传递更顺畅
＊ 建立中心控制点
＊ 让代码更易于重用
＊ 为程序族作计划
＊ 把相关操作包装到一起
＊ 实现某种特定的[[重构]]
应该避免的类
＊ 避免创建万能类
＊ 消除无关紧要的类 （降级为其他类的成员）
＊ 避免用动词命名的类 （降级为其他类的子程序）
知识来源： 《代码大全2》 P152－156
＊ 为[[抽象]]的对象建模
＊ 降低[[复杂度]]
＊ 隔离复杂度
＊ 隐藏实现细节
＊ 限制变动的影响范围
＊ 隐藏全局数据
＊ 让参数传递更顺畅
＊ 建立中心控制点
＊ 让代码更易于重用
＊ 为程序族作计划
＊ 把相关操作包装到一起
＊ 实现某种特定的[[重构]]
应该避免的类
＊ 避免创建万能类
＊ 消除无关紧要的类 （降级为其他类的成员）
＊ 避免用动词命名的类 （降级为其他类的子程序）
知识来源： 《代码大全2》 P152－156
Defined tags for this entry: 学习
3月
4
Containment
＊ 通过包含来实现“有一个／has a”的关系
＊ 在万不得已时通过private继承来实现“有一个”的关系
＊ 警惕有超过约7个数据成员的类
Inheritance
＊ 用public继承来实现“是一个／is a”的关系
＊ 要么使用继承并进行详细说明，要么就不要用它
＊ 遵循Liskov替换原则LSP
＊ 确保只继承需要继承的部分
＊ 不要覆盖一个不可覆盖的成员函数
＊ 把公用的接口、数据及操作放到继承树中尽可能高的位置
＊ 只有一个实例的类是值得怀疑的（特例：单件模式）
＊ 只有一个派生类的基类也值得怀疑 （提前设计）
＊ 派生后覆盖了某个子程序，但在其中没有任何操作，这种情况也值得怀疑
＊ 避免让继承体系过深
＊ 尽量使用多态，避免大量的类型检查
＊ 让所有的数据都是private（而非protected）
知识来源： 《代码大全2》 P143－P148
＊ 通过包含来实现“有一个／has a”的关系
＊ 在万不得已时通过private继承来实现“有一个”的关系
＊ 警惕有超过约7个数据成员的类
Inheritance
＊ 用public继承来实现“是一个／is a”的关系
＊ 要么使用继承并进行详细说明，要么就不要用它
＊ 遵循Liskov替换原则LSP
＊ 确保只继承需要继承的部分
＊ 不要覆盖一个不可覆盖的成员函数
＊ 把公用的接口、数据及操作放到继承树中尽可能高的位置
＊ 只有一个实例的类是值得怀疑的（特例：单件模式）
＊ 只有一个派生类的基类也值得怀疑 （提前设计）
＊ 派生后覆盖了某个子程序，但在其中没有任何操作，这种情况也值得怀疑
＊ 避免让继承体系过深
＊ 尽量使用多态，避免大量的类型检查
＊ 让所有的数据都是private（而非protected）
知识来源： 《代码大全2》 P143－P148
Defined tags for this entry: 学习
3月
4
创建高质量的类，第一步，可能也是最重要的一步是创建一个好的接口。这也包括了创建一个可以通过接口来展现的合理抽象，并确保细节仍被隐藏在抽象背后。
抽象通过提供一个可以让你忽略实现细节的模型来管理复杂度，而封装则强制阻止你看到细节。
创建类的抽象接口的指导建议：
＊ 类的接口应该展现一直的抽象层次。
＊ 一定要理解类所实现的抽象是什么
＊ 提供成对的服务
＊ 把不相关的信息装一道其他类中
＊ 尽可能让接口可变成，而不是表达语义
＊ 谨防在修改时破快就口的抽象
＊ 不要添加与接口抽象不一致的公用成员
＊ 同时考虑抽象性和内聚性
良好的封装的指导建议：
＊ 尽可能地限制类和成员的可访问性
＊ 不要公开暴露成员数据
＊ 避免把私用的实现细节放入类的接口中
＊ 不要对类的使用着作出任何假设
＊ 避免使用友元类（friend class C++）
＊ 不要因为一个子程序里仅使用公用自程序，就把它归入公开接口
＊ 让阅读代码比编写代码更方便
＊ 要格外警惕从语义上破快封装性
＊ 留意过意紧密的耦合关系
知识来源：《代码大全2》 P133-143
抽象通过提供一个可以让你忽略实现细节的模型来管理复杂度，而封装则强制阻止你看到细节。
创建类的抽象接口的指导建议：
＊ 类的接口应该展现一直的抽象层次。
＊ 一定要理解类所实现的抽象是什么
＊ 提供成对的服务
＊ 把不相关的信息装一道其他类中
＊ 尽可能让接口可变成，而不是表达语义
＊ 谨防在修改时破快就口的抽象
＊ 不要添加与接口抽象不一致的公用成员
＊ 同时考虑抽象性和内聚性
良好的封装的指导建议：
＊ 尽可能地限制类和成员的可访问性
＊ 不要公开暴露成员数据
＊ 避免把私用的实现细节放入类的接口中
＊ 不要对类的使用着作出任何假设
＊ 避免使用友元类（friend class C++）
＊ 不要因为一个子程序里仅使用公用自程序，就把它归入公开接口
＊ 让阅读代码比编写代码更方便
＊ 要格外警惕从语义上破快封装性
＊ 留意过意紧密的耦合关系
知识来源：《代码大全2》 P133-143
Defined tags for this entry: 学习
3月
3
＊ 辨识对象及其属性（method && data）
＊ 确定可以对各个对象进行的操作
＊ 确定对象的哪些部分对其他对象可见——public && private
＊ 定义每个对象的公共接口public interface
这些步骤并无须以特定的顺序来完成，需迭代。
知识来源： 《代码大全2》 P88-89
＊ 确定可以对各个对象进行的操作
＊ 确定对象的哪些部分对其他对象可见——public && private
＊ 定义每个对象的公共接口public interface
这些步骤并无须以特定的顺序来完成，需迭代。
知识来源： 《代码大全2》 P88-89
Defined tags for this entry: 学习
3月
3
1. 寻找显示世界中的[[对象]] FFind Real-World Objects 相关：使用对象进行设计的步骤
2. 形成一直的抽象 Form Consistent Abstractions （在子程序接口、类接口的以及包接口的层次上进行抽象）
3. [[封装]]实现的细节 Encapsulate Implementation Details
4. 当[[继承]]能简化设计时就继承 Inherit －－ When Inheritance Simplifies the Design
5. 信息隐藏 Information Hiding （隐藏复杂度，类的接口应该尽可能少的暴露其内部工作机制）
6. 找出容易改变的区域 Identify Areas Likely to Change
7. 保持松散[[耦合]] Keep Coupling Loose （耦合标准： 规模，可见性。灵活性； 耦合种类：简单数据参数耦合，简单对象耦合，对象参数耦合，语义耦合）
8. 查阅常用的[[设计模式]] Look for Common Design Patterns
9. 高[[内聚|内聚性]] Aim for Strong Cohesion
10. 构造分层结构 Build Hierarchies
11. 严格描述类契约 Formalize Class Constracts
12. 为对象分配职责 Assign Responsibilities for Objects （每一个对象该对什么负责，这个对象应该隐藏些什么信息）
13. 为测试而设计 Design for Test
14. 避免失误 Avoid Failure
15. 有意识地选择绑定时间 Choose Binding Time Consciosly ()
16. 创建中央控制点 Make Central Points of Control
17. 考虑使用蛮力突破 Consider Using Brute Force （拿不准时，用蛮力解决 ——Butler Lampson）
18. 画一个图 draw a Diagram
19. 保持设计的模块化 Keep Your Design Modular
知识来源： 《代码大全2》 P87-110
2. 形成一直的抽象 Form Consistent Abstractions （在子程序接口、类接口的以及包接口的层次上进行抽象）
3. [[封装]]实现的细节 Encapsulate Implementation Details
4. 当[[继承]]能简化设计时就继承 Inherit －－ When Inheritance Simplifies the Design
5. 信息隐藏 Information Hiding （隐藏复杂度，类的接口应该尽可能少的暴露其内部工作机制）
6. 找出容易改变的区域 Identify Areas Likely to Change
7. 保持松散[[耦合]] Keep Coupling Loose （耦合标准： 规模，可见性。灵活性； 耦合种类：简单数据参数耦合，简单对象耦合，对象参数耦合，语义耦合）
8. 查阅常用的[[设计模式]] Look for Common Design Patterns
9. 高[[内聚|内聚性]] Aim for Strong Cohesion
10. 构造分层结构 Build Hierarchies
11. 严格描述类契约 Formalize Class Constracts
12. 为对象分配职责 Assign Responsibilities for Objects （每一个对象该对什么负责，这个对象应该隐藏些什么信息）
13. 为测试而设计 Design for Test
14. 避免失误 Avoid Failure
15. 有意识地选择绑定时间 Choose Binding Time Consciosly ()
16. 创建中央控制点 Make Central Points of Control
17. 考虑使用蛮力突破 Consider Using Brute Force （拿不准时，用蛮力解决 ——Butler Lampson）
18. 画一个图 draw a Diagram
19. 保持设计的模块化 Keep Your Design Modular
知识来源： 《代码大全2》 P87-110
Defined tags for this entry: 学习
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: 学习
2月
10
想起了高中时期的题海战术。
我还不是命题人，我还不具备创意的能力和机会。
自己磕磕碰碰也许能找到答案，但是既然能够知道已经有答案了，为什么不直接去找，然后理解之。
举一反三，我需要更多的一，也需要二来理解一，更需要三来熟悉一。所以，我需要的还不只是一。
我需要经验。
我还不是命题人，我还不具备创意的能力和机会。
自己磕磕碰碰也许能找到答案，但是既然能够知道已经有答案了，为什么不直接去找，然后理解之。
举一反三，我需要更多的一，也需要二来理解一，更需要三来熟悉一。所以，我需要的还不只是一。
我需要经验。
Defined tags for this entry: 学习
2月
8
Levels of Design
1.软件系统 Software System
2.分解为子系统或包 Division into Subsystem or Package ：
分解为数据库、用户界面、业务规则、命令解释器、报表引擎等。
目标：确定如何分解以及各个子系统如何协作。
重点：子系统之间的相互通信规则
基本原则：子系统图应该是无环图
PS：我更喜欢按功能来划分子系统，比如用户模块，业务模块，客服模块，管理模块等，而以上所谈到的数据库模块等等知识属于公用的底层模块部分。
3.分解为类 Division into Classes
目标：识别出系统中所有的类,识别接口
4.分解成子程序 Division into Routines
目标： 细化出私有函数，子程序。
也有可能再返回第3层设计
5.子程序内部的设计 Internal Routine Design
目标：具体实现。
包括编写为代码，选择算法、组织子程序内部的代码块以及编码。
知识来源： 《代码大全2》
1.软件系统 Software System
2.分解为子系统或包 Division into Subsystem or Package ：
分解为数据库、用户界面、业务规则、命令解释器、报表引擎等。
目标：确定如何分解以及各个子系统如何协作。
重点：子系统之间的相互通信规则
基本原则：子系统图应该是无环图
PS：我更喜欢按功能来划分子系统，比如用户模块，业务模块，客服模块，管理模块等，而以上所谈到的数据库模块等等知识属于公用的底层模块部分。
3.分解为类 Division into Classes
目标：识别出系统中所有的类,识别接口
4.分解成子程序 Division into Routines
目标： 细化出私有函数，子程序。
也有可能再返回第3层设计
5.子程序内部的设计 Internal Routine Design
目标：具体实现。
包括编写为代码，选择算法、组织子程序内部的代码块以及编码。
知识来源： 《代码大全2》
Defined tags for this entry: 学习
2月
8
Desirable Characteristics of a Design
1.最小的复杂度 Minimal complexity： 应该作出简单而易于理解的设计，避免“聪明的”设计，“聪明的”设计往往是难以理解的。
2.易于维护 Ease of maintenance ： 考虑做维护工作的程序员会提出的问题。
3.松散耦合 loose coupling 人那个程序各个组成部分之间关联最小。实现手法： 抽象接口，合理封装，信息隐藏等。
4.可扩展性 extensibility : 可以改动系统的一部分而不会影响到其他部分。
5. 可重用性 reusebility : 该系统组成部分能够在其他系统中使用。
6. 高扇入 high fan-in 可以让大量的类使用某个给定的类，系统可以很好的利用较低层次上的工具类。
7.底扇出 low fan-in ：一个类少使用其他的类。大于7为高扇出，导致系统复杂。
8.可移植性 protability ： 方便地移植到其他环境。
9.精简性 leanness ： 没有对于部分,关键问题： “这虽然简单，但把它加进来之后会损害什么呢?"
10.层次性 stratification ： 可以在任何层面上观察系统并得到一致性看法。可以在任意参差上观察而不需要进入其他层次。
知识来源：《代码大全2 》
1.最小的复杂度 Minimal complexity： 应该作出简单而易于理解的设计，避免“聪明的”设计，“聪明的”设计往往是难以理解的。
2.易于维护 Ease of maintenance ： 考虑做维护工作的程序员会提出的问题。
3.松散耦合 loose coupling 人那个程序各个组成部分之间关联最小。实现手法： 抽象接口，合理封装，信息隐藏等。
4.可扩展性 extensibility : 可以改动系统的一部分而不会影响到其他部分。
5. 可重用性 reusebility : 该系统组成部分能够在其他系统中使用。
6. 高扇入 high fan-in 可以让大量的类使用某个给定的类，系统可以很好的利用较低层次上的工具类。
7.底扇出 low fan-in ：一个类少使用其他的类。大于7为高扇出，导致系统复杂。
8.可移植性 protability ： 方便地移植到其他环境。
9.精简性 leanness ： 没有对于部分,关键问题： “这虽然简单，但把它加进来之后会损害什么呢?"
10.层次性 stratification ： 可以在任何层面上观察系统并得到一致性看法。可以在任意参差上观察而不需要进入其他层次。
知识来源：《代码大全2 》
Defined tags for this entry: 学习