1.设计模式源自建筑学和人类学，模式结合起来可以解决更复杂的问题。
一个模式的描述应该包括4项：模式的名称，模式的目的（即要解决的问题），模式的实现方法，约束因素。
2.设计模式和面向对象是相得益彰的关系。
学习设计模式我们可以：复用解决方案；确立通用术语；提升了观察视角；
设计模式可以帮助团队提高效率，使软件更容易修改和维护，
3.设计常被认为是一种将事物放在一起的组合过程，按照这种观点，整体由部分组成，先有部分，然后才有整体的形式。
在形成整体前构建的模块，不可能有能力处理特殊的需要。
每一部分都根据自己在整体中的位置而改变，只有通过这样的过程，一个建筑才能富有生气。才能有健壮灵活的系统。
每个部分都因其存在于更大整体的背景中，而被赋予了特定的形式。
这是一个复杂化的过程，通过对整体操作将部分注入其中，而不是一小部分一小部分添加而成。整体孕育了部分，整体的形式及各个部分是同时产生的，好像胚胎的成长过程。
一种设计思想方式：开始用最简单的术语来考虑问题，然后添加更多特性。设计应该从问题的一个简陈述开始，然后通过在这个陈述中加入信息，使它更加详细复杂，这种信息应该采用模式的形式。
找出为其它模式创造了背景的模式，这些模式应作为设计的起点。
4.用模式思考
用在问题域中发现的模式进行思考，有助于获得突破性的思路，为思考指引了方向。
用模式思考的过程：
(1)找出模式
(2)按背景的创造顺序将模式排序
(1)对每个模式扩展设计
(1)添加细节
背景模式是一个经常与其它模式相关的模式，它为其它模式提供背景。背景模式或者称为最高模式，最外层模式。
一般地工厂模式等创建型模式排 在末位。因为在知道需要实例化什么对象之前，不考虑对象实例化更好。明天的事情明天说，至少对于实例化是如此。先考虑系统中需要什么，然后再去关注如何创建它们。
Bridge模式常和Adapter模式结合使用，前者使用后者，为后者创造了背景。
Facade模式与Adapter模式有很多相似处。
Bridge模式就常成为背景模式的候选了。
使用模式的另外一个优点是可以看到重用和灵活性的可能，这是仅仅陷于细节的时候根本无法看到的。
模式为我们提供了一种语言，使我们能够超越于细节之上，以实际的方式讨论背景，这样我们更可能看到问题域中的约束因素。模式有助于我们吸取其他开发人员此前了解到的经验教训。因此，它有助于创建健壮，可维护而且有生气的系统。
开始认为存在一个其实并不需要的模式，未必会有什么副作用。
三.<<设计模式解析第2版>>
1.模式应该相互配合，共同解决问题。
3.软件开发中的3个不同视角（perspective）：概念视角，规约视角，实现视角
概念视角分析对象必须有哪些操作；
规约视角标识了用来处理概念视角中所有情况所需的接口，即如何调用这些操作；
实现视角关注对于给定的规约，怎样实现这个特定情况；
在概念层次，抽象类就是其它类的占位符
五. 类图
泛化记号：实心三角前头，指向父类。使用vp时，从父类拖向子类。
1.一种是过度设计，过度分析就是分析瘫痪，过度设计的表现之一：深入研究所有的可能的方案
2.针对接口编程，而不是针对实现编程。
3.分支太多，每次增加新的分支时，必须搜遍每个分支，找出可能涉及的地方，这就是分支蔓延。
4.重用并不是使用面向对象方法的原因，降低维护成本和使代码更加灵活才是更重要的考虑因素。
5.特化技术常常会产生太深的继承层次。这会导致程序弱内聚，冗余，紧耦合，难以测试。
6.原则总是适用的，而模式只在某些场景下才适用，虽然可能模式并不完美。
7.修改代码改进结构，但并不增加新功能，这就是重构(refactoring)。
8.switch语句可能意味着应该使用抽象。
9.对象的创建和管理规则：对象应该要么构造或管理其它对象，要么使用对象，而不应该兼而有之。
10.工厂应该既关心使用哪些对象的规则，又需关心如何管理它们的规则，可能包括实例化多少对象，如何共享对象。
11.按概念性动机分类：行为型模式，结构型模式，创建型模式。
12.三层架构与MVC：
三层架构：UI、BLL(业务处理)、DAL(数据处理)和永久存储(数据库)
MVC：Model View Controller 模型－视图－控制器
它们都是从整体上策划一个项目的实现逻辑，
区别： 三层架构中没有Control层，而是由界面直接调用业务逻辑
三层架构的UI层相当于MVC中的View层
三层架构的BLL+DAL相当于MVC中的Model层， MVC中的Model层由访问数据和业务逻辑组成。而三层中典型的Model是由实体类构成的。
MVC基本原则：应用程序逻辑(主流程)写在Control里面，View做数据展示，数据模型和业务逻辑代码写在Model里面。
MVC中的 Model层也可以再细分为实体类+业务逻辑类，业务逻辑类中必然紧耦合了实体类，为了保持高内聚，这个业务逻辑类只能包含有关这一个实体类的操作。
如果把多个有关实体的业务逻辑代码写到一个类的静态方法中，则彻底做到了"低内聚紧耦合"，且把程序设计结构化了。
13.静态方法
静态方法的问题：一直占用内存，不能扩展，可维护性差。
静态方法不能被重写，会影响一部分设计思路，设计出的程序比较结构化。
静态方法不能读取对象中的非静态属性。
静态方法破坏了面向对象的多态性。
静态的方法和变量会调用时在内存生成一个唯一的标识，在物理内存中给静态一个位子,这样在调用时可以直接找到,，而且会节省内存。但是如果声明的静态过多，每一个都会在内存有一个位子，可能会报内存溢出。它们只存在于整个应用程序生命周期内。
当在多线程环境中是，静态方法还涉及到并发问题。
处理业务逻辑的代码不要写到静态方法中。被频繁调用的且和业务逻辑无关的独立功能性代码，如数学方法，推荐鼓励归类封装到静态方法中，以方便业务逻辑来调用。但是如果如果操作数据是对象，这些方法写作为对象成员方法则更合理些。
单例即是静态变量，根据程序设计的需要，单例不可过多，一个就好。其余全局数据作为成员变量放在其中，这样既没浪费内存又增强了可维护性。
从面向对象的角度上来说，应该根据该方法是否与此类实例化对象之间具有逻辑上的相关性，如果是就应该使用实例化对象，反之使用类静态方法。
从线程安全、性能、兼容性上也是选用实例化方法为宜。
14.数据结构+静态方法处理。
设计出只包含数据成员的类，然后用类静态方法处理它，这是传统的面向过程设计，这里的数据类只相当于c语言中的数据结构，而类静态方法就是一个个独立的全局函数。
如果有考虑数据对象重用的理由，则一个包含了行为的对象的重用性会更方便一些。
15.
119
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
