既然我们在用Java之类的面向对象的语言编码，那么重复代码可以大致分为如下两种情况： 1、类型体系之内（父类型和子类型、子类型之间）存在重复逻辑代码 2、类型体系之外的重复代码 【类型体系内的重复代码处理】 1、如果重复代码属于类型本身操作（即应该是以实例方法存在），则很自然的应用重构技巧，公共代码往上走。如果Sub Type之间有这种重复代码，把重复代码迁移到DefaultAdatper中。 2、如果重复代码不属于类型本身操作（即应该是以静态方法存在），则需要判断一下这种静态代码的功能使用范围： A、如果是非常全局性的，例如有关java流的辅助操作，则应该果断的抽取出来，封装到一个Utility工具类中，例如可以叫 做IOUtil。把这个Utility类放置到非常底层模块中，这样上层很多功能模块中都可以使用，否则可能会导致上层多个模块中都有类似IOUtil的 类，又是重复代码。
1 public class IOUtil { 2 /** 3 * 工具类，不需要产生实例。 但是也不需要应用单态！！！ 4 */ 5 private IOUtil() {} 6 7 public static InputStream buildInputSteam(File file) { // } 8 9 // 其他公共静态操作 10 }B、如果这种静态操作只对本类型体系有意义，则有两种常用的处理方法：第一种是把这种静态方法迁移到基类 DefaultAdapter中，但是不要在DefaultAdapter中放置过多的类似静态方法；第二种是把这种静态方法封装到一个helper助手 类中，例如MyTypeHelper，其中放置了MyType类型体系中需要使用的一些静态方法。如果第一种DefaultAdapter中堆放了较多的 静态方法，则可以用helper助手类的方式。
1 public class MyTypeHelper { 2 /** 3 * 助手类，不需要产生实例。 但是也不需要应用单态！！！ 4 */ 5 private MyTypeHelper() {} 6 7 public static boolean validateParamer(Object paramer) { // } 8 9 // 其他公共静态操作 10 }这个helper一般需要和接口、默认适配类一起暴露，便于扩展子类型使用。示意图如下： 【类型体系之外的重复代码处理】 类型体系之外的重复代码处理相对就很简单了，根据重复代码功能适用范围，封装到对应的Util类或者Helper类中。这里就不细讲了～_～ 【有关公用代码的几个概念】 个人意见，仅供参考。 助手类（Helper class） ： 我觉得首先这个类产生的目的是为特定模块或者特定功能服务的（助手吗～_～），不是全局的。而且完全可以隐藏在特定模块内部，很多时候不需要暴露。 Helper类的命名要有针对性，不能搞成一个麻辣烫，里面的静态操作既为这种功能服务，又为那种功能服务，尽量做个忠臣，不要同时当多个主子的助手。 工具类（Utility class） ：一般是全局的，往往有一定普世价值，也就是说往往是全局通用的。 例如你在做一个模块，这个模块功能是处理表单，则关于处理表单的一些公用静态操作就应该放置到该模块的一个助手类中，名称类似于 FormProcesserHelper。再有一个导出报表的功能，则对应的助手类可以称之为ExportReportHelper，建议这两个 helper不要混在一起。 有人可能会说，这样会不会导致大量的助手类呢？这边有个粒度把握的问题（经验会发生作用～_～），但是只要是助手类命名规 范，则一个助手类的名字就基本上可以告诉用户你提供什么样的服务了。 假如你现在处理的是有关IO操作的重复代码，则需要迁移到全局的工具类中，因为这样的操作往往适应于全局的。 Facade class（门面类） ：这个乍看起来和助手类有点像，往往是绑定于特定模块。但是，要搞清楚，门面类是用来封装子系统的，代理对模块常用核心功能的访问的，针对用户需要的常用场景提供一些辅助操作，帮助用户更好的使用此模块的主要功能。面向客户端或者其他子系统或模块的，不是用来处理对应模块中重复代码的 ！！！有关详细信息，请参加Facade设计模式的文档。 【注意】Helper class、Utility class、Facade class一般都不需要生实例，暴露的都是静态操作，更不需要误写成单态，别滥用单态！！！ 后记:： 关于重复代码的处理，个人以为既需要技巧（别人总结出来的技巧），更需要经验（经验往往给你感觉，跟着感觉走一般就不会太离谱～_～）。 希望对开发新手有作用～_～
