当对象建立好了之后，为了实现我们的业务逻辑处理，我们需要对实例化的对象进行操作。现在我们为该系统提出第一个需求：用户可以修改行程中的备注信息。

回到我们的第一版代码中，如果我们需要处理这个操作，我们会怎么做呢？

itineraryInstance.Note = "this is my new note info";

是不是会像上面这样，将需要添加的值赋予实例化的对象呢。这种操作，对我们现在正在进行的编程习惯来说，是再正常不过了。

那么我们来思考，如果我们的项目有多处需要对“备注信息”处理呢。则对该属性的变更将被散落在代码各处。而当我们对该需求进行了一个增强验证时，比如此时我们需要增加：用户修改行程中的备注信息时，只允许用户录入200个字以内的文本。 OMG，此时我们需要去查找所有散落的片段，并且为他加上验证。

从另外个角度来看，第一个版本我们所建立的类，我们无法通过仅仅查看它本身就能读懂有关旅行行程有关的业务，我们仅仅知道它具有起始时间，备注信息等，而对他们应该如何相互作用无从所知。

所以这种仅仅具有类的属性，或者说以POCO呈现的类型，我们称之为“贫血模型”。

接下来，我们回到第二版代码中，我们为它赋予属于它的行为。从需求中我们得知了，行程的备注信息是可以修改的，而备注信息是属于行程的，因此修改备注信息改行为理应属于行程本身。我们稍微改动代码：

publicclassItinerary{publicintID {get;set; }publicList Participants {get;set; }publicList

Places {get;set; }publicItineraryNote Note {get;set; }publicItineraryTime TripTime {get;set; }publicItineraryStatus Status {get;set; }//ctorpublicvoidChangeNote(stringcontent){if(content.Length >200)thrownewNoteIsOverlengthException(); Note =newItineraryNote(content); }}

此时我们为Itinerary赋予了一个ChangeNote的行为，当外界需要更改备注时，则只需通过调用改方法既可以实现，而且当展开其他开发人员阅读此类时，也会清楚的明白，业务上允许用户更改200字以内的备注。

但是，我们依然有一个地方美中不足，我想你可能也发现了：属性还是对外暴露的！对，也就是说，我们除了通过类公开的行为修改类自身的属性外，我们还可以在外界随意更改。这显然不符合我们设计的初衷。因此我们可以将所有属性的set私有化。所以，一定要注意，我们在考虑实体的时候，一定要知道“实体是高度内聚和自治的”（敲重点！！！！！）。

当然，有的开发者还会尝试另外的写法，让实体完全自治，将上面的代码中的属性，全部转变为私有的字段，外界只能通过公开的行为来对实体进行处理。

publicclassItinerary{publicintID {get;set; }privateList participants;privateList

places;privateItineraryNote note;privateItineraryTime tripTime;privateItineraryStatus status;//ctorpublicvoidChangeNote(stringcontent){if(content.Length >200)thrownewNoteIsOverlengthException(); note =newItineraryNote(content); }}

但是当外界需要获取该实体的值，或者需要ORM映射的时候可能就不是很友好了，不过你可以使用类似于像备忘录模式的快照方法来处理。后期我们也会采用这种模式来实现部分案例。

通过将实体赋予它应用的行为所建立出来的实体我们称为“充血模型”。那么贫血模型好还是充血模型好呢？很多同学肯定会说，这还用问吗，肯定是充血模型啦。其实这个答案并没有一个真正的答案，实体自身的行为是通过我们对领域的慢慢分析（可能是通过与领域专家沟通）得来的，如果因为为了使用充血模型而盲目的将一些不属于实体的行为赋予给它，只会让实体变的更加混乱，从而得不偿失。所以，此时的贫血模型并不意味着一直是贫血模型，后期随着领域的深入它可能会不断丰富属于自身的行为。

ITPub博客

为实体赋予它的行为

最新文章