应用OOP的设计过程演化（三）

应用OOP的设计过程演化（三）2011-10-01 博客园 Bēniaǒ在上一篇文章里（应用OOP的设计过程演化（二））完善了整个系统的体系结构，以及完成了各个具体的功能角色的功能，这也只能算是完成了一个结构而已，要真正做到完善还差得很远。比如在计算租金这个算法上，使用switch语句，判断图书的类型来决定该书的折扣，之前我为了演示在switch语句中固定了折扣的算法策略，如下代码示意代码：

1/**//// <summary>
2/// 计算租金
3/// </summary>
4/// <returns></returns>
5private double GetRent（）
6{
7  switch （_bType）
8  {
9    case B_Type.NOVEL: BookCash = Convert.ToDouble（Day） * 0.1;
10      break;
11    case B_Type.LIFT: BookCash = Convert.ToDouble（Day） * 1d;
12      break;
13    case B_Type.MAGAZINE: BookCash = Convert.ToDouble（Day） * 0.5;
14      break;
15  }
16  return BookCash;
17}

这就是原有设计中的普通顾客借书的折扣算法，租借的是小说，租金的折扣*0.1，生活类书籍租金的折扣*1，而杂志则是打5折，很显然这样的固化设计是不合理的，那我们应该怎么来解决呢？，在实际的应用开发中，我们应该从数据库或是配置文件里读取这些折扣率，下面我以从配置文件中读取的方式简单介绍下。

我们可以这样来分析，因为不同类型的书籍的折扣是不一样的，在系统中又出现两种角色（会员和普通顾客），那么会员的折扣率和普通顾客的折扣率也应该有所不同，我们应该为他们定义不同的算法策略，将每一种折扣算法封装到一个类中，然后我们只需要根据书籍的类型里进行判断决定采用哪一个类（具体的策略对象）来处理就OK。通过这样的分析，策略模式（Strategy）正是解决这样的问题的模式，它的定义："准备一组算法，并将每一个算法封装起来，使得它们可以互换。"

策略模式的使用是由用户发起的，根据用户的操作决定使用什么具体的策略角色。也就是说，我们完全可以使用这个模式来解决上面这种固化的折扣算法。系统里书籍的类型分三种：小说、生活和杂志；我们可以为这三种类型的书籍各自定义一个独立的算法策略，当然也可以将这三种策略定义到一个类里。我们既然是面向对象的编程，那就还是将其分开吧。但要记住的是“面向对象编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。” 在实际的项目中如果能够做到这样也就够了，类的划分还得根据实际的需求而定。