2010-09-08 34 views
3

假设我正在制作一个新库,Jokes,带有一个小API。在使我的API简单易用的利益,我把它放在基地命名空间:在哪里保持内部课程?

namespace Jokes 

    --> public interface IJoker 
     --> string Joke(); 

    --> public static class Jokers 
     --> public static IJoker NewSlapstickJoker() 
     --> public static IJoker NewAbsurdJoker() 
     --> public static IJoker NewCheesyJoker() 

还有鬼的实现是内部:

--> internal class SlapstickJoker : IJoker 
--> internal class AbsurdJoker : IJoker 
--> internal class CheesyJoker : IJoker 

现在我敢肯定的请遵循下面的指导原则(有人可以验证吗?):

  • 不要从根名称空间访问子名称空间中的类型。 (例如,System中的类型无法识别System.Drawing中的类型)。

此准则适用于内部类吗?为了避免污染我的根名字空间,我想把我的内部类放在Jokes.Internal。这意味着Jokes名称空间(Jokers)中的一个类型将知道子名称空间Jokes.Internal中的类型。这个可以吗?

+0

是Jokers的一个小丑工厂吗?如果是这样,也许更改名称 – 2010-09-09 00:00:20

回答

2

为了避免污染我的根名称空间,我想把我的内部类放在Jokes.Internal中。这意味着Jokes名称空间(Jokers)中的类型将知道子名空间Jokes.Internal中的类型。这个可以吗?

是的,没关系。关于在名称空间中没有类型的主要指导依赖于“sub”名称空间内的类型实际上更多关于公共API。内部类和仅由内部类型使用的名称空间实际上是一种实现细节,并且不属于任何类型的指导。

我会坚持一致的东西,你觉得是有道理的。使用内部命名空间似乎是合理的(尽管我可能会做类似命名空间Jokes.Implementations)。

此外,鉴于您的Jokers类正在构建新的实例,它基本上是一个工厂。你可能想要考虑命名更像JokerFactory的东西,以使这一点很明显。对我而言,Jokers将暗示该类中将包含一个Joker实例的集合,而不是一组工厂方法。

+0

+1 JokerFactory – ChrisW 2010-09-09 00:46:49

1

命名空间服务几个主要用途:

  1. 它们有助于避免不同的开发商,不同的组织类型的创建和共享之间的命名冲突。
  2. 他们帮助组织类型分组,以便更容易理解他们做什么以及哪些类型相互关联或一起使用。

现在到你的具体问题。引用内部命名空间中的外部命名空间类型并不是非常理想 - 但它也不是很糟糕。虽然我现在想不起来,但如果.NET框架中存在这种情况存在的情况,我不会感到惊讶。作为一个通用的设计原则,在层中构建代码是一个好主意;并且通常这些层的结构使得较少的“专用”代码不知道更多的“特定代码”。

命名空间嵌套是将更专业的类型与不太专业的类型分开的一种方式。所以命名空间System包含非常一般和广泛适用的类型 - System.Drawing更专业化,并包含与图像和视觉处理有关的类型。

但是,您应该避免做的事情是使用名称空间根据可访问性对类型进行分组。这绝对是名称空间的滥用 - 并且从长远来看很可能会导致问题(特别是因为扩大类型的可访问性是很常见的 - 但改变它所属的名称空间可能非常困难)。在我看来,只要你在做什么都一致,并且在命名空间之间有一种明显的类型划分,我认为你会没事的。

0

如果您按照您的建议进行操作并不重要,但我认为避免使用“Jokes.Internal”命名空间会更好。我不会认为内部类是“污染”你的根命名空间。

无论如何,我认为使名称空间与您的可见性声明相匹配是绝对不正常的。

1

为了避免污染你的根命名空间,我建议之一:

  • 声明类publicinternal代替(让他们对你的API的用户不可见,大会外)

  • 申报然后为嵌套的内部类Jokers(使得它们不是Jokers类的外部可见)

+0

如果可以的话,我建议将它们嵌入'Jokers'内。 – Timwi 2010-09-09 00:41:58