原文出处： zetaplusae

利用贫血规模模子凡是被认为是一种反模式，因为它勉励措施员无意义地反复编写代码。下面我将简短（而琐碎）地用一个例子来叙述这个是如何发生的。我们可以通过细致的筹划以及严格的编码类型来制止其产生，可是同样可以得到较好的封装。防备陷入贫血规模模子深坑的难度随项目人数呈指数级增长。

我相信所有人劈面向工具都有所认识，但我却有趣地发明一些看似毫无意义的小办法却导致了最终一场大劫难。

第一步：编写贫血实体

在软件开拓的某些环境下，我们会在一个规模实体之外实现一些逻辑。这大概是由于一个明晰的设计抉择可能，更有大概，耐久类不能引用外部处事造成了不能将这段逻辑实此刻规模工具的内部。把外部处事（依赖）添加到实体工具中将会造成与数据库的交互变的巨大而艰涩难解。

public class User {
   private final String name;
   private final String emailAddress;

   public User(final String name, final String emailAddress) {
      this.name=name;
      this.emailAddress=emailAddress;
   }

   public String getName() {
      return this.name;
   }

   public String getEmailAddress() {
      return this.emailAddress;
   }
}

第二部：逻辑被实此刻外部类中

一个开拓组的成员抉择他们需要一个用来操纵这个实体的要领。这个要领（在我们的例子中）要挪用到User工具，但它还需要用到一个User类所不知道的外部处事。这段逻辑被实此刻一个辅佐类（helper）可能说一个处事类（service）的要领中，而且以某种方法协助了这个实体。这个辅佐类不包括自带的数据，而且仅仅从这个实体中获取数据、修改其状态。

public class UserReminderService { // 用户提醒处事
   private IMailService mailService; // 邮件处事
   private IMessageGeneratorService messageGeneratorService; // 动静生成处事

   public void sendReminderMessage(final IUser user) { // 发送一个提醒
      String reminderMessage = this.messageGeneratorService.generateReminderMessage(user.getName);
      this.mailService.sendMessage(user.getEmailAddress(), reminderMessage);
   }

   ...
}

这个并不能实此刻User实体中，因为我们基础无法在实体中取得邮件处事可能是动静生成器。到今朝为止，这个看起来还不算很糟糕（我们很好地封装了动静的建设以及邮件发送进程），可是这仅仅是“松弛”的开始，劳务派遣管理系统，然后顿时开始让这些不鉴戒的开拓者陷入劫难。那边错了呢？

UserReminderService是一个游手好闲的类（它掌管了太多其他类的勾当）。动静的建设、把它发送出去这些都应该是User类本身的业务逻辑。

public class SignupVerificationService { // 注册确认处事
    private IMailService mailService; // 邮件处事
    private IMessageGeneratorService messageGeneratorService; // 动静生成处事

    public void sendVerificationEmail(final IUser user) { // 发送确认邮件
      String verificationMessage = this.messageGeneratorService.generateVerificationMessage(user.getName);
      this.mailService.sendMessage(user.getEmailAddress(), reminderMessage);
   }
}

第三步：反复代码发生

在此期间，昆山软件开发，另一个开拓者开拓了一个全新的组件，同样也利用了User实体。这个新的处事被用来抉择注册用户是真的用户而不是一个呆板人。

public class SignupVerificationService { // 注册确认处事
    private IMailService mailService; // 邮件处事
    private IMessageGeneratorService messageGeneratorService; // 动静生成处事

    public void sendVerificationEmail(final IUser user) { // 发送确认邮件
      String verificationMessage = this.messageGeneratorService.generateVerificationMessage(user.getName);
      this.mailService.sendMessage(user.getEmailAddress(), reminderMessage);
   }
}

这个开拓者大概会发明这个要领与之前的sendReminderMessage要领十分的相似。在这个环境下，他以为他把验证成果与其他组件分隔来的做法十分夺目，看上去没有须要为这短短两行代码重用之前的实现。那边错了呢？

这两个要领看上去十分相似，昆山软件公司，可是又是差异的，使得开拓者认为是两个差异的勾当。这里有一种冗余的感受，但还没有造成问题。

第四步：逻辑改观

从久远来看，越简朴的代码会变的越巨大。在这个迭代后期，我们的开拓者在sendReminderMessage要领中添加了一些更巨大的逻辑（预处理惩罚用户名和校验邮箱地点）。

  public void sendReminderMessage(final IUser user) {
      String formattedUserName = formatUserNameForMessage(user.getName());
      String reminderMessage = this.messageGeneratorService.generateReminderMessage(formattedUserName);
      if (isEmailAddressValid(user.getEmailAddress()) {
         this.mailService.sendMessage(user.getEmailAddress(), reminderMessage);
      }
   }

   public boolean isEmailAddressValid(final String emailAddress) { // 是否邮箱地点有效
      return emailAddress.contains('@');
   }

   public String formatUserNameForMessage(final String userName) { // 为动静名目化用户名
      return userName.toUpperCase();
   }

我们此刻有了sendReminderMessage要领的新版本（固然是一个很简略的验证系统），使得（曾经相似的）UserReminderService变得相当差异。

那边错了呢?