接口地狱还是可接受的设计？

Question

我正在重构一些遗留代码，这些代码通过一个案例语句一遍又一遍地做着相似的事情：

switch(identifier)
    case firstIdentifier: 
        (SomeCast).SetProperties(Prop1,Prop2,Prop3);
        break;
    ...
    case anotherIdentifier:
        (SomeDifferentCast).SetProperties(Prop1, Prop2, Prop3);
        break;

所以，我尝试创建一个独特的界面，以便它可以成为

(SameInterfaceCast).SetProperties(Prop1,Prop2,Prop3);

但是，我随后发现有些项目甚至没有使用所有属性。于是，我开始想到更像这样的东西：

if(item is InterfaceForProp1)
    (InterfaceForProp1).SetProp1(Prop1);
if(item is InterfaceForProp2)
    (InterfaceForProp2).SetProp2(Prop2);
if(item is InterfaceForProp3)
    (InterfaceForProp3).SetProp3(Prop3);

你可以像这样创建一个类：

public class MyClassUsesProp2And3 : InterfaceForProp2, InterfaceForProp3

但是，我担心这段代码过于分散，它可能会膨胀太多。也许我不应该太害怕本质上是一种方法接口，但我想在走这条路之前看看我是否缺少设计模式？ （唯一出现在我脑海中但不太合适的是Decorator 或Composite 模式）

更新

所有属性都是唯一类型。

最终，这是依赖注入的一种形式。代码太乱了，现在不能使用像 Ninject 这样的东西，但最终我什至可以摆脱其中的一些并使用注入容器。除了设置变量之外，目前还有一些逻辑正在完成。这都是遗留代码，我只是想一点一点地清理它。

Answer 1

我不知道对此是否有“正确”的答案，但这就是我会做的。

class Properties {
    prop1
    prop2
    prop3
}

interface PropertySetable {
     setProperties(Properties prop);
}
public class MyClassUsesProp2And3 implements PropertySetable {
    setProperties(Properties prop) {
       //I know I need only 2 and 3
       myProp2 = prop.prop2;
       myProp3 = prop.prop3;
    }

}

在调用函数时，你不应该有演员表。

 someFunc(..., PropertySetable, Properties,...) {
      PropertySetable.setProperties(Properties); 
 } 

这是基本结构。

您应该封装属性 - 将属性设为私有并具有相关的构造函数。或者使用 Builder 模式来构建属性......等等......

Answer 2

我认为答案取决于您首先要重构代码的原因。

• 如果您想完全摆脱 switch 块，那么您必须使用一种方法实现一个接口，该方法采用三个参数。每个班级都必须弄清楚哪些参数适用以及如何处理这些参数。
• 如果您想减少代码总量，那么我不确定添加特定于类的属性设置逻辑是否比原始 switch 语句更少代码
• 如果您想利用编辑器的代码完成功能插入具有正确数量的属性/参数的正确方法，那么只需在每个类上实现正确的方法并完全避免使用接口

Answer 3

visitor pattern 是您面对 switch 语句和类型转换时的标准解决方案。您的每种情况的代码将进入访问者类中的单独方法。你的每个类将只实现一个接口——一个接受访问者的accept 方法。你最终会得到比现在更多的代码，但它会读起来更清晰。

Answer 4

基本上，您希望使演员（使用 setProp 方法的类型）具有相同的“演员”类型，并使属性（prop1...n）具有相同的“道具”类型。这会将您的代码减少到

actor.setProp(prop)

如果您想避免使用 instanceOf，我能想到的唯一方法是使用访问者模式，使访问者“道具”。我也会使用模板方法让我的生活更轻松。在 Java 中，我会让它看起来像这样（对于两种实际的 Prop）。

class Actor {

    protected void set(Prop1 p1) {
        // Template method, do nothing
    }

    protected void set(Prop2 p2) {
        // Template method, do nothing
    }

    public void setProp(Prop p) {
        p.visit(this);
    }

    public interface Prop {
        void visit(Actor a);
    }

    public static Prop makeComposite(final Prop...props ) {
        return new Prop() {

            @Override
            public void visit(final Actor a) {
                for (final Prop p : props) {
                    p.visit(a);
                }
            }
        };
    }

    public static class Prop1 implements Prop {
        public void visit(Actor a) {
            a.set(this);
        }
    }

    public static class Prop2 implements Prop {
        public void visit(Actor a) {
            a.set(this);
        }
    }
}

这允许你做这样的事情：

    ConcreteActor a = new ConcreteActor();
    Prop p = Actor.makeComposite(new ConcreteProp1(42), new ConcreteProp2(-5));
    a.setProp(p);

...这真是太棒了！