命名空间的经验法则 [英] Namespace Rule of Thumb

问题描述

在将项目进一步分类到新的名称空间之前，在给定的名称空间中应该进入多少类，接口等是否存在一般的经验法则?喜欢最佳实践还是社区偏爱?还是所有这些都是个人喜好?

Is there a general rule of thumb as to how many classes, interfaces etc should go in to a given name space before the items should be further classfied in to a new name space? Like a best practice or a community preference? Or is this all personal preference?

namespace: MyExample.Namespace
 interface1
 interface2
 interface3
 interface4
 interface5
 interface6
 interface7
 interface8
 interface9

或

namespace: MyExample.Namespace.Group1
 interface1
 interface2
 interface3
namespace: MyExample.Namespace.Group2
 interface4
 interface5
 interface6
namespace: MyExample.Namespace.Group3
 interface7
 interface8
 interface9

推荐答案

在任何可靠的来源中我都没有看到任何经验法则，但是在与大多数开发人员一起工作时，我有一些共同的偏好.有几件事可以帮助您创建名称空间.

I have not seen any rule of thumb at any reliable source but there are a few common preferences that I haven seen while working with most developers. There are a few things that help you make the namespaces.

1. 班级域
2. 是类还是接口(我已经看到一些开发人员更喜欢ShopApp.Model.Interfaces之类的名称空间).如果您的界面是某种服务或数据合同，则效果很好.
3. 没有太深的名称空间，3(.)就足够了.不仅如此，它还会令人烦恼.
4. 如果您随时觉得名称空间变得不合逻辑或难以管理，则可以开放以重组名称空间.
5. 不要仅仅为了它而创建名称空间.

快乐编码！！！

这篇关于命名空间的经验法则的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！