迈向架构设计师之路系列—简单对象访问模式（一）

　　假设场景

　　现在假如公司要你做一个公司内部的薪资管理系统，根据职位的不同，每月的工资自然不一样，经理一月10000加上分红1000，技术人员一月5000加上200的餐补，客服一月3000，现在要是由你来做，你会怎么设计？代码无错便是优已经不适用了

　　阅读目录

　　一：大部分人的写法v1.0

　　二：第一次改版后的代码v1.1

　　三：第二次改版后的代码v1.2

　　四：第三次改版后的代码v1.3

　　五：UML类图解析

　　六：总结

　　七：思考

　　一：大部分人的写法v1.0

　　这样的写法会带来一个问题？什么问题呢？复用性的问题

　　假如现在你接了个私活，别的公司让你也写个公司内部的薪资计算系统，你说那还不简单，把代码复制过去就行啊，有人说过初级程序员的工作就是Ctrl+C和Ctrl+V，这其实是非常不好的编码习惯，因为当你的代码中重复的代码多到一定程度的时候，维护起来就是一场灾难，越大的系统这种方式带来的问题越严重，编程有一个原则就是尽可能的想办法避免重复，再说了比如客户要求你给它们公司做的内部薪资计算系统是个Web版的，或者是个WindowsApplication版的，那么你下面的代码就废掉了，想想看，薪资计算系统哪些是和控制台程序无关的，只和计算有关的，也就是说分出一个类让计算和显示分开，也就是要让业务和界面分开

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;

　　namespace _1_SimpleFactory
　　{
    　　class Program
    　　{
        　　static void Main(string[] args)
        　　{
            　　　　try
            　　　　{
                　　　　int intSalary = 0; ;//薪水
                　　　　string strPost = Console.ReadLine();//职位
                　　　　switch (strPost)
                　　　　{ 
                    　　　　case "经理":
                       　　 　　intSalary = 10000 + 1000;
                         　　break;
                    　　　　case "技术":
                        　　　　intSalary = 5000 + 200;
                         　　break;
                    　　　　case "客服":
                        　　　　intSalary = 3000;
                         　　break;
                　　　　}
               　　 　　Console.WriteLine("工资是：" + intSalary);
                　　　　Console.ReadLine();
            　　　  }
             　　   catch (Exception ex)
             　　  { 
            　　   }
        　　}
    　　}
　　}

　　

 　 二：第一次改版后的代码v1.1

　　为什么要改版？因为考虑到复用性的问题

　　要让业务逻辑和界面逻辑分开，让它们的耦合度下降，只有分离开才能达到更容易维护和扩展，也就是业务的封装

　　我们新建一个类库，名字叫BusinessLogic，里面有个类文件叫Calculate.cs，专门处理根据职位计算工资的，当我们需要做个Web版的话，只需要把界面逻辑文件Program.cs代码中的“Console.WriteLine("工资是：" + intSalary);Console.ReadLine();”换成“ASP.NET的Response.Write(("工资是：" + intSalary);Response.End();”就OK了，业务逻辑文件Calculate.cs是可以复用的，这样就达到了业务和界面分离了，如果你现在要做一个Windows版的，手机版的，PDA版的，都可以复用这个Calculate类

　　这次改版后的代码修复了原始代码不能复用性的问题，这里只是用到了面向对象三个特性中的封装特性，把业务逻辑封装起来，继承和多态在这里还没用到呢

　　这样的写法又会带来一个新的问题？缺乏灵活性，灵活性包含两个方面，一个方面是修改性，一个方面则是扩展性

　　已经把业务和界面分离了不是很灵活了吗？好那我们现在打个比方，比方CEO现在要在公司中安排一些亲戚进来工作，职位给了个虚头衔是助理，亲戚自然不能亏待，工资是每月6000+1000，你该怎么设计呢？只要修改Calculate.cs 业务逻辑文件，在里面加个分支就行了，问题来了，如果你这样做，你只是要增加一个职位却让“经理”和“技术”以及“客服”参加了编译，这是糟糕的，你万一一不小心把case "经理":intSalary = 10000 + 1000;改成了case "经理":intSalary = 1000 + 1000;你们经理该弄死你了，其次你看到“经理”补助1000，我们技术部补助才200，他奶奶的，不行我要提高我们部门的待遇，然后你把case "技术":intSalary = 5000 + 200;改写成intSalary = 5000 + 800;这样你们部门每个技术都要比原来多发600元人民币了，本来是让你增加一个功能，却让原来运行良好的代码产生了变化，这是非常糟糕的且有巨大风险的，那么我们下面该怎么设计呢？

 　 1：Calculate.cs 业务逻辑文件

 　 using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;

　　namespace BusinessLogic
　　{
    　　public class Calculate
    　　{
       　　 /// <summary>
       　　 /// 计算工资
        　　/// </summary>
        　　/// <param name="strPost">职位描述</param>

　　　　  ///<returns>工资</returns>
       　　 public static int CalculateSalary(string strPost)
        　　{
            　　int intSalary = 0; ;//薪水
            　　switch (strPost)
            　　{
                　　case "经理":
                    　　intSalary = 10000 + 1000;
                     break;
                　　case "技术":
                    　　intSalary = 5000 + 200;
                     break;
                　　case "客服":
                    　　intSalary = 3000;
                     break;
            　　}
            　　return intSalary;
        　　}
    　　}
　　}

　　2：Program.cs 界面逻辑文件

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;
　　using BusinessLogic;

　　namespace _1_SimpleFactory
　　{
   　　 class Program
    　　{
       　　 static void Main(string[] args)
        　　{
            　　try
            　　{
                　　int intSalary = Calculate.CalculateSalary(Console.ReadLine());
                　　Console.WriteLine("工资是：" + intSalary);
                　　Console.ReadLine();
            　　}
            　　catch (Exception ex)
            　　{ 
                
            　　}
        　　}
   　　 }
　　}

　　工程架构图

　　

　　三：第二次改版后的代码v1.2

　　为什么要再次改版呢？因为考虑到灵活性的问题

　　我们要让“经理”和“技术”以及“客服”运算类分开，修改其中一个类不影响其他的类，增加“助理”等运算类也不影响其他的代码

　　首先还是在名字叫BusinessLogic的类库里面有个类文件叫Calculate.cs的计算工资类，里面有个虚方法CalculateSalary()，用于计算工资的，然后我们把“经理”和“技术”及“客服”和“助理”写成了计算工资类的子类，继承后，重写了CalculateSalary()方法，这样要修改任何一个职位的工资，就不需要提供其他职位的代码了，其次要增加一个职位，只需要新建一个类继承计算工资类，重写CalculateSalary()方法就行了，也不用提供其他职位的代码了

　　这次改版后的代码修复了第一版代码不具有灵活性的问题

　　这样写又会带来一个新的问题？什么问题呢？就是如何让客户端知道我想用哪个计算工资类呢？我们是用CalculateJinLi.cs这个经理计算工资类，还是用CalculateJiShu.cs这个技术计算工资类呢？

　　1：Calculate.cs

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;

　　namespace BusinessLogic
　　{
    　　/// <summary>
    　　/// 计算工资抽象类，这个抽象不是指把它定义为抽象类，而是它存在的意义是为了抽象
    　　/// </summary>
    　　public class Calculate
    　　{
        　　/// <summary>
        　　/// 计算工资
        　　/// </summary>
        　　///<returns>工资</returns>
        　　public virtual int CalculateSalary()
        　　{
            　　int intSalary = 0; ;//薪水
            　　return intSalary;
       　　 }
   　　 }
　　}

　　2：CalculateJinLi.cs

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;

　　namespace BusinessLogic
　　{
    　　/// <summary>
    　　/// 计算经理工资的类，继承计算工资类
    　　/// </summary>
    　　public class CalculateJinLi:Calculate
    　　{
       　　 public override int CalculateSalary()
        　　{
            　　int intSalary = 10000 + 1000 ;//薪水
            　　return intSalary;
        　　}
   　　 }
　　}

　　3：CalculateJiShu.cs

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;

　　namespace BusinessLogic
　　{　　
   　　 /// <summary>
    　　/// 计算技术工资的类，继承计算工资类
    　　/// </summary>
    　　public class CalculateJiShu:Calculate
   　　 {
       　　 public override int CalculateSalary()
       　　 {
           　　 int intSalary = 5000 + 200;
           　　 return intSalary;
        　　}
    　　}
　　}

　　4：CalculateKeFu.cs

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;

　　namespace BusinessLogic
　　{
    　　/// <summary>
    　　/// 计算客服工资的类，继承计算工资类
   　　 /// </summary>
   　　 public class CalculateKeFu:Calculate
   　　 {
        　　public override int CalculateSalary()
        　　{
           　　 int intSalary = 3000;
            　　return intSalary;
        　　}
   　　 }
　　}

　　5：CalculateZhuLi.cs

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;

　　namespace BusinessLogic
　　{
    　　/// <summary>
    　　/// 计算助理工资的类，继承计算工资类
    　　/// </summary>
   　　 public class CalculateZhuLi:Calculate
    　　{
        　　public override int CalculateSalary()
        　　{
           　　 int intSalary = 6000 + 1000;
            　　return intSalary;
        　　}
   　　 }
　　}

　　工程架构图

　　

 　　四：第三次改版后的代码v1.3

 　　第二次代码改版后遇到的问题就是如何去实例化对象的问题，到底要实例化谁，将来会不会增加实例化的对象，比如增加“助理”职位的计算工资，这是很容易变化的地方，以后保不准会增加“销售”这个职位的计算工资类等，应该考虑一个单独的类来做这个创造实例的过程，这就是工厂

　　在第二版代码上，我们增加CalculateFactory这个类库，里面有个CalculateFactory.cs类文件，类文件中有个CreateCalculate()方法，根据输入的职位，工厂实例化出合适的对象，通过多态返回父类的方式实现计算工资的结果

　　1：CalculateFactory.cs 工厂类文件

　　using System.Linq;
　　using System.Text;
　　using BusinessLogic;

　　namespace CalculateFactory
　　{　　
   　　 /// <summary>
    　　/// 计算工资工厂类
    　　/// </summary>
    　　public class CalculateFactory
    　　{
       　　 /// <summary>
       　　 /// 根据传入的职位创造对应的实例
        　　/// </summary>
        　　/// <param name="strPost">职位</param>
        　　/// <returns>Calculate抽象类</returns>
        　　public static Calculate CreateCalculate(string strPost)
        　　{
           　　 Calculate calulate = null;
            　　switch (strPost)
            　　{ 
               　　 case "经理":
                    　　calulate = new CalculateJinLi();
                    　　break;
               　　 case "技术":
                    　　calulate = new CalculateJiShu();
                    　　break;
                　　case "客服":
                    　　calulate = new CalculateKeFu();
                    　　break;
                　　case "助理":
                    　　calulate = new CalculateZhuLi();
                    　　break;
            　　}
           　　 return calulate;
        　　}
    　　}
　　}

　　2：Program.cs 客户端文件

　　using System;
　　using System.Collections.Generic;
　　using System.Linq;
　　using System.Text;
　　using BusinessLogic;
　　using CalculateFactory;

　　namespace _1_SimpleFactory
　　{
   　　 class Program
    　　{
        　　static void Main(string[] args)
        　　{
            　　Calculate calculate = null;
            　　//由工厂根据参数决定要实例化哪个对象
            　　calculate = CalculateFactory.CalculateFactory.CreateCalculate("经理");
            　　int intResult = calculate.CalculateSalary();
            　　Console.WriteLine("经理工资为：" + intResult);
            　　calculate = CalculateFactory.CalculateFactory.CreateCalculate("技术");
           　　 intResult = calculate.CalculateSalary();
            　　Console.WriteLine("技术工资为：" + intResult);
            　　calculate = CalculateFactory.CalculateFactory.CreateCalculate("客服");
            　　intResult = calculate.CalculateSalary();
            　　Console.WriteLine("客服工资为：" + intResult);
            　　calculate = CalculateFactory.CalculateFactory.CreateCalculate("助理");
            　　intResult = calculate.CalculateSalary();
           　　 Console.WriteLine("助理工资为：" + intResult);
            　　Console.ReadLine();
       　　 }
   　　 }
　　}

　　运行效果图

　　

　　工程架构图

　　

 　 五：UML类图解析

　　统一建模语言UML（是Unified Modeling Language）的缩写，是用来对软件密集系统进行可视化建模的一种语言，UML为面向对象开发系统的产品进行说明，可视化，和编制文档的一种标准语言

　　类图分为三层，第一层显示类的名称，如果是抽象类，则用斜体表示，第二层是类的特性，通常是字段和属性，第三层是类的操作，通常是方法和行为，前面的符号“+”，表示public，”-“表示private，“#”表示protected

　　

　　六：总结

　　这样我们就完成了一个具有复用性，灵活性（可修改，可扩展）的公司内部薪资管理系统，我们同时也看到这样一个小小的公司内部薪资系统，都用到了封装，继承，多态

　　七：思考

　　如果我们有一天我们需要更改经理的工资怎么办？我们只需要改CalculateJinLi.cs里的代码就行了，如果我们需要增加“销售”职位的工资算法怎么办？我们只需要增加相应的子类就行了，还要去计算工资工厂在switch里增加分支就行了，那我们要去修改界面怎么办？比如我们换成Web版的，那就去改界面呀，跟运算毫无关系

　　这个只是24种设计模式中最简单的“简单对象访问模式”，其他很多设计模式有的很复杂，由于平时工作很忙，没有及时更新请大家谅解，请关注我的博客