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

Question

I'm reading a book which shows an example below:

Assume you are developing a collection of geometric classes named Square, Circle, and Hexagon. Given their similarities, you would like to group them together into a unique namespace called MyShapes within the CustomNamespaces.exe assembly. You have two basic approaches. First, you can choose to define all classes in a single C# file (ShapesLib.cs) as follows:

// ShapesLib.cs
using System;

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

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

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

While the C# compiler has no problems with a single C# code file containing multiple types, this could be cumbersome when you want to reuse class definitions in new projects. For example, say you are building a new project and only need to use the Circle class. If all types are defined in a single code file, you are more or less stuck with the entire set. Therefore, as an alternative, you can split a single namespace across multiple C# files.

// 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... */ }
}

I don't quite understand it, what does reuse class definitions in new projects mean? In both case, when you want to use Circle class in other projects, you need to use MyShapes.Circle c = new Circle() explicitly or use using MyShapes; Circle c = new Circle(); using MyShapes; Circle c = new Circle(); , so there is really no difference between "define all classes in a single C# file' or "split a single namespace across multiple C# files"?

Answer 1

" you are more or less stuck with the entire set. Therefore, as an alternative, you can split a single namespace across multiple "

The wording is suspect, and your intuitions are correct, you are still suck with the entire set. They are the same thing, the only difference is you have class per file that share the same namespace (which some might say) can be easier to maintain in several ways such as readability, git commits and merges etc.

In any normal sense and directly relating to the authors comment " you are more or less stuck with the entire set ", this would only start to make a substantial difference when you had each shape in a different project / Nuget and you could selectively and granularly reference each shape, with the advantage that all shapes are still under the same archetype namespace. Even then, shapes are not the best analogy.

Without getting bogged down in the semantics of the wording, the author is just implying you can split individual classes across files and have them still reside in the same namespace.

Answer 2

cumbersome when you want to reuse class definitions in new projects

Basically, it is exactly what is written. If you have namespace for a project that contains a number of classes, if in the future you would like to reuse a class (why reinvent the wheel when you have already done the leg work - common in the professional setting), you would have to import the classes that you need.

But, if you have only one class that you needs to be imported (ie included in your project), but that class is in a file representing a number of classes - you will be importing all of the additional classes even though the project you are going to be working on has no need for them. It is wasted memory.

In addition, and this is not something that has been mentioned, it is a good practice to separate classes into their own files for easier readability and code management in the future. Especially if your classes will grow to represent large objects that will have many methods, properties, etc. You would not want to have a 1000+ line file.

Answer 3

There are various good reasons for having one class = one file.

1. you can copy the single.cs file in another project and with a little luck it will just work, and you won't import useless things (I say little luck because often a class uses other classes... For example all the shapes could have a class Shape as a base class... Then to copy Circle to another project you would have to copy both Circle and Shape )

2. it is easy to find the.cs file that contains a class: it has the same name as the class. If a file contains multiple classes, what name should the file have? It is quite easy after some time to have the filename become "obsolete" because you added some more classes

3. it is quite easy to make a class that is already too much big as the number of lines... If you begin putting multiple classes in the same file this problem will only increase. But normally you don't have to check all the classes together... Perhaps today you have to work on Circle and tomorrow on Square . It is quite useless to have both of them at the same time. It would be like always carring around useless tools.

4. if you work with a VCS (Version Control System), like github, it is easy to see what files have been modified. If one file = one class, you can have an idea about what has been modified. If multiple classes are inside a single file, everything becomes murkier

There are surely other good reasons... But the main good reason is: everyone is doing it... So probably it is the correct way. In at least a language (Java), it isn't a suggestion, it is a rule. One file = one public class.