13518219792
对于每个编码人员来说，避免重复代码可能是大家都想做的。对于有一定经验（对基本的OO原则有一定经验）的开发人员来说，大部分情况下都能比较自然地避免重复代码的问题，写代码的时候，感觉有逻辑重复的情况，会很自然的凭感觉经验做相应的处理和复用。以下是个人经验，供新手参考。 既然我们在用Java之类的面向对象的语言编码，那么重复代码可以大致分为如下两种情况： 1、类型体系之内（父类型和子类型、子类型之间）存在重复逻辑代码 2、类型体系之外的重复代码 【类型体系内的重复代码处理】 1、如果重复代码属于类型本身操作（即应该是以实例方法存在），则很自然的应用重构技巧，公共代码往上走。如果Sub Type之间有这种重复代码，把重复代码迁移到DefaultAdatper中。 2、如果重复代码不属于类型本身操作（即应该是以静态方法存在），则需要判断一下这种静态代码的功能使用范围： A、如果是非常全局性的，例如有关java流的辅助操作，则应该果断的抽取出来，封装到一个Utility工具类中，例如可以叫做IOUtil。把这个Utility类放置到非常底层模块中，这样上层很多功能模块中都可以使用，否则可能会导致上层多个模块中都有类似IOUtil的类，又是重复代码。1publicclassIOUtil{2/**3 *工具类，不需要产生实例。但是也不需要应用单态！！！4*/5privateIOUtil(){}67publicstaticInputStreambuildInputSteam(Filefile){//}89//其他公共静态操作10} B、如果这种静态操作只对本类型体系有意义，则有两种常用的处理方法：第一种是把这种静态方法迁移到基类DefaultAdapter中，但是不要在DefaultAdapter中放置过多的类似静态方法；第二种是把这种静态方法封装到一个helper助手类中，例如MyTypeHelper，其中放置了MyType类型体系中需要使用的一些静态方法。如果第一种DefaultAdapter中堆放了较多的静态方法，则可以用helper助手类的方式。1publicclassMyTypeHelper{2/**3 *助手类，不需要产生实例。但是也不需要应用单态！！！4*/5privateMyTypeHelper(){}67publicstaticbooleanvalidateParamer(Objectparamer){//}89//其他公共静态操作10} 这个helper一般需要和接口、默认适配类一起暴露，便于扩展子类型使用。示意图如下： 【类型体系之外的重复代码处理】 类型体系之外的重复代码处理相对就很简单了，根据重复代码功能适用范围，封装到对应的Util类或者Helper类中。这里就不细讲了～_～ 【有关公用代码的几个概念】 个人意见，仅供参考。 助手类（Helper class） ：我觉得首先这个类产生的目的是为特定模块或者特定功能服务的（助手吗～_～），不是全局的。而且完全可以隐藏在特定模块内部，很多时候不需要暴露。Helper类的命名要有针对性，不能搞成一个麻辣烫，里面的静态操作既为这种功能服务，又为那种功能服务，尽量做个忠臣，不要同时当多个主子的助手。 工具类（Utility class） ：一般是全局的，往往有一定普世价值，也就是说往往是全局通用的。 例如你在做一个模块，这个模块功能是处理表单，则关于处理表单的一些公用静态操作就应该放置到该模块的一个助手类中，名称类似于FormProcesserHelper。再有一个导出报表的功能，则对应的助手类可以称之为ExportReportHelper，建议这两个helper不要混在一起。有人可能会说，这样会不会导致大量的助手类呢？这边有个粒度把握的问题（经验会发生作用～_～），但是只要是助手类命名规范，则一个助手类的名字就基本上可以告诉用户你提供什么样的服务了。 假如你现在处理的是有关IO操作的重复代码，则需要迁移到全局的工具类中，因为这样的操作往往适应于全局的。 Facade class（门面类） ：这个乍看起来和助手类有点像，往往是绑定于特定模块。但是，要搞清楚，门面类是用来封装子系统的，代理对模块常用核心功能的访问的，针对用户需要的常用场景提供一些辅助操作，帮助用户更好的使用此模块的主要功能。 面向客户端或者其他子系统或模块的，不是用来处理对应模块中重复代码的 ！！！有关详细信息，请参加Facade设计模式的文档。 【注意】Helper class、Utility class、Facade class一般都不需要生实例，暴露的都是静态操作，更不需要误写成单态，别滥用单态！！！后记:： 关于重复代码的处理，个人以为既需要技巧（别人总结出来的技巧），更需要经验（经验往往给你感觉，跟着感觉走一般就不会太离谱～_～）。 希望对开发新手有作用～_～
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：主机域名、虚拟主机、营销软件、网站建设、亚东网站维护、网站推广。
措施一：改写类的实例方法
通过类继承实现代码重用不是精确的代码重用技术，因此它并不是最理想的代码重用机制。换句话说，如果不继承整个类的所有方法和数据成员，我们无法重用该类里面的单个方法。继承总是带来一些多余的方法和数据成员，它们总是使得重用类里面某个方法的代码复杂化。另外，派生类对父类的依赖关系也使得代码进一步复杂化：对父类的改动可能影响子类;修改父类或者子类中的任意一个类时，我们很难记得哪一个方法被子类覆盖、哪一个方法没有被子类覆盖;最后，子类中的覆盖方法是否要调用父类中的对应方法有时并不显而易见。
任何方法，只要它执行的是某个单一概念的任务，就其本身而言，它就应该是首选的可重用代码。为了重用这种代码，我们必须回归到面向过程的编程模式，把类的实例方法移出成为全局性的过程。为了提高这种过程的可重用性，过程代码应该象静态工具方法一样编写：它只能使用自己的输入参数，只能调用其他全局性的过程，不能使用任何非局部的变量。这种对外部依赖关系的限制简化了过程的应用，使得过程能够方便地用于任何地方。当然，由于这种组织方式总是使得代码具有更清晰的结构，即使是不考虑重用性的代码也同样能够从中获益。
1，继承提高了代码的重复利用性；
2，继承是面向对象的，一类事物可以独立存在，解藕了类与类之间的斗联系。
3，继承更利于程序的设计。
5，在组合中，一定要把同一类事物放在一起，和现实生活中一样，每一类事物都是有自己的共性和自己的特性，按毛主席的矛盾论说是：矛盾的普遍性与特殊性，普遍性就是继承来的。
6，在写代码之前，分析和设计是关键的一步，这一步解决的就是哪些类是同类的，哪些东西是公共的。
重新写个方法，把你选中的放进去，用到的时候调用下就好，重写写的方法最好是static修饰的，这样就能直接用类名调用了，比如
public class A{
public static void b(){
//这里放你那些代码
}
}
以后要用的话就是A.b()就可以用了
