Interfaces and classes in the same assembly. Best Practices?

[Robert Zurer]

I notice that Microsoft puts their interfaces and classes in the same
assembly. For example System.Data contains OleDbConnection and
IDbConnection etc.

I have found it useful to keep my interfaces in a separate assembly for
a number of reasons. Among them are

Avoiding circular references
Hiding implementation from a remoting client
Supporting polymorphic behavior across classes

Even more important to me though, is that interfaces represent the
outward facing behavior of my classes. If I create an interfaces
assembly, it should be able to stand on it's own using only FCL
assemblies and maybe some enumerations/constants. That has the result of
keeping my design "honest" so to speak.

The downside is twice the number of assemblies.

What is considered the best practice?

Thanks
Robert Zurer

ro****@zurer.com

[Sherif ElMetainy]

Hello

I notice that Microsoft puts their interfaces and classes in the same
assembly. For example System.Data contains OleDbConnection and
IDbConnection etc.

This is not always the case. For example IDisposable interface is in
mscorlib assembly, and there are classes implementing it in all other
assemblies. like SqlConnection in System.Data. There is nothing against
separating the interface from the class implementing it, and sometimes this
is essential.

Best regards,
Sherif

[Sherif ElMetainy]

Hello

I notice that Microsoft puts their interfaces and classes in the same
assembly. For example System.Data contains OleDbConnection and
IDbConnection etc.

This is not always the case. For example IDisposable interface is in
mscorlib assembly, and there are classes implementing it in all other
assemblies. like SqlConnection in System.Data. There is nothing against
separating the interface from the class implementing it, and sometimes this
is essential.

Best regards,
Sherif

[Michael Riggio]

We always have our interfaces in a separate assembly for the exact reasons
you stated below.

"Robert Zurer" <ro****@zurer.com> wrote in message
news:MP************************@news.microsoft.com ...

I notice that Microsoft puts their interfaces and classes in the same
assembly. For example System.Data contains OleDbConnection and
IDbConnection etc.

I have found it useful to keep my interfaces in a separate assembly for
a number of reasons. Among them are

Avoiding circular references
Hiding implementation from a remoting client
Supporting polymorphic behavior across classes

Even more important to me though, is that interfaces represent the
outward facing behavior of my classes. If I create an interfaces
assembly, it should be able to stand on it's own using only FCL
assemblies and maybe some enumerations/constants. That has the result of
keeping my design "honest" so to speak.

The downside is twice the number of assemblies.

What is considered the best practice?

Thanks
Robert Zurer

ro****@zurer.com

[Michael Riggio]

We always have our interfaces in a separate assembly for the exact reasons
you stated below.

"Robert Zurer" <ro****@zurer.com> wrote in message
news:MP************************@news.microsoft.com ...

I notice that Microsoft puts their interfaces and classes in the same
assembly. For example System.Data contains OleDbConnection and
IDbConnection etc.

I have found it useful to keep my interfaces in a separate assembly for
a number of reasons. Among them are

Avoiding circular references
Hiding implementation from a remoting client
Supporting polymorphic behavior across classes

Even more important to me though, is that interfaces represent the
outward facing behavior of my classes. If I create an interfaces
assembly, it should be able to stand on it's own using only FCL
assemblies and maybe some enumerations/constants. That has the result of
keeping my design "honest" so to speak.

The downside is twice the number of assemblies.

What is considered the best practice?

Thanks
Robert Zurer

ro****@zurer.com