By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,888 Members | 1,553 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,888 IT Pros & Developers. It's quick & easy.

Interfaces and classes in the same assembly. Best Practices?

P: n/a
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


Jul 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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
Jul 21 '05 #2

P: n/a
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
Jul 21 '05 #3

P: n/a
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


Jul 21 '05 #4

P: n/a
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


Jul 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.