We Keep Coding

How to distinguish 'Role' interfaces from 'Result' interfaces?

This issue comes up for me so often in my coding that I'm astonished I can find so little reference to it, and would value other people's thoughts and ideas.
I define lots of APIs, for the frameworks I work on, and within large domain models that I want to break up. Those APIs consist almost entirely of interfaces (meaning, in my case, C# interfaces). I find, over and over again, that I want to distinguish between two kinds of interface. In the absence of finding any more widely used terms, I define these two as follows:
'Role' interfaces are intended to be implemented by objects outside of the API, in order that those objects can be used as arguments for methods defined on the API.
'Result' interfaces are implemented by objects inside the API and made available to other parts of the system via the API. The intent of defining a result interface rather than exposing the object that implements it is to restrict the view of the object to the outside world.
To pick one example, a Payments sub-system might define IPayableItem as a Role interface, implemented by many types in other parts of the application in order that Payments may be generated for them. Those generated Payment objects may be retrieved via the API but defined by the Result interface IPayment.
The only way I can currently distinguish these is by naming convention and/or commenting. Ideally, I would like the distinction enforced by the language, and have it enforce the rule: you can't implement a Result interface outside the API, only use it. But C# doesn't provide any such mechanism. (Can anyone advise me of a language that does?). I could define an attribute, but this still wouldn't enforce anything.
Another important significance of the distinction lies in Semantic Versioning of the API. If I add a new member to a Role interface then this should be seen as a breaking change (and hence a first-level version) - because any existing external implementations will need to add that member. But if I add a member to what I deem to be a 'Result' interface then it should only be my own code that is impacted - it is just a new feature (second-level version) for everyone else. But with no enforced distinction between the two types there's some risk that people are implementing the Result interfaces and hence their code would be broken.
Has anyone else encountered this dilemma? If so, how have you dealt with it? I look forward to your answers.
But please don't both to respond with either of the following arguments (which I have heard all too often):
My Result interfaces should be abstract classes rather than interfaces. This does not solve the problem, and potentially makes it worse, since external code can sub-class them.
I should be returning the concrete type and ensuring that anything I don't want accessible outside the API is marked 'internal'. There are lots of cases where I need things inside the API to be public, e.g. to be accessible to other frameworks (not going through the API).

I think what you're asking is it possible to expose an interface, but determine that a given instance is one you created?
If so, you could also create an internal private interface, and mark all your implementations as also implementing the private interface. Then upon being given an object from the outside world, verify it has the internal interface implementation as well.
public interface IPublic
{
...
}
internal interface ISecret { }
public class PublicImplementation : IPublic, ISecret
{
...
}
Only you can implement the ISecret, so even if someone implements the IPublic and passes it to you, it will fail the ISecret test.

Is there a reason to use abstract or interface except for coordination between developers? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Interface vs Abstract Class (general OO)
I can see their advantage in coordination of a developing team, or code that might be further developed by others.
But if not, is there a reason to use them at all? What would happen if I omit them?
Abstract – I'll be able to instantiate it. No problem. If it doesn't make sense – I won't.
Interface – I have that functionality declared in all classes deriving from it anyway.
Note: I'm not asking what they are. I'm asking whether they're helpful for anything but coordination.

Both are what I call contracts and can be used in the following fashion by an individual developer:
Abstract
Allows for polymophism of differing derived implementations.
Allows one to create base functionality which can be dictated or not that the derived class be required to implement.
Allows for a default operation to be runtime consumed if the derived does not implement or required to implement.
Provides a consistency across derived objects which a base class pointer can utilize without having to have the actual derived; hence allows generic operations on a derived object from a base class reference similar to an Interface in runtime operation.
Interface
Allows a generic pattern of usage as a defacto contract of operation(s).
This usage is can be targetted to the process in hand and allows for the
surgically precise operations for that contract.
Used to help with
factory patterns (its the object returned), mocking of data during
unit tests and the ability to replace an existing class (say from a
factory returning the interface) with a different object and it
doesn't cause any consumer of the factory any pain of refactoring due to the adherence of the interface contract.
Provides a pattern of usage which can be easily understood away from the static of the rest of the class's implementation.
Long story short are they required to get a job done? No.
But if you are into designing systems which will have a lifespan of more than one cycle, the upfront work by said architect will pay off in the long run whether on a team or by an individual.
++Update
I do practice what I preach and when handing off a project to other developers it was nice to say
Look at the interface IProcess which all the primary business classes adhere to. That process defines a system of goals which can help you understand the purpose and the execution of the business logic in a defined way.
While maintaining and adding new functionality to the project the interfaces actually helped me remember the flow and easily add new business logic into the project.

I think if you're not coordinating with others, it does two things
helps keep your from doing weird things to your own code. Imagine
your write a class, and use it in multiple projects. You may evolve
it in one project so that it is unrecognizable from it's cousin in
another project. Having an abstract class or interface makes you
think twice about changing the function signatures.
it gives you flexibility going forward - plenty of classic examples here. Use
the generic form of the thing you're trying to accomplish, and if
you decide you need a different kind later (streamreaders are a
great example, right?) you can more easily implement it later.

Abstract - you can instantiate a child of it, but what is more important, it can has its own non abstract methods and fields.
Interface - more "rough" one in regard of abstract, but in .NET you can have multiple inheritance. So by defining interface you can lead consumer of your interface(s) to subscribe to different contracts(interfaces), so present different "shapes" of specified type.

There are many reasons to use either construct even if you are not coordinating with anyone. The main use is that both actually help express the developper intent, which may help you later figure out why you choose the design you actually chose. They also may allow for further extensibility.
Abstract class allow you to define one common implementation that will be shared across many derived classes while delegating some of the behavior to the child classes. It allows the DRY (don't repeat yourself) principle to avoid having the same code repeated everywhere.
Interfaces expresses that your class implements one specific contract. This has a very useful uses within the framework, among which:
Use of library functionality that necessitate the implementation of some Interface. Examples are IDisposable, IEquatable, IEnumerable...
Use of constraints in generics.
Allow mocking of interfaces (if you do unit testing) whithout having to instanciate a real object.
Use of COM objects

Explicit interface implementation for COM interfaces in C#

Some time I ago I was working on a major refactoring of an old Win32 program implemented with COM, and there were various parts that were implemented with C# (.NET). During my work on this project, I ran across a Microsoft page on COM programming in C# that recommended C# classes explicitly implement COM interfaces, rather than implicity. I recently tried to remember why, and I couldn't. I also couldn't find the page on the MSDN site again. Can anybody please tell me why Microsoft might recommend this ?

Hmm, that makes a wee bit of sense, COM is pure interface-based programming and the actual implementation of the interfaces should be hidden. Implementing interface methods explicitly gets you that automatically because they cannot be public.
Actually doing this is quite pointless, you could (and should) simply apply the [ClassInterface(ClassInterfaceType.None)] attribute to the class. That by itself ensures that the implementation isn't exposed, only the interfaces implemented by the class are visible. Implementing the interface methods explicitly isn't actually good enough. Because you cannot hide the fact that your class inherits System.Object. Which exposes the four public methods of Object and puts a reference to mscorlib.tlb in your type library, a reference that a real COM client will never use. It will almost always work because the odds that the compiler that uses your class runs on a machine that doesn't have .NET installed are pretty small. But very yucky nonetheless, it isn't actually required. Only the machine that uses the class needs it installed.
Just don't do this. Declare the interfaces you implement, give them the [InterfaceType(ComInterfaceType.InterfaceIsDual)] attribute to allow them to be used both early and late bound. And hide the actual implementation of them with [ClassInterface(ClassInterfaceType.None)]. Only sensible way.

It's old, but from here: http://msdn.microsoft.com/en-us/library/aa288461%28v=VS.71%29.aspx they mention implementing an interface explicitly so you can implement multiple interfaces that have the same member names.
This also requires that the user of your class cast an instance of your class to the appropriate interface.
As for why this is especially important for COM: my first guess is so that COM can call one set of methods while managed code may call another. However, I'm guessing here.

What is the major use of MarshalByRefObject?

What's the purpose for MarshalByRefObject?

Remoting; it means that between AppDomains or machines, rather than serialize and transfer the object, the object stays at one end and a proxy is created at the other. All method calls to the proxy are intercepted and the call is transmitted as RPC wiki, msdn, causing the method to execute on the other machine (typically serialising the arguments and return value).
Note: this can lead to unexpectedly "chatty" interfaces. The object/proxy/RPC approach is now less preferable to approaches with an explicit service boundary; Microsoft now recommends WCF wiki, msdn instead of remoting.

Another important use of MarshalByRefObject is for implementing AOP via remoting sink-chains.
If you have an object that derives from ContextBoundObject (which itself derives from MarshalByRefObject) you can instantiate it in a separate Context within the same AppDomain and have communications between objects automatically go through the Remoting proxy system - allowing you to plug custom sinks into the Remoting sink-chain.
This ultimately allows you to 'decorate' method calls to your objects and implement cross-cutting services, such as logging and security etc.

it basic use is for support access of objects between two appdomains and these appdomains can be on the same computer or in the different computers via remoting.
See Here

Any object outside the application domain of the caller application should be considered as Remote Object. A Remote Object that should be derived from MarshalByRefObject Class. Any object can be changed into a Remote Object by deriving it from MarshalByRefObject. Objects without inheriting from MarshalByRefObject are called Non-remotable Objects.

Exposing C# via COM for C++ Client

we're considering exposing some C# types to C++ clients via COM. What problems can we expect to hit over the life of the project? E.g. how will versioning be managed?
On versioning, it would seem from reading this that we should decorate our types to be exposed with [ClassInterface(ClassInterfaceType.None)] and use an explicit interface. That way I assume we fully control the interface that will be exposed to COM clients.
Thanks in advance.

Since you are using a C++ client you should definitely use explicit interfaces for early binding. Dispatch interfaces are useful when using scripting clients such as VBS but they are rarely useful for C++ clients.
The only way to version an interface is to create a new interface (possibly inheriting from the original interface). When using explicit interfaces you have full control over this process.
This means you should create an interface for every class that you intend to expose via COM. Don't forget to mark every interface and class with the ComVisible and Guid attributes. Also all your classes must have a default constructor.

You'll have to read about the GUID attribute (including this) to maintain binary compatibility and only rebuild the clients when necessary.
Also you might be interested in the ComVisible attribute that helps reduce registry pollution.

To get full control over COM interfaces, define them in MIDL. Build a type library with those interfaces in a C++ project, then import type library to C# and implement interfaces.
This approach is useful with complex interfaces where marshaling is not trivial.
Versions should be done COM-style, changing GUIDs and adding new or inheriting interfaces.