1. 外观模式：应该让一个软件中的子系统间的通信和相互依赖关系达到最小,而具体办法就是引入一个外观对象,它为子系统间提供了一个单一而简单的屏障。
2. 代理与外观的主要区别在于，代理对象代表一个单一对象而外观对象代表一个子系统：代理的客户对象无法直接访问目标对象，由代理提供对单独的目标对象的访问控制，而外观的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。
3. 适配器模式：主要是为了解决两个已有接口之间不匹配的问题，我不需要考虑这些接口是怎样实现的，也不考虑它们各自可能会如何演化。不需要对两个独立设计的类中任一个进行重新设计，就能够使它们协同工作。
4. 观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
5. 状态模式：允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。
6. 代码重复是编程中最常见、最糟糕的“坏味道”，如果我们在一个以上的地方看到相同的程序结构，那么可以肯定，设法将它们合二为一，程序会变得更好。完全相同的代码当然存在明显的重复，而微妙的重复会出现在表面不同但是本质相同的结构或处理步骤中。
7. 只要是在做面向对象的开发，创建对象的工作不可避免。创建对象时，负责创建实体通常需要了解要创建的是哪个具体的对象，以及何时创建这个而非那个对象的规则。而我们如果希望遵循开放封闭原则、依赖倒转原则和里氏代换原则，那使用对象时，就不应该知道所用的是哪一个特选的对象。此时就需要“对象管理者”工厂来负责此事。
8. 所有类都有构造方法，如果不编码则系统默认生成空的构造方法，若你有定义的构造方法，那么默认的构造方法就会失效。
9. 用户是如何浏览你的网站的
a) 大部分时候用户并非在阅读屏幕上的内容，而是在扫视。 用户习惯扫视和快速寻找页面上一些能够引导他理解内容的关键点。
b) 不要考验用户的耐心
当一个页面不能满足用户的期望时，离开就在所难免。希望通过添加相关内容来丰富页面和留住用户往往效果不佳甚至适得其反。一屏页面上承载的信息越多，认知的负担就会越重，就需要花费更多的时间去处理信息，如果这些信息中还有些不是用户期望的，那就还要花额外的精力将这些多于信息从注意力中剥离。Jakbo Nielsen 的研究结论也表明：一个页面上的认识负担越重，导航和浏览就会越困难，用户离开并寻找其他替代品的可能性就越大。
c) 用户并不做最佳选择
用户并不是在搜寻找到最佳选项的最快途径，他们也并非用线性的方式来阅读屏幕上的内容（有顺序地从一个模块到另一个模块）。当用户找到第一个合理的选项，或者一旦找到了可能的目标内容，立即点击的可能性会非常大。其实，用户是在寻找能让他们觉得够用或者合适的内容，而非寻找最佳的选择，理由也很直观，让用户自己去做最佳选择需要花费不少时间和精力，那已经在考验用户的耐心了（选择即成本）。
10. 抽象类不能实例化，抽象方法是必须被子类重写的方法，如果类中包含抽象方法，那么类就必须定义为抽象类，不论是否还包含其他一般方法。抽象类拥有尽可能多的共同代码，拥有尽可能少的数据。
11. 抽象类通常代表一个抽象概念，它提供一个继承的出发点，当设计一个新的抽象类时，一定是用来继承的，所以，在一个以继承关系形成的等级结构里面，树叶节点应当是具体类，而树枝节点均应当是抽象类。
12. 抽象类可以给出一些成员的实现，接口却不包含成员的实现，抽象类的抽象成员可被子类部分实现，接口的成员需要实现类完全实现，一个类只能继承一个抽象类，但可实现多个接口等等。①类是对对象的抽象；抽象类是对类的抽象；接口是对行为的抽象。②如果行为跨越不同类的对象，可使用接口；对于一些相似的类对象，用继承抽象类。③从设计角度讲，抽象类是从子类中发现了公共的东西，泛化出父类，然后子类继承父类，而接口是根本不知子类的存大，方法如何实现还不确认，预先定义。
13. .NET Framework提供了用于数据存储和检索的专用类，这些类统称集全。这些类提供对堆栈、队列、列表和哈希表的支持。大多数集合类实现相同的接口。
14. 委托是对函数的封闭，可以当作给方法的特征指定一个名称，而事件则是委托的一种特殊形式，当发生有意义的事情时，事件对象处理通知过程。
15. 愚弄我一次，是你错；愚弄我两次，是我蠢
16. 墨菲准则 ：可能会出错的地方就一定会出错。
17. 从设计角度讲，抽象类是从子类中发现了公共的东西，泛化出父类，然后子类继承父类，而接口是根本不知子类的存大，方法如何实现还不确认，预先定义。即抽象类是自底而上抽象出来的，而接口则是自顶向下设计出来的。
18. 设计模式描述了软件设计过程中某一类常见的一般性的解决方案。
19. 原代码就是设计。
2. 代理与外观的主要区别在于，代理对象代表一个单一对象而外观对象代表一个子系统：代理的客户对象无法直接访问目标对象，由代理提供对单独的目标对象的访问控制，而外观的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。
3. 适配器模式：主要是为了解决两个已有接口之间不匹配的问题，我不需要考虑这些接口是怎样实现的，也不考虑它们各自可能会如何演化。不需要对两个独立设计的类中任一个进行重新设计，就能够使它们协同工作。
4. 观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
5. 状态模式：允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。
6. 代码重复是编程中最常见、最糟糕的“坏味道”，如果我们在一个以上的地方看到相同的程序结构，那么可以肯定，设法将它们合二为一，程序会变得更好。完全相同的代码当然存在明显的重复，而微妙的重复会出现在表面不同但是本质相同的结构或处理步骤中。
7. 只要是在做面向对象的开发，创建对象的工作不可避免。创建对象时，负责创建实体通常需要了解要创建的是哪个具体的对象，以及何时创建这个而非那个对象的规则。而我们如果希望遵循开放封闭原则、依赖倒转原则和里氏代换原则，那使用对象时，就不应该知道所用的是哪一个特选的对象。此时就需要“对象管理者”工厂来负责此事。
8. 所有类都有构造方法，如果不编码则系统默认生成空的构造方法，若你有定义的构造方法，那么默认的构造方法就会失效。
9. 用户是如何浏览你的网站的
a) 大部分时候用户并非在阅读屏幕上的内容，而是在扫视。 用户习惯扫视和快速寻找页面上一些能够引导他理解内容的关键点。
b) 不要考验用户的耐心
当一个页面不能满足用户的期望时，离开就在所难免。希望通过添加相关内容来丰富页面和留住用户往往效果不佳甚至适得其反。一屏页面上承载的信息越多，认知的负担就会越重，就需要花费更多的时间去处理信息，如果这些信息中还有些不是用户期望的，那就还要花额外的精力将这些多于信息从注意力中剥离。Jakbo Nielsen 的研究结论也表明：一个页面上的认识负担越重，导航和浏览就会越困难，用户离开并寻找其他替代品的可能性就越大。
c) 用户并不做最佳选择
用户并不是在搜寻找到最佳选项的最快途径，他们也并非用线性的方式来阅读屏幕上的内容（有顺序地从一个模块到另一个模块）。当用户找到第一个合理的选项，或者一旦找到了可能的目标内容，立即点击的可能性会非常大。其实，用户是在寻找能让他们觉得够用或者合适的内容，而非寻找最佳的选择，理由也很直观，让用户自己去做最佳选择需要花费不少时间和精力，那已经在考验用户的耐心了（选择即成本）。
10. 抽象类不能实例化，抽象方法是必须被子类重写的方法，如果类中包含抽象方法，那么类就必须定义为抽象类，不论是否还包含其他一般方法。抽象类拥有尽可能多的共同代码，拥有尽可能少的数据。
11. 抽象类通常代表一个抽象概念，它提供一个继承的出发点，当设计一个新的抽象类时，一定是用来继承的，所以，在一个以继承关系形成的等级结构里面，树叶节点应当是具体类，而树枝节点均应当是抽象类。
12. 抽象类可以给出一些成员的实现，接口却不包含成员的实现，抽象类的抽象成员可被子类部分实现，接口的成员需要实现类完全实现，一个类只能继承一个抽象类，但可实现多个接口等等。①类是对对象的抽象；抽象类是对类的抽象；接口是对行为的抽象。②如果行为跨越不同类的对象，可使用接口；对于一些相似的类对象，用继承抽象类。③从设计角度讲，抽象类是从子类中发现了公共的东西，泛化出父类，然后子类继承父类，而接口是根本不知子类的存大，方法如何实现还不确认，预先定义。
13. .NET Framework提供了用于数据存储和检索的专用类，这些类统称集全。这些类提供对堆栈、队列、列表和哈希表的支持。大多数集合类实现相同的接口。
14. 委托是对函数的封闭，可以当作给方法的特征指定一个名称，而事件则是委托的一种特殊形式，当发生有意义的事情时，事件对象处理通知过程。
15. 愚弄我一次，是你错；愚弄我两次，是我蠢
16. 墨菲准则 ：可能会出错的地方就一定会出错。
17. 从设计角度讲，抽象类是从子类中发现了公共的东西，泛化出父类，然后子类继承父类，而接口是根本不知子类的存大，方法如何实现还不确认，预先定义。即抽象类是自底而上抽象出来的，而接口则是自顶向下设计出来的。
18. 设计模式描述了软件设计过程中某一类常见的一般性的解决方案。
19. 原代码就是设计。
posted on
