Interfaces and classes in the same assembly. Best Practices?

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

robert@zurer.com

re: Interfaces and classes in the same assembly. Best Practices?

Hello
[color=blue]
> I notice that Microsoft puts their interfaces and classes in the same
> assembly. For example System.Data contains OleDbConnection and
> IDbConnection etc.[/color]

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

re: Interfaces and classes in the same assembly. Best Practices?

Hello
[color=blue]
> I notice that Microsoft puts their interfaces and classes in the same
> assembly. For example System.Data contains OleDbConnection and
> IDbConnection etc.[/color]

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

re: Interfaces and classes in the same assembly. Best Practices?

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

"Robert Zurer" <robert@zurer.com> wrote in message
news:MPG.1af015017b96186e989687@news.microsoft.com ...[color=blue]
> 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
>
> robert@zurer.com
>
>
>
>
>
>[/color]

re: Interfaces and classes in the same assembly. Best Practices?

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

"Robert Zurer" <robert@zurer.com> wrote in message
news:MPG.1af015017b96186e989687@news.microsoft.com ...[color=blue]
> 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
>
> robert@zurer.com
>
>
>
>
>
>[/color]