应用OOP的设计过程演化(一)

?

?????? 今天看到了一篇很不错的分析设计文章，虽然用的语言是net平台的，但是个人认为分析是不分平台的，就转载过来以供参考。

?

???? 面向对象的程序设计(Object-Oriented Programming，简记为OOP)立意于创建软件重用代码，具备更好地模拟现实世界环境的能力，这使它被公认为是自上而下编程的优胜者。它通过给程序中加入扩展语句，把函数“封装”进编程所必需的“对象”中。面向对象的编程语言使得复杂的工作条理清晰、编写容易。

在计算时代的早期，程序员基于语句思考编程问题。到了20世纪七八十年代，程序员开始基于子程序去思考编程。进入21世纪，程序员以类为基础思考编程问题。而类是OOP中的核心组成元素，通常都是使用类来“封装”对象（属性、行为）。在经典图书《代码大全》里定义：“创建高质量的类，第一步，可能也是最重要的一步，就是创建一个好的接口。这也包括了创建一个可以通过接口来展现的合理的抽象，并确保细节仍被隐藏在抽象背后。”

为了更好的理解设计思想，本系列文章以简单的《书店信息系统》为例，但随着需求的增加，程序将越来越复杂。此时就有修改设计的必要，重构和设计模式就可以派上用场了。最后当设计渐趋完美后，你会发现，即使需求不断增加，你也可以神清气闲，不用为代码设计而烦恼了。

在一个书店里，主要业务就是销售书，销售书后所得到的就是收取到的资金（本次交易金额），那以这个业务来分析，在不考虑设计的情况下，我们该怎么去实现：

?

在上面的设计中，我们已经应用到了OO的思想，把不同个顾客类型做为一独立的对象来处理。仔细观察，会员（Buy）和普通顾客具有完全相同的方法，为什么不为它们建立一个共同的父类呢？
?
?

?
???? 
通过共性的抽象，让会员和普通顾客都去继承并实现父类的抽象方法，那代码是这样的吗？
?
?
针对如上的设计来说，完全可以满足一个简单的销售逻辑的处理，可算是一个完美的设计。然而，在我们的实际项目中会有很多意想不到的事发生，其中需求变更应该是最为头疼的。刁钻的客户是永远不会满足的，这意味着我们就不能给我们的设计画上圆满的句号。时间久了，书店的一些书籍早已因陈旧而不能销售出去，可老板又不想让这些书成为废品，书无论是新还是旧都有他的价值所在，旧书的里的知识或许是不能与新版的书籍比配，但还是有一定的参考价值，就如我们去研究历史一样，是为了什么？是为了更好的迎接未来。
书店的业务扩展，老板决定将陈旧的书籍用来出租(呵呵，这想法不错，满足了像我这样的穷人想看书可又没钱买书的XX，UPUP.....)，根据我们上面在设计销售经验来看，那出租我们应该怎么来设计呢？是不是也应该把不同的对象做为的独立的逻辑来处理呢？答案是肯定的，那到底要怎么去设计呢，这要求我们深入到具体的业务逻辑了。
通过分析现实中的业务逻辑，出租主要涉及到两个方面：租借和归还。而我们上面的设计中把顾客分为了会员和普通顾客两类，那么归还是不是应该划分为会员还书和普通顾客换书呢？这是肯定的，因为会员和普通顾客在租书的租金上是不一样的，会员和普通顾客在租金上应该是两种不同的策略。
从上面的分析得出，出租主要分为租借、会员归还和普通顾客归还这三种类型的逻辑。而租书不用给租金但必须先交押金，还会则需要收取租金（可从押金中扣除）。也就是说这三种类型里都回有处理出租（租借和归还）和交易金额的逻辑。既然都有共性，那也应该抽象出父类，是这样设计的吗？ 
?
?
?

?
?

?
仔细观察会发现，Sell和Hire都具有相同的行为，这里我们完全可以在进一步的抽象，为这两个类定义一个统一的接口，详细本文就不做介绍，我已经把内容安排到下一篇文章里，大家可以关注本系列的后续文章。
?
?
PS:转载个好的文章真不容易，等明天把其后面的几讲转载上来
??? BWT：后面的几讲实在是有点长，就不在转了。
???????????? 二的地址是：? http://www.uml.org.cn/mxdx/200911162.asp
???????????? 三的地址是：?http://www.uml.org.cn/mxdx/200911163.asp
?????????????? 对于软件方面的管理分析http://www.uml.org.cn/这个站点真的是很不错！