关于association的继承.txt

一些关于UML的经典讨论

关于Association的继承
　
--------------------------------------------------------------------------------
 
这几日在看的时候遇到一些问题，觉得很疑惑，最让我疑惑的就是Association的继承，请教一下各位大侠。 
比如一个银行系统，客户Customer Holds Accounts，一个客户可能有多个帐号。但是往下进行，Account可能有很多钟，现金帐号： CurrentAccount，存款帐号：DepositAccount。假设我们限制到一个客户最多只能有一个现金帐号，一个存款帐号。哪Customer就和CurrentAccount有了关联，这时书中就引入了关联的一般化（Association Generalization），概念我能大致明白，可是实现上呢。还有对这种多重性的控制上呢，应该怎么做呢。 
希望大侠指点迷津。
 
 03/11/21 10:55 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 spide   现金账号与存款帐号不可能（继承）有“性别、邮政编码”等客户必有的属性，应该依据对业务对象的分析，对属性和操作确有“继承性”的建立继承关系。可以抽象出一个“账号”类，但要等你认为系统比较复杂时才必要。可以把继承看作一种“一对一关联”，但这不是充分条件。
　
--------------------------------------------------------------------------------
 
 03/11/24 03:01 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 spide   “继承”使得你不必总是“重复已经说过的东西”。例如，有5种账号，他们属性、操作都有共性，没必要重复书写5次，只需要抽象出来一个“账号”然后在描述更具体的“xxx账号”类的新特点前说明继承的来源，别人就很容易记住了。
　
--------------------------------------------------------------------------------
 
 03/11/24 03:22 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 致虚子   回复: “继承”使得你不必总是“重复已经说过的东西”。例如，有5种账号，他们属性、操作都有共性，没必要重复书写5次，只需要抽象出来一个“账号”然后在描述更具体的“xxx账号”类的新特点前说明继承的来源，别人就很容易记住了。
　
--------------------------------------------------------------------------------
 
谢谢spide的回复。 
我想讨论的是我有一个抽象的帐号类：Account，然后会继承出不同的帐号类别：CurrentAccount等。首先是客户和基类Account有关联，多重性为1对多，但是由于特殊的要求，Account又和CurrentAccount有关联，多重性为1对0..1。这是客户和CurrentAccount的关联似乎和客户和Account的关联有重复，在我看的这边书中用到了一个Association Generalization的概念，在编程中如何实现这样一个情况呢。
 
 03/11/24 09:28 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 spide   各种语言实现方法不同。
　
--------------------------------------------------------------------------------
 
从实现方法上来说，组合（1对多关联）只要在父类实现一个“集合”属性，或者在子类中实现一个能够访问到父类对象的属性就可以了，这是传统的数据结构中的经典方法。 

继承在概念上比组合复杂得多，但是用OO语言实现起来却非常方便。 

下面的话需要结合一两种OO语言为例才能更清楚。 

一般，只要遵循编程语言的语法稍加说明不同类之间的继承性，语言编译器会为你实际实现继承关系。编译器为你维护父类与子类对象各自的数据结构，并且实现多态。例如，一个定义为Acount类型的对象，在执行post操作时，执行的代码要根据实际实例化类型的不同而改变，可能是子类中的post操作代码而不是父类中的。对于属性的访问也是多态的。 

一个程序组件，如果接口中含有Account类的对象，编写好、调试好之后，当给他传入实例化为Account的子类型的对象时，不需要重新编译，不需要重新测试。其中Account类型的接口变量在此只不过定义了“模式”，它在这个组件中会根据具体的实例化类型而执行不同子类中重载了的代码。 

当然，我们设计程序时必须小心地保持子类与父类同一属性、操作的功能含义完全一致。 

对于实现问题：组合，基本上是从数据结构上简单直观地去了解它就足够了。而继承，必须深入到编译以及程序执行的动态过程中去了解它。 

顺便说一下，我经常因为一张A4纸画不下一个完整模块的类图中的所有的类，而将一些业务上有共性的类抽象、继承。这样，子类、以及仅仅与这些子类相关联的类都可以放到另一张纸上（模块上）去表达。虽然整个系统中的类变多了，但是每一个独立的模块看起来其规模都恰好符合我的懒惰性格，既不过粗也不过细。 

同样情况也出现在其它文档中。例如对于状态来说，一个需要成百上千个状态的图，在针对对象类型进行继承之后，可以将图纸简化成两三张，而每一张上面只有一二十个状态就足够了。 

要利用继承，就要从对象分析阶段就开始，“自顶向下”地贯彻到各个开发步骤中，直到源代码中。一开始，只有OOA没有OOP也没有关系，程序风格一定会跟着思想的改变而改变。就怕没有足够精炼的OOA，于是盲目追求OOP中最沉重、最繁琐的形式。
 
 03/11/26 17:31 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 babituo  建议的一种实现办法
　
--------------------------------------------------------------------------------
 
Customer Holds Accounts这个关联抽象的实现如下： 
procedure Customer.Add(AAccount); 
begin 
if Not AAccount.ViolateAddRuler(Accounts) then 
begin 
Accounts.add(AAccount); 
end; 
end; 

Accounts是Customer的集合类属性，记录所有Customer的Account。 
ViolateAddRuler是Account类的抽象方法，不同的子类有不同的实现； 
对于不需限制的类型，直接返回true, 
对于受限类型，在方法中加入规则检查。