面向对象分析与设计

        本文再以ATM系统为例来说明面向对象的分析和设计过程。如果从用户需求的高度来看，需求包括取款、查询和修改密码。用户输入密码严格来说仅仅是用户需求中的一个步骤，并非真正意义上的需求。然后进入分析阶段，分析阶段考虑的仍然是问题域，经过分析产生的是分析类，分析类与现实世界中对象有对应关系。很显然此时一个分析类就是用户（User)，该类具有卡号、密码、金额、用户名和身份证等信息，在我们讨论的问题中仅仅需要卡号、密码和金额，所以该分析类就包括这三个属性（卡号、密码和金额），该类的方法肯定包括取款（drawCash)、改密码(changePassword)和余额查询(queryBalance)。按道理这三个方法就够了，但因为输入密码需要一次交互，实际就是一个用户登陆的过程，所以需要增加一个方法login方法。这就是是一个实体类。系统的边界类和控制类在此不做讨论，现在就完成了OOA的工作。接下来进入OOD阶段。OOD实际就是在系统架构的基础上完成对分析类的细化，也就是从概念到实现的一个求精的过程。所以说分析类不同的人来做应该是大同小异，而设计的差别则根据不同的架够甚至不同的设计人员(具备不同的经验和技能)。如果采用一个独立的APP来实现（适用与小用户量的情况，往往只能作为原型或是一些Demo），那么设计类显然可以与分析类对应，就是说可以设计一个User类，该类就是现实世界中这个用户在系统中的一个映像（或代理）。可以在系统启动时，加载所有用户的信息（也就是形成所有用户的实例，并且填充每个用户实例的数据），在用户输入的信息进入系统后，调用该用户的代理实例的方法进行处理即可。如果是商用的系统，往往会采用J2EE架构的分层设计方法以及局部的设计模式，此时该分析类就影射为多个设计类，包括我们常用的称为UserMgr的设计类（也包括User中的方法，但没有数据成员）、相应的数据访问类（比如UserDao)和数据库（严格来说是、数据库中该用户对应的数据）（很显然，如果仍采用前一种方法，那么在内存中将保存大量的数据，如果用户数据超过百万条，内存肯定不够）。所以在这种情况下，我们看不到所谓的用户类，不是消失了，而是分解了。从这里也看出，分层架构反而弱化了面向对象，而且也从侧面印证了一句话“架构决定了设计”。很多的时候，我们省略掉了分析的过程，因为这种系统类似性太强了，所以在用户需求和软件需求分析完成后，我们就可以直接进行设计了。