一.  程序设计目标韩寒父亲
我们用三层架构做了一个网上购物系统，主要是实现网上购物基本功能与流程，并通过这次实践设计更进一步熟练掌握三层架构的使用以及它的具体含义，加强编程结构化能力。
婚姻法 房产陈僖仪 喜爱夜蒲
操作系统
Windows XP
应用软件
Visual Studio+SQL Server 2000
设备
硬件外部设备需奔腾133以上的PC机，内存需16兆以上
开发语言
C#
二.  程序设计介绍
1.程序结构
119消防日是几月几号我们为程序建立了一个名为“网上购物”的工程，主要有 个类
三.程序设计步骤
模式名称：
问题：
解决方法：
四.简单工厂模式的定义
简单工厂模式是类的创建模式，又叫做静态工厂方法（Static Factory Method）模式。简单工厂模式是由一个工厂对象决定创建出那一种产品类的实例。
五.简单工厂模式的结构
简单工厂模式涉及到工厂角、抽象产品角以及具体产品角等
三个角：
（1）工厂类（Creator）角：担任这个角的是工厂方法模式的核心，含有与应用紧
密相关的商业逻辑。工厂类在客户端的直接调用下创建产品对象，它往往由一个
具体C# 类实现。
（2）抽象产品（Product）角：担任这个角的类是工厂方法模式所创建的对象的父
类，或它们共同拥有的接口。抽象产品角可以用一个C# 接口或者C# 抽象类
实现。
（3）具体产品（Concrete Product）角：工厂方法模式所创建的任何对象都是这个角
的实例，具体产品角由一个具体C#类实现。
工厂类的示意性源代码如下所示。可以看出，这个工厂方法创建了一个新的具体产品的实例并返还给调用者。
1：Creator 类的源代码
public class Creator
{
/
/静态工厂方法
public static Product factory()男装搭配技巧
{
return new ConcreteProduct();
}
}
抽象产品角的主要目的是给所有的具体产品类提供一个共同的类型，在最简单的情况下，可以简化为一个标识接口。所谓标识接口，就是没有声明任何方法的空接口。
2：抽象角Product 接口的源代码
public interface Product
{
}
具体产品类的示意性源代码如下。
3：具体产品角ConcreteProduct 类的源代码
public class ConcreteProduct implements Product
{
public ConcreteProduct(){}
}
虽然在这个简单的示意性实现里面只给出了一个具体产品类，但是在实际应用中一般都会遇到多个具体产品类的情况。
六．模式的优点和缺点
1． 模式的优点
模式的核心是工厂类。这个类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例。而客户端则可以免除直接创建产品对象的责任，而仅仅负责“消费”产品。简单工厂模式通过这种做法实现了对责任的分割。
2． 模式的缺点
正如同在本章前面所讨论的，当产品类有复杂的多层次等级结构时，工厂类只有它自
己。以不变应万变，就是模式的缺点。这个工厂类集中了所有的产品创建逻辑，形成一个无所不知的全能类，有人把这种类叫做上帝类（God Class）。如果这个全能类代表的是农场的一个具体园丁的话，那么这个园丁就需要对所有的产品负责，成了农场的关键人物，他什么时候不能正常工作了，整个农场都要受到影响。将这么多的逻辑集中放在一个类里面的另外一个缺点是，当产品类有不同的接口种类时，工厂类需要判断在什么时候创建某种产品。这种对时机的判断和对哪一种具体产品的判断逻辑混合在一起，使得系统在将来进行功能扩展时较为困难。这一缺点在工厂方法模式中得到克服。
王菀之 张敬轩由于简单工厂模式使用静态方法作为工厂方法，而静态方法无法由子类继承，因此，工厂角无法形成基于继承的等级结构。这一缺点会在工厂方法模式中得到克服。
七．个人体会 
    设计模式实际上是良好的OO思想的一种提炼。每一种设计模式后面都体现了一种良好的OO思路，这些思路对于解决软件中常见的“change”问题有很大的适应性，而每种模式又有自己独特的解决思路，带有一定的通用性。而组合各种模式又可以解决许多常见问题。不可否认的是，还存在一些未经总结的设计模式。实际上，你自己也可以总结一些模式出来。无论怎样，设计模式仍然是面向对象，它不是新东西，也没有必要言必称设计模式—似乎不懂设计模式就落伍了，但给OO的开发者提供一个言简意赅的沟通桥梁。
设计模式告诉了我们什么是好的OO思想，思考如何更好的应用OO的思想—虽然还是那几个耳熟能详的术语：封装、继承、组合、多态。
设计模式首先是对传统的OO使用方法的矫正：如针对接口编程而不是实现；优先使用组合，而不是继承。其次是在原来理解上的突破：封装是对变化而言的，不仅仅是属性和方法的集合。类不仅是现实事物的抽象，同时它还具有责任。更有创新：依赖式注入。
模式不是万能的，也并不总能完美地解决问题，因此每种模式都包括了影响的信息。在应
用模式之前，我们必须先分析问题的情境，并评估模式的影响，再决定是否采用模式，采用哪一种模式。也就是说，理解、分析模式，和实现模式一样重要
八．建议
  (1)使用更加通俗易懂的语言解释设计模式，并用完整的代码实例辅以说明。代码的演示时间应延长点，好让学生看清，看懂代码。
    (2)在学生需要的时候给学生补充一点C#知识，有些同学专注于其他语言,对于C#也不太懂，听起课来一头雾水，这时候来点知识补充还是必要的