C#/.Net强制执行（或者只是'；提示其他开发人员'；）一个类方法只能从另一个特定类调用？

我目前正在做一些特定于领域的内部库开发，顺便说一句，我试图建模的东西很好地模拟了“类”和“对象”的关系。因此，对于扮演对象或实例角色的C#classMyClass对象，我的C#classMyObject对象的行为应该类似于特定于域的类。现在我想让MyObject中的代码访问MyClass的方法，项目中的其他类/代码不应该访问这些方法。任何关于如何执行这一点的想法，都可以在希望我的开发伙伴们尊重这一点的时候通过文档记录下来

我希望我的问题说得足够清楚，否则请告诉我

---

致以最良好的祝愿

您始终可以将

MyClass

和

MyObject

拆分为另一个项目，并将

MyClass

和/或

MyObject

定义为

内部

类。这样，它只能由该程序集中的其他对象访问

---

请参阅：

这里的标准方法是声明成员

内部

，并确保MyClass和MyObject是同一程序集的一部分。该大会不应包含任何其他内容

附加：这是为此目的而设计的工具。其他语言有其他方法来微调可访问性（C++:

friend

），但在.NET中选择了一个更简单的模型

---

您不必如此严格地接受“nothing other”，这两个类可以与其他相关类共享一个程序集。然后，您必须在该库中手动验证禁止访问规则。

如果您不希望您的使用者调用特定于实现的方法，您可以尝试抽象到接口或抽象基类。这样，消费者将只“看到”您希望他们看到的属性和方法

您不必使用继承来提供共享功能，也不必依赖成员可访问性来阻止其他人使用您不愿意公开的方法

例如：

public interface IDomainSpecific
{
   void DoStuff();
} 

public interface IDomainService
{
   void HelpMeDoStuff();
}

public class DomainObject1 : IDomainSpecific
{
  private readonly IDomainService _service;

  public DomainObject1( IDomainService service )
  {
    _service = service;
  }

  public DoStuff()
  {
    // Do domain specific stuff here 
    // and use the service to help
    _service.HelpMeDoStuff();
  }
}

这使用了经典的构造函数注入，当您已经在应用程序中使用依赖项注入时效果最好，尽管它在工厂中也能很好地工作

关键是要明确责任。任何人都不可能调用任何他们不应该调用的东西，因为“DomainObject”永远不知道实现共享服务的具体类型。共享服务也未在域对象上公开。额外的好处是可测试性，并且可以在不接触DomainObject的情况下使用另一个实现来交换服务。

我建议使用一个。这样，即使您的开发伙伴在同一名称空间中编写代码，他们也永远无法访问该类

一旦类声明完全包含在另一个类声明中，该类就被认为是嵌套的，并且只能通过包含该类的类进行访问

---

也许您的MyObject应该从MyClass派生，并将MyClas中的方法声明为受保护的

沃特？对我来说（我和其他一些人打赌）“类”==“对象”。我发现你的问题令人困惑。对象是类的实例，我不确定你是否有两个类，一个称为MyObject，一个称为MyClass，或者你是否有一个类和一个对象？@Will:我建议你将MyClassas理解为MyCategoryRight，我可能在这里选择了令人困惑的措辞，但是我想表达一种我们通常在类和这个类的对象之间，但是在运行时的对象之间的关系。这让事情变得更清楚了还是更糟了？@S.C.我认为亨克的回答最能解决你的问题。您只需要确保MyClass和MyObject位于同一个程序集中，并且其中没有任何其他程序可以访问MyObject的内部方法。我假设他希望两个类上的某些方法都可以公开访问，但他希望其中一个类上的某些方法只能被另一个类访问，而不能被其他类访问可公开访问。这个解决方案使整个第二个类公开地不可访问。这是一个很好的建议，但是我需要从“工厂”实例化这两种对象，这在运行时会有所不同。我不确定嵌套类是否能处理这个问题？所以我应该只为两个类创建一个程序集？所以我应该只为这两个类创建一个程序集？我认为这似乎有点“沉重”。谢谢你的建议。也许吧，但这取决于你的申请；如果在这些类中有很多特定于领域的逻辑，那么一个新的项目可能是将这些逻辑与应用程序的其余部分分离开来的好方法。你能举个例子吗？抽象和可访问性是不同的。S.C.在接口和抽象基类方面仍然会遇到同样的问题。@Dave White:他必须隐藏构造函数并创建工厂方法来创建实例，但这不是什么大问题。至少它可以作为“对其他开发人员的提示”。@TMN-当然。完全可行。但是你在原始答案中加入了“可访问性”的概念，这个概念本身是不完整的，不能解决OP的问题；“实例”的公共（公共？）接口以及“实例”与其“类”之间的约定。后者是一个内部依赖项，可以注入到“实例”中。这将使内部结构与公共内容完全分离。不管每个类驻留在哪个程序集中。好吧，我不认为我的“实例”是一个“类”，所以这似乎是错误的。听起来好像MyObject为MyClass的实例建模。