工厂模式属于创建型模式，他提供一种创建对象的最佳方式，在创建对象时，我们不需要对客户端暴露创建逻辑，只需通过一个共同的接口来实现对象的创建。
介绍

意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

主要解决 ：主要解决接口选择的问题。

何时使用 ：我们明确地计划不同条件下创建不同实例时。

如何解决 ：让其子类实现工厂接口，返回的也是一个抽象的产品。

关键代码 ：创建过程在其子类执行。

优点：
 1、一个调用者想创建一个对象，只要知道其名称就可以了。
 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
 3、屏蔽产品的具体实现，调用者只关心产品的接口。

缺点 ：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。

注意事项 ：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

- 阅读剩余部分 -

 存储过程的优点：
(1) 减少网络通信量。调用一个行数不多的存储过程与直接调用SQL语句的网络通信量可能不会有很大的差别，可是如果存储过程包含上百行SQL语句，那么其性能绝对比一条一条的调用SQL语句要高得多。

(2) 执行速度更快。有两个原因：首先，在存储过程创建的时候，数据库已经对其进行了一次解析和优化。其次，存储过程一旦执行，在内存中就会保留一份这个存储过程，这样下次再执行同样的存储过程时，可以从内存中直接调用。

(3) 更强的适应性：由于存储过程对数据库的访问是通过存储过程来进行的，因此数据库开发人员可以在不改动存储过程接口的情况下对数据库进行任何改动，而这些改动不会对应用程序造成影响。

(4) 分布式工作：应用程序和数据库的编码工作可以分别独立进行，而不会相互牵制。

存储过程的写法：

--------------创建存储过程-----------------

create proc procedure_name 
( 
    @parameter type, --参数定义
)
as beginset nocount on;--是否返回受影响行数：on-否，off-是 　　
    --逻辑处理代码
end

--------------调用存储过程-----------------

--存储过程如果有参数，后面加参数格式为：@参数名=value，也可直接为参数值value
exec Procedure_name    

--------------删除存储过程-----------------

--在存储过程中能调用另外一个存储过程，而不能删除另外一个存储过程
drop procedure Procedure_name    

 上线以后的软件产品总是不可避免会出现一些超出预期的错误或异常，而软件产品的使用者大多数是普通用户，这部分人并不了解软件的内部逻辑，我们不可能要求他们提交一份详细的错误文档来帮助我们解决问题，多数情况只能依靠软件自动收集的错误信息去进行问题定位和解决，所以我们需要知道哪些数据是软件应该在出错时收集的，这些信息越精确，对我们排查错误就越有帮助：

1.产品的具体版本;
2.操作系统和Internet Explorer的版本（Windows的许多功能其实都是由Internet Explorer及其相关组件提供的，所以它的版本信息对调试图形界面程序很重要，其它系统中也如此，尽量记录系统底层中应用比较广泛的组件信息）;
3.发生崩溃的代码所处的文件名和行号;
4.字符串格式的错误信息;
5.错误类型的独特编号;
6.用户对当时所做事情的描述;
7.用户的电子邮件地址.

总结自《软件随想录》：
免责声明：出于自我保护的目的，因为规格书不可能非常完美;
作者：为规划书负责的人，如果规格书有问题，就必须要有一个人去更正其中的问题;
使用场景：设计产品时，我们需要对产品的真实使用场景进行设想，从我们的产品使用人群中选取一些有代表性的目标用户群，为每一类人群设想一个虚构的但非常典型的用户，设想的场景越是逼真生动，设计出的产品就越适合用户使用;
非目标：在一个团队做产品时，或许每个人对产品的功能的理解都不一样，如果每个人都将自己的想法做出来，必将导致时间和金钱的浪费，而且最终的产品的功能不一定就是用户都需要的，因此我们需要将那些不需要的功能列出来，以免引起争议;
概述：可以是简单的流程图，也可以是对基本架构的详细文字描述，人们在对产品的大致轮廓了解以后会更容易理解产品的细节
细节：这是规格书中最重要的部分，需要将产品需要注意的细节详细的描述出来，例如那些可能出现的情形以及对应的解决方法，还有那些需要做出设计决定的地方也必须详细的写出来;
待解决的问题：产品设计之初必然会有很多不如人意的地方，也会有一些暂时解决不了或是没有解决的问题，我们需要将这些问题标注出来，方便以后讨论解决方案;
多角度的注释：阅读规格书的人有很多的类型，每类人的理解方向和关注点都不一样，我们需要对一些有专业倾向的地方做出多种角度的注释，好方便不同的人去理解;
规格书需要与时俱进：随着产品的开发和不断的做出新的设计决定，我们的规格书也必须及时更新，规格书总是反映着一个团队对于产品开发和使用的最佳共识;