Question

I often find the need to do something along these lines:

public class OperationResult {   bool succes;   SomeOtherObject someobject; }   public interface ICanDoSomethingWeird {   OperationResult DoMyThing(); } 

Where the OperationResult is really a class that belongs to the ICanDoSomethingWeird interface. I find it very annoying I cannot place it in the namespace of the interface. I’m wondering how other people deal with this. Do you just stick it in the global namespace? or just one namespace up from the namespace where the interface sits?

My current approach is to do rename the OperationResult class to ICanDoSomethingWeird_OperationResult, but am not very impressed by how pretty that is 🙂

Anybody have a better solution?

Answer 1

If OperationResult is a type used solely by ICanDoSomethingWeird and clients of ICanDoSomethingWeird, then it belongs in the same ‘context’ as ICanDoSomethingWeird. That is, it belongs in the same namespace as ICanDoSomethingWeird:

namespace MyNamespace {     public class OperationResult {}      public interface ICanDoSomethingWeird     {         OperationResult DoMyThing();     } } 

Think about the client code. Would you prefer this:

using MyNamespace;  ICanDoSomethingWeird myWeirdThing = ...; ICanDoSomethingWeird.OperationResult result = myWeirdThing.DoMyThing(); 

or this:

using MyNamespace;  ICanDoSomethingWeird myWeirdThing = ...; OperationResult result = myWeirdThing.DoMyThing(); 

The latter makes more sense to me, and is the only option where interfaces are concerned. You cannot declare inner types in interfaces. And do note the general advice regarding nested types:

DO NOT use nested types if the type is likely to be referenced outside of the containing type.