contract/interface c# system achitecture

[Guest]

Hi,

I have a C++ background and am new to C#.
At the moment I'm working on a project where I want to define a contract for
users of my library. I have done this by creating a interface dll project
containing the contract for the clients. To implement the interface I created
a second dll project that contains the implementation. The interface has an
assync design. It also has a factory that, based on configuration data, can
load different implementation assemblies. This is transparent for the client
and the reason for doing so is that the implementation is very computational
heavy and might need to be done on a separate machine e.g. with .NET
remoting. Having the contract defined in this manner means I can easily
replace the implementation without the client knowing.

Is there a better way of doing this in C#?

Filip

 

[Pop Catalin]

There might be a better way, from the versioning and upgradability's
point of view, wich is to use an abstract base class instead of an
interface if this is posible. Using an abstract class instead of an
interface allows ading new members (but not abstract, only virt or non
virt) without beaking posible implentations of the class wich you might
not now about(it there will ever be the case).

 

[Nicholas Paldino [.NET/C# MVP]]

I wouldn't say this is better, especially in an environment like .NET.
Because you only have single inheritance, using a base class means that you
force the implementer to burn the base, which isn't exactly good design.

When requiring an implementation of a contract from external sources, I
would say you should always take an interface. You can provide an abstract
base class which implements the interface to make things easier, but an
interface should always be preferred.

 

[Wiebe Tijsma]

I wouldn't say this is better, especially in an environment like .NET.
Because you only have single inheritance, using a base class means that you
force the implementer to burn the base, which isn't exactly good design.

When requiring an implementation of a contract from external sources, I
would say you should always take an interface. You can provide an abstract
base class which implements the interface to make things easier, but an
interface should always be preferred.

I'd prefer a base class for types with many operations, and keep
interfaces clean with a minimal amount of operations.

Like the XPathNavigator base class / IXPathNavigable interface combination.

This forces you to separate your logic, and doesn't require you to
clutter up classes with too many methods for complex interface
implementations.

Regards,

Wiebe Tijsma

 

[Mark Wilden]

I wouldn't say this is better, especially in an environment like .NET.
Because you only have single inheritance, using a base class means that
you force the implementer to burn the base, which isn't exactly good
design.

What does "burn the base" mean?

///ark

 

[Nicholas Paldino [.NET/C# MVP]]

Mark,

Since .NET only allows for a class to derive from a single base class,
if you provide an abstract class, as opposed to an interface, you force the
user to provide an implementation which derives from the abstract class.
You burn their opportunity to provide their own base class (which might make
their implementation easier/cleaner/easier to maintain/etc/etc).