摆脱C＃中的预编译器指令

Question

有人要求我维护一些不像我想的那样的代码，并且它充满了编译器指令，使其几乎不可读且几乎不可维护。例子： 通用标签

using指令甚至更漂亮： 通用标签

我想我会给 ConditionalAttribute 一试，但在这种情况下将无法正常工作

有什么办法可以解决这个编译器指令的噩梦吗？

该代码是针对.NET 3.5编译的。

更新：
奥德（Oded）回答建议删除有关BeforeAdd方法的编译器指令，从而使它过载。不幸的是，这是行不通的，因为这两种方法都应该覆盖AbstractBusiness类，该类根据最终包含的程序集提供了两种不同的实现： 通用标签

或 通用标签

此代码从公司过去一段时间创建的一组库中获取其依赖关系，此后一直在“升级”。现在，它们具有该库集的4个不同版本，并带有冲突的名称空间和不同的实现。所有这些都是使用（非常）旧版本的应用程序的“向后兼容性”的名称。

---

结论

我最终选择了@Oded的答案，因为它是一般方法中最有意义的方法（ KISS 等等。在这种情况下，我无法使用它；您在这里看到的只是冰山一角。我不想去K.I.S.S.这段代码是付给我的。

Answer 1

在第一种情况下，您似乎可以简单地对该方法进行多次重载而不是使用此构造。此时，超载解析应该解决问题。

在第二种情况下（使用指令）-您可以对某些指令进行别名化，并在需要时使用别名将所有指令包括在内。包括所有名称空间时会发生什么？有名字冲突吗？

Answer 2

我认为问题不在此类中。此类仅是症状。问题出在调用BeforeAdd的基类中。如果您可以在那里进行重构，则不需要条件编译。

如果名称和名称空间冲突，则可以使用using关键字（而不是用于程序集的关键字）解决该问题。

所以您可以做类似的事情 通用标签

我还认为问题本质在于基类，而不是此类。

在那种情况下，您可以通过改编或接口解决这种胡说八道。

我不知道另一个类叫什么，但是我们称它为EntityAggregator。 通用标签

然后在您的聚合器基类中： 通用标签

然后在您的子类中： 通用标签

现在，您可以通过实现该接口将其他对象修改为IEntity。

当我看这段代码时，也让我惊讶的是，也许您使用事件而不是这段代码。

现在，如果您正在谈论多用途编译，即在两种不同条件下在两个不同的位置编译代码，那么可以通过使用局部类来更优雅地做到这一点。

您将CONDITION_1代码隔离为以下内容： 通用标签

在这种情况下，由于代码重复，我不喜欢这样。您可以使用using关键字来帮助实现这一点： 通用标签

Answer 3

根据我所看到的，似乎原始开发人员没有任何继承和多态的感觉。从代码中很难看出来，但似乎LogEntity和AbstractBusinessEntity具有相同的属性。有继承模型还是两个完全不相关的类？如果它们不相关，是否可以创建它们都可以实现的继承模型或接口？如果您粘贴这些类，可能会有所帮助。

长话短说，我不会浪费时间尝试使用当前形式的代码。我将不惜一切代价找到一种消除编译器指令的方法。它看起来并非完全不可挽救，但可能需要一些努力。

Answer 4

我不知道这是否可行，但我要做的是在DVCS Mercurial中创建分支来处理此问题。

当我修复常见的错误/添加代码时，我将有2个分支在玩，暂时有3个分支。

这是我创建初始版本的方法： 通用标签

仅修复其中之一的错误： 通用标签

要修复常见错误： 通用标签

注意：这是假设您不会在类型分支或公共分支中进行繁重的重构，如果这样做，则至少在当前情况下可能会更好相比于这样的分支方式任何此类重构都会使将来的合并变得非常痛苦。