条件访问修饰符？答案

【问题标题】：Conditional access modifiers?条件访问修饰符？
【发布时间】：2017-03-13 22:29:05
【问题描述】：

我的公司有一个带有非常大的 DLL（大约 11 MB）的软件产品，我被分配了通过制作两个或三个版本的 DLL 来减小其大小的任务，以只允许每个 DLL 中提供的方法列表.当前的 DLL 有各种方法，但我们的大多数客户只使用特定的方法集，具体取决于他们的行业。

我有 7 个项目的解决方案：两个是 C++ 项目，五个是 C#。其中两个 C# 项目从 C++ 项目调用函数（使用 dllexport），我认为它被称为非托管代码（请多多包涵，我是这个领域的新手，所以我不太了解术语 - 事实上我只是现在发现“public/private/protected/etc”被称为“Access Modifiers”！:-)）

到目前为止，我已经弄清楚了如何定义一个解决方案范围的预处理器常量以与“#if”一起使用。到目前为止，我已经想出了以下创建三个 DLL：

例如，以下内容位于 .cs 文件之一中：

#if DLL_FOR_INDUSTRY_A
public void method_A(int arg1)
#else
private void method_A(int arg1)
#endif
{
  for (int x=0; x<arg1; x++)
  {
  // code here;
  }
}

#if DLL_FOR_INDUSTRY_B
public void method_B(int arg1)
#else
private void method_B(int arg1)
#endif
{
  // code here;
}

#if DLL_FOR_INDUSTRY_C
public void method_C(int arg1)
#else
private void method_C(int arg1)
#endif
{
  // code here;
}

但我的问题是我在整个 DLL 中有大约 400 多个方法！有些方法在我应该创建的新 DLL 中很常见。两个新的 DLL 将代表软件版本（将其视为“标准”与“专业”版本。）我还研究了使用“[System.Diagnostics.Conditional]”，但它没有如果方法是 "public method_A(int x)" 而不是像 "public void method_A(int x)" 这样的方法，则可以工作。如果我在现有方法中添加“void”，它会中断许多其他调用（噩梦！）另外，我不是该领域的专家，所以我不知道哪种方法更好。

我的问题 - 是否有人对我应该如何正确执行此操作有更好的建议？如果有人可以为我指出如何“有条件地”编译如此大的 DLL 以便我可以设置预处理器常量来更改 DLL 结果的正确方向，那就更好了。（我尝试使用上面显示的内容进行编译（仅涵盖大约 15 个方法而不是 400+，这需要大量工作）但 DLL 大小似乎没有改变，不确定未使用的方法是否仍被编译到新的 DLL .)

能否以更简单的方式将访问修饰符设置为“有条件的”？（这样它们就不会出现在输出 DLL 中。）

请帮忙！我在 Windows 7 和 Windows 10 上使用 Visual Studio 2015。我真诚地感谢任何能给我一些指导的人，过去 5 天我一直在这，包括周末，但我没有好的解决方案。 :-(

【问题讨论】：

public method_A(int x) 不仅仅是“一种方法”。它是一个构造函数。
将内容设为私有会减小 DLL 的大小吗？
为什么不使用继承？您绝对不想做类似“如果客户 == x...否则如果客户 == y...”之类的事情 - 我在他们这样做的地方工作，而且维护起来是可怕 .
如果删除（假设）仅与行业 A 相关的内容会破坏（假设）仅与行业 B 相关的内容，那么这意味着该方法毕竟与两个行业都相关，或者存在不适当的需要排除的依赖项。
制造很多条件似乎并不理想。只需使用他们需要的方法创建 3 个不同的程序集。您有 3 个较小尺寸的版本。他们可以使用 3 个版本中的任何一个，而无需再次重新编译。

标签： c# dll

【解决方案1】：

我建议在这里使用继承而不是条件编译 - 例如，拥有一个包含所有行业使用的通用功能的基类和包含行业特定功能的不同行业的实现。然后，您可以将其拆分为多个程序集，为每个人提供一个具有通用功能的 DLL 以及包含与其特定行业相关的代码的第二个 DLL。

你肯定不想做很多“if”语句来做特定行业的事情。我记得大约 10 年前在一家公司工作，该公司的代码类似于

if (client == x) ...
else if (client == y) ...
else ...

可以预见的是，这很快就变得非常难以维护。作为记录，代码是在我到达那里之前编写的，所以这不是我的错；）。在他们的情况下，他们本可以从使用Template Method Pattern 而不是进行特定于客户的推理中受益。（Strategy Pattern 和 Factory Pattern 在这种情况下通常都非常有用）。

【讨论】：