oo分析的过程是理解需求的过程

      oo分析的过程是理解需求，分析业务的过程。没有了oo分析能很好的了解你要做的业务吗？这是我这两天进行一个模块分析后，想到的一个问题。虽然进行oo的分析设计已经很长时间了，但是这次才让我感到oo分析还意味着什么。
    这两天来到新公司负责一个手机充值的功能，适应了几天做了点东西之后头头跟我说了句咱要加入手机支付的功能。当我用期待的眼光寻求需求文档的时候，头头慷慨的跟我口头说了一边需求，头头是这样跟我说的“我们现在要加入一种充值方式就是手机充值，跟XXXX公司合作的，他们上行通知我们，然后我们返回结果给他，之后发送下行给他们，他们会返回处理结果，成功后我们需要记录用户的充值信息，把金额加入用户的帐户，后台可能需要配置手机充值的类型和一些相关的查询操作”大体明白之后，他跟我说“其实不是很复杂，对你来说很简单的。你可以写一个action接受他们的上行，然后记录下来，去调用他们的下行，成功后记录下来就可以了，后台管理的需求你要自己想一想，自己设计一下”。
     以前在做分析设计的时候，需求都是比较完整的了，吃透需求后，可以发现系统中可以变化的部分，可扩展的部分，这样在进行分析和设计的时候就可以多考虑一些，这些看起来都是值得去进行设计的。但是这次的需求看起来似乎很简单，如果按头头说的写个action，再写点别的东西就可以满足需求了。但是我还是固执的用仅有的时间做了这次分析。
      首先我对需求进行了一些分析，按习惯第一点是要把领域对象找出来。但是对于这样比较抽象的需求来说，抽象领域对象似乎不是很容易。抽象领域对象的时候发现了很多系统的细节问题。比如以后换了合作公司怎么办？对于不同类型的支付方式可能要采取不同的方法，包月用户怎么续费？怎样记录用户的流水和钱包的更改？有一些问题似乎太过于细节了，可以先放到后面，通过需求和简单的分析，反复之后，找到了三个领域对象，用户，手机支付，用户钱包。手机支付我想可以更加抽象一些，理解成为支付方式。这样的话，以后也可以对现有的支付方式进行重构。
      之后由于时间紧迫就开始了用uml进行对象的设计。考虑到要记录用户的流水和钱包的计算还有一些关于手机充值的记录，所以将支付方式和信息记录进行了独立的处理以求达到解藕，支付方式中有不同的实现，手机支付或者支付宝等等，支付方式中有代理类。代理类依赖于信息记录，可以接受一个支付方式的对象。这样我既可以通过代理类直接记录支付的情况，也可以不用代理类，手动的记录支付情况。信息记录用到的是装饰模式，对不同的信息记录方式都可以进行功能的叠加。考虑到性能的问题，要对上行进行队列处理，所以手机支付是一个抽象类，依赖于手机消息队列。不同的合作伙伴可以有自己的实现。进行了这些分析之后，我把对于一些问题的疑惑跟头头商量之后，得到了一些答复，一些细节的需求问题也就有了眉目了。
      大体的设计就是这个样子的了，有的地方也还不是很好，但是通过这次的分析，可以放你更清楚的看到需求，理解系统中可能出现的变化的地方。oo设计可以让你有更好的结构，让你的代码可维护，可扩展，但还有一点就是可以帮你理解需求，发现系统中变化的部分。另外设计是需要不断的反思，不断的重构的，不断的讨论的。我想如果了没有这种设计行为，只是简单的完成工作，不是一个程序员应该有的职业希望。对于一个很简单的需求，我们其实也可以发现他变化的地方，分析之后才能感到对他值得不值得设计。在我进行设计手机支付的时候也想过，这个值得考虑那么多吗？其实整个的分析过程才让我感觉到，这也是一种挖掘需求的过程。
     oo分析的过程是也理解需求，分析业务的过程。