1. 当我自己做的时候 说的是我在前一个项目中负责的一些工作，描述如下： 模块主要包含以下几项工作：
   
   

    这些用户信息中都有写共同的东西，如中文姓名，英文姓名 又有些不同的东西，有的需要证件，有的不需要证件，需要证件的，彼此可选的证件类型又不一样 这些功能最终是被不同的模块用来实现业务，不同的业务模块对用户的一些属性的要求不一样，比如有的生日不能为空，有的生日不许在某一年之前，有的证件不能用护照，有的必须用身份证之类的等等。在新增，编辑，和选择的时候所所需要的提示语当然也不一样。

   刚开始做了时候，涉及到的业务板块只有2个，于是我看到了这些用户的共同点，对信息做了个统一的抽象。简单轻松愉快的实现了后来，不断的有新的业务板块添加进来，每个板块对用户信息所需要的属性不一样，就统一属性，也根据板块有不同的限制。我才发现，我给自己制造了一个坑。具体的表现如下。

    当然，不光光是新增一个用户那么简单。在这些用户操作的过程中肯定还有很多诱惑我把不同类型的用户硬生生凑到一起的东西。而且是一些很客观的重复的工作量。

   最后的解决方案，庆幸我破釜沉舟的重构，用继承的方式，尽可能的对重复的工作做了抽取，放在了基类中。这样，虽然在新增模块的过程中，确实会存在一些少量很难避免的重复工作。但是，相比起不必要的高度耦合可能造成的未知安全隐患，和开发过程中不断思考的维护和对之前的需求进行的返工确认。这些重复的工作量简直可以忽略不计了。

2.换到了新的项目组，同样的业务，也存在类似的问题，只是他们还在我重构代码之前，眼看着现在每个版本都要增加1-2个业务板块。我庆幸自己当初的决定之余……

在以业务为主的系统和应用中，我个人还是觉得模块之间的低耦合比代码的重复利用更重要一些