病人、住院病人、门诊病人.txt

一些关于UML的经典讨论

回归简单——病人、住院病人、门诊病人
　
http://www.shecn.com/best/g32/u1147657.htm
--------------------------------------------------------------------------------
 
楼下为了名词、概念、理念争论起来了，结果问题还是没有结论似的。看来都翻书去了。呵呵呵。比较可爱。 

不过，一开始就想到翻书套模式可能会越来越糊涂，反而漏掉了更基本更简单的东西。 

这里，“病人”确实是个抽象的概念，楼下有人提出是abstract的想法，应该说思路对了。沿着这个思路再往前走一步就好了。 

其实，一个病人要挂号什么的，是所有病人都要做的。因此首先定义一个病人Interface里定义所有病人的共同的方法。无论是门诊病人，住院病人都是implement这个病人Interface的，自然也就会实现各自的有关方法，其中就有“挂号”这个方法。各自实现各自的“挂号”方法来创建各自的对象。 

当然，更好一些可以定义一个抽象的“base病人”类，在这个“base病人”类里头，实现基本的病人的方法，比如“挂号”。 
　
 
 03/05/16 23:20 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sinohong   公布答案了，公布答案了！！哈哈。下面的楼梯太长乐，还是这里另搭一个吧。接着原来思路往下走吧，感兴趣的来看看吧。欢迎指教哦。
　
--------------------------------------------------------------------------------
 
嗯。前面已经说了，病人是个Interface，具体的方法在各个子类里完成。 

再往下考虑一步，很自然的就会问，谁来调用这个Interface啊。 

假设，通过分析，我们系统里有个Operator这个对象，就是那个坐在挂号处脸色永远很难看的那个business worker乐。 

现在，这个Operator需要处理一个东西，就是所有来到挂号处的人提交的挂号的请求request. 当这个Operator处理请求的时候Operator.handle(reqst)，就会根据提交的请求决定创建什么样的子类。 

比如，提交的是“门诊”请求，则创建“门诊病人”子类，并且调用“门诊病人”的“挂号”接口，完成门诊病人的挂号手续。于是，一个门诊病人成功创建了。 

假如有新的类型的病人出现怎么办？比如，现在出了个“非典”病人。那么当然啦，这个Operator必须首先增加处理“非典”病人挂号请求。然后呢，当然系统要创建“非典病人”子类，并且实现这类病人的“挂号”方法，比如，这类病人立刻会被上报到国务院，呵呵。是不是跟实际情况很像啊。 

那么有个base病人有什么好处啊。可能的好处就是，比如，当病人挂号的时候不说自己挂什么号，就默认的称谓“门诊病人”。当然，还可以处理所有病人都共同的挂号手续，比如创建病历等等。 

总结哈，在我的方案里，有门诊病人和住院病人等子类实现病人接口，Operator在处理挂号请求的时候决定创建什么子类。每当有新类型的病人需要处理的时候，Operator需要知道如何处理新类型的病人，新类型病人也必须了解自己的挂号手续。（这好像在现实中也是成立的，嘻嘻。） 
　
 
 03/05/18 10:57 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sinohong   也在这里放一条。模式啊，模式啊，我们都要模式，这个是模式吗？
　
--------------------------------------------------------------------------------
 
哈哈。 

现在凡事都讲模式。掉书袋的也愿意掉些模式出来唬人，弄得我们大家好自备哦，呜呜呜呜。 

好了，答案是—— 
放心吧，这就是模式，是很常用的Factory Method模式。 

这个模式的特点就是知道什么时候创建对象，但预先无法知道必须创建的对象的类，而且由子类完成对象的创建。 

这个门诊病人、住院病人问题，从提问者的角度看，实际困惑在于只有挂号了以后才会知道一个病人是门诊病人还是住院病人，所以是一个构造型的问题，一般适用构造型模式。 

有些网友提出了几种模式 
用状态来进行状态转移是不行的。这里不是状态的问题。 
而用装饰模式呢？嗯，只能说，看来这一章他背的最熟。
 
 03/05/18 11:15 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 killcamel  实际困惑在于只有挂号了以后才会知道一个病人是门诊病人还是住院病人
　
--------------------------------------------------------------------------------
 
-- 那么挂号前病人存在不存在呢？ 
-- 一个外科的住院病人能不能在内科门诊呢？ 

所以是一个构造型的问题，一般适用构造型模式。 
现在凡事都讲模式。掉书袋的也愿意掉些模式出来唬人 

-- 只看表面的问题是构造方面的就限定用构造型模式，究竟是谁在掉书袋？ 

-- 老兄真的明白装饰模式是怎么一回事？ 
-- 是不是不知道还有 
class A::A（class base&）{} 
的构造函数写法？ 
 
 03/05/18 11:57 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 sinohong   我是从楼主的原话中得来的
　
--------------------------------------------------------------------------------
 
"比方说“挂号”，挂号应该作为一个病人的方法，但是这个病人执行这个方法后应该变为门诊病人，一个“病人”对象怎样在运行时变为一个“门诊病人”对象？还有像“住院”方法。 " 

从这里，我们看不到楼主的系统设计的全貌，我们只知道楼主遇到的问题就是怎样在挂号的时候创建门诊病人，这就是我的理解，是我提出方案的基础。 

你问挂号之前有没有病人？当然没有啦。你不挂号，系统根本不知道你是谁啊。 

至于需要处理“外科的门诊的住院病人”（不知道是不是真的存在），从而采用些其他的设计，那是别的问题，而且与整个系统的设计有关。这里只能针对楼主的原话。
 
 03/05/18 20:26 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 killcamel  这个，我不懂
　
--------------------------------------------------------------------------------
 
你问挂号之前有没有病人？当然没有啦。你不挂号，系统根本不知道你是谁啊。 

-- 系统不知道有这个对象，却知道调用这个对象的挂号方法，未免太神奇了 
-- 现在再看看，挂号究竟该是谁的方法
 
 03/05/24 23:29 酷帖！    臭帖！    回复   
酷帖评价：           臭帖评价： 
返回页首 
 
 xue_zhong   好好想想，不要顺着你的思路走了，会撞墙的
　
--------------------------------------------------------------------------------
 
病人不是一个什么抽象概念，他是在业务中活生生存在的，根本不需要为病人建立什么Interface，挂号也不是病人的方法。 

病人就是病人（称之为Patient），跟住院和门诊没有太多的关系，病人来医院进行看病的过程（称之为Visit），这个Visit类才是跟住院还是门诊相关的。所以无论病人是看门诊还是住院，他都是Patient，他的基本信息是不会改变的，Patient类里包含的主要信息是病人的原始信息和一些附加信息，如果要考虑全的话，还需要考虑过敏信息（Allergy类）等，Patient与他的附加信息、Allergy等类之间的关系是聚集关系。 

Visit即看病的过程类，是单独的一个类，这个类里可以记录病人的类型，这个类型包括，住院、门诊、急诊等等，这个类里除了病人的类型外还会记录很多信息，如，时间、总费用、与其相关的医生是谁，与财务相关联的信息等等。在这里Patient和医院（Hospital）之间是一种关联关系，这种关联关系就是Visit，所以Visit是Patient和Hospital之间的关联类。 

针对挂号来说，它不是Patient的一个方法，而是单独的一个控制类，可以称之为Admit，其实你可以把入院登记和挂号理解为同一种类型的类可以统一称它们为Admit，它提供了一种医院与病人之间的契约，让病人可以在医院里从事一些活动，也就是触发了Visit的产生，所以它是一种控制类，你在使用这个类的时候，需要new patient，new visit等等。 

总结来说，这里包括的类包括Hospital,Patient，Visit，Admit等类，如果要把病人信息记得全面还需要包括Allergy等类，住院和门诊只是病人访问的一种形态。