将单个命名空间拆分到多个 C# 文件有什么好处？答案

【问题标题】：what's the benefits to split a single namespace across multiple C# files?将单个命名空间拆分到多个 C# 文件有什么好处？
【发布时间】：2021-04-27 10:25:35
【问题描述】：

我正在阅读一本书，其中显示了以下示例：

假设您正在开发一个名为 Square 的几何类集合，圆形和六边形。鉴于它们的相似性，您希望将它们组合到 CustomNamespaces.exe 程序集中称为 MyShapes 的唯一命名空间中。您有两种基本方法。首先，您可以选择在单个 C# 文件 (ShapesLib.cs) 中定义所有类，如下所示：

// ShapesLib.cs
using System;

namespace MyShapes
{
    public class Circle { /* Interesting members... */ }

    public class Hexagon { /* More interesting members... */ }

    public class Square { /* Even more interesting members... */ }
}

虽然 C# 编译器对包含多种类型的单个 C# 代码文件没有任何问题，但当您想在新项目中重用类定义时，这可能会很麻烦。例如，假设您正在构建一个新项目，并且只需要使用 Circle 类。如果所有类型都定义在一个代码文件中，那么您或多或少会被整个集合所困扰。因此，作为替代方案，您可以将单个命名空间拆分为多个 C# 文件。

// Circle.cs
using System;
namespace MyShapes
{
    public class Circle { /* Interesting methods... */ }
}

// Hexagon.cs
using System;
namespace MyShapes
{
    public class Hexagon { /* More interesting methods... */ }
}

// Square.cs
using System;
namespace MyShapes
{
    public class Square { /* Even more interesting methods... */ }
}

我不太明白，在新项目中重用类定义是什么意思？在这两种情况下，当你想在其他项目中使用Circle类时，你需要显式使用MyShapes.Circle c = new Circle()或者使用using MyShapes; Circle c = new Circle();，所以“在单个C#文件中定义所有类”和“在单个C#文件中定义所有类”之间真的没有区别跨多个 C# 文件拆分单个命名空间”？

【问题讨论】：

您可以将一个命名空间拆分到多个 C# 文件中。” 这本书是什么？这听起来很奇怪。同一文件夹中的类 - 按照惯例 - 共享相同的命名空间。
更重要的是，您可以将命名空间拆分（传播）到多个程序集。

标签： c# .net .net-core clr

【解决方案1】：

"你或多或少地被整个系列卡住了。因此，作为一个或者，您可以将单个命名空间拆分为多个"

措辞令人怀疑，而且你的直觉是正确的，但你仍然对整个系列很烂。它们是一样的，唯一的区别是每个文件都有一个类共享相同的命名空间（有些人可能会说）可以通过多种方式更容易维护，例如可读性、git 提交和合并等。

在任何正常意义上并且与作者评论“你或多或少地被整个集合困住”直接相关，只有当你将每个形状都放在一个不同的项目/ Nuget，您可以有选择地和细粒度地引用每个形状，其优点是所有形状仍位于相同的原型命名空间下。即便如此，形状也不是最好的类比。

在没有陷入措辞语义的情况下，作者只是暗示您可以跨文件拆分单个类，并让它们仍然驻留在同一个命名空间中。

【讨论】：

我想你说的就是这个，现在我又读了一遍
@stuartd :) 是的，可能措辞更好

【解决方案2】：

当你想在新项目中重用类定义时很麻烦

基本上，这正是所写的。如果您有一个包含多个类的项目的命名空间，如果将来您想重用一个类（为什么在已经完成腿部工作时重新发明轮子 - 在专业环境中很常见），您将不得不导入你需要的类。

但是，如果您只有一个类需要导入（即包含在您的项目中），但该类位于代表多个类的文件中 - 您将导入所有其他类，即使您将要从事的项目不需要它们。这是浪费内存。

此外，这不是已经提到的，将类分离到自己的文件中是一种很好的做法，以便将来更容易阅读和代码管理。特别是如果您的类将增长为表示具有许多方法、属性等的大型对象。您不希望拥有超过 1000 行的文件。

【讨论】：

在这两种情况下，当你使用using MyShapes时，无论是单个文件还是多个文件，都会导入所有包含的类型，不是吗？
没有。 using 不会“导入”任何东西。 using 允许您使用缩写形式的类名。如果没有using 语句，你必须写NamespaceFoo.ClassBar，有using NamespaceFoo; 你可以写ClassBar，编译器会首先尝试在“当前”命名空间中找到ClassBar，然后它会尝试结合ClassBar 名称与您定义的各种 using。
这些类可以位于共享相同命名空间的不同项目中。有可能，但在这个例子中你为什么要这样做？
在专业环境中很常见。考虑使用名为“SomeCompanyName”的命名空间设置一个基本“Account”类。然后，如果您将基“Account”类派生到 Project1 的某些特定帐户类型（例如“Savings”类和“Investment”类）。对于下一个项目，您可能只需要使用“Savings”类，您将继承“SomeCompanyName”命名空间，但如果它有自己的文件，则无需包含额外的“Investment”类。您只需要包含“Account”基类和您需要的“Savings”类及其文件。

【解决方案3】：

拥有一个 class= 一个文件有很多充分的理由。

您可以将单个 .cs 文件复制到另一个项目中，如果运气好的话，它会正常工作，并且您不会导入无用的东西（我说运气不好，因为一个类经常使用其他类......例如所有形状可以有一个class Shape 作为基类...然后要将Circle 复制到另一个项目，您必须同时复制Circle 和Shape)
很容易找到包含类的 .cs 文件：它与类同名。如果一个文件包含多个类，该文件应该有什么名称？一段时间后，文件名很容易“过时”，因为您添加了更多类
创建一个已经超过行数的类是很容易的...如果你开始将多个类放在同一个文件中，这个问题只会增加。但通常你不必一起检查所有课程......也许今天你必须在Circle 上工作，明天在Square 上工作。同时拥有它们是非常没用的。这就像总是随身携带无用的工具。
如果您使用诸如 github 之类的 VCS（版本控制系统），很容易看到哪些文件已被修改。如果一个文件 = 一个类，您可以了解已修改的内容。如果多个类都在一个文件中，一切都会变得模糊

当然还有其他好的理由...但主要的理由是：每个人都在这样做...所以可能这是正确的方法。至少在一种语言（Java）中，这不是建议，而是规则。一个文件 = 一个公共课程。

【讨论】：