重构重复和高度耦合的代码答案

【问题标题】：Refactoring duplicated and highly coupled code重构重复和高度耦合的代码
【发布时间】：2013-03-04 15:33:52
【问题描述】：

我有三个具体的类-

public class ClassA{
    public C1 processA(C1 c1){
        //lots of ugly code that copies
        //one field to another
        //return c1
    }
    public List<C1> processA(List<C1> c1s){
        //iterate over c1s
            //call process(c1)
            //add returned value to list

        //return list
    }
}


public class ClassB{
    public C2 processB(C2 c2, C3 c3){
        //lots of ugly code that copies
        //one field to another
        //return c2
    }
    public List<C2> processB(List<Pair<C2, C3> pairs){
        //iterate over pairs
            //call process(c2, c3)
            //add returned value to list

        //return list
    }
}

public class ClassC{
    public C4 processC(C4 c4, C5 c5, C1 c1){
        //lots of ugly code that copies
        //one field to another
        //return c4
    }
    public List<C4> processC(List<Triple<C4, C5, C1> triples){
        //iterate over triples
            //call process(c4, c5, c1)
            //add returned value to list

        //return list
    }
}

我想删除 process(List...) 方法中的重复项。我不关心 processA(C1)、processB(C2,C3)、processC(C4,C5,C1) 方法，它们将保持不变。在重构此代码时我有哪些选择？

【问题讨论】：

从重命名方法、变量和类型名开始重构。
更改变量和方法名称。这是我的第一步。
创建接口并覆盖process()
不应该你所有的第二个构造函数都返回一些Collection，正如你的评论所说，return list无处不在。
确实如此。谢谢！。我已经更正了。

标签： java design-patterns refactoring

【解决方案1】：

除了代码重复之外，我还看到了代码的另外两个问题，您可以解决这些问题以消除重复的代码气味：

几个类的紧密耦合。虽然我不能在不了解这些类的域及其实际描述性名称的情况下确认这一点，但看到 C1-C5 的相关性足以使属性复制成为有效操作，我认为一个好的起点是重新考虑这些类的设计。例如，它们是否可以是 composed，以便 C1-C5 共享的属性始终可以存储在新的 bean 类中？
做同一件事的多种方式，或者，在传统的 OOD 术语中，它缺乏“关注点分离”。这些类不仅关心转换（C3 到 C2 等），而且还收集对集合进行操作的结果。考虑将后一个问题分离出来，也许只是让客户使用更通用的集合解决方案，例如apache collection's Collections.collect()。因为 A 类和 B 类试图为用户做多件事，所以你有多个用于单个项目和集合的方法。（有趣的是，在 scala 或 groovy 等函数式语言中，通用集合解决方案会更加优雅和简洁，从而减少对此类便捷方法的需求。）

【讨论】：