C#/.Net enforcing (or just 'hint to fellow developers') that a class method is only supposed to be called from another specific class?

I'm doing some internal domain-specific library development at the moment, and incidentally the stuff i'm trying to model mimicks "class" and "object" relations fairly well. So objects of my C# class MyClass should sort of act like a domain specific class for objects of my C# class MyObject who play the part of object or instance. Now I would like the code in MyObject to access methods of MyClass, which should not be accessible t开发者_运维百科o other classes/code in the project. Any ideas how to enforce this, asside from documenting it at hoping my fellow developers will respect this.

I hope I made my question clear enough, otherwise let me know.

Best regards!

You could always split MyClass and MyObject up into another project, and define MyClass and/or MyObject as an internal class. That way it can only be accessed by other objects in that assembly.

See: http://msdn.microsoft.com/en-us/library/7c5ka91b(VS.80).aspx

The standard approach here is to declare the members internal and make sure MyClass and MyObject are part of the same assembly. That assembly should contain little else.

Additional: This is the tool that was designed for this purpose. Other languages have other means to fine-tune accessibility (C++: friend) but in .NET a simpler model was chosen.

And you don't have to take the 'nothing else' so strictly, the 2 classes could share an assembly with other related classes. you would then have to verify the no-access rule(s) manually inside that library.

I'd suggest a private nested class. That way, even if your fellow devs are writing code in the same namespace, they'll never be able to access the class.

Once the class declaration is fully enclosed within another class declaration, the class is considered nested and can only be accessed through the containing class.

Pehaps your MyObject should descend from MyClass and declare the methods in MyClas as protected.

If you don't want your consumers to invoke certain implementation specific methods you could try abstracting to interfaces or abstract base classes. That way the consumer will only 'see' the properties and methods you want them to see.

You do not have to use inheritance to provide shared functionality and you do not have to rely on member accesibility to prevent others from using methods you'd rather not expose.

For example:

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();
  }
}

This uses classic constructor injection and works best when you already use dependency injection in your application, though it works perfectly well with factories as well.

The point is to keep responsibilities crystal clear. There's no chance of anybody invoking anything they shouldn't because the 'DomainObject' never knows what concrete type implements the shared service. The shared service is not exposed on the domain object either. The added bonus is testability and the possibility of swapping the service with another implementation without ever needing to touch the DomainObject.