We Keep Coding

What is wrong with testing an object to see if it implements an interface?

In the comments of this answer it is stated that "checking whether the object has implemented the interface , rampant as it may be, is a bad thing"
Below is what I believe is an example of this practice:
public interface IFoo
{
void Bar();
}
public void DoSomething(IEnumerable<object> things)
{
foreach(var o in things)
{
if(o is IFoo)
((IFoo)o).Bar();
}
}
With my curiosity piqued as someone who has used variations of this pattern before, I searched for a good example or explanation of why it is a bad thing and was unable to find one.
While it is very possible that I misunderstood the comment, can someone provide me with an example or link to better explain the comment?

It depends on what you're trying to do. Sometimes it can be appropriate - examples could include:
LINQ to Objects, where it's used to optimize operations like Count which can be performed more efficiently on an IList<T> via the specialized members.
LINQ to XML, where it's used to provide a really friendly API which accepts a wide range of types, iterating over values where appropriate
If you wanted to find all the controls of a certain type under a particular control in Windows Forms, you would want to check whether each control was a container to determine whether or not to recurse.
In other cases it's less appropriate and you should consider whether you can change the parameter type instead. It's definitely a "smell" - normally you shouldn't concern yourself with the implementation details of whatever has been handed to you; you should just use the API provided by the declared parameter type. This is also known as a violation of the Liskov Substitution Principle.
Whatever the dogmatic developers around may say, there are times when you simply do want to check an object's execution time type. It's hard to override object.Equals(object) correctly without using is/as/GetType, for example :) It's not always a bad thing, but it should always make you consider whether there's a better approach. Use sparingly, only where it's genuinely the most appropriate design.
I would personally rather write the code you've shown like this, mind you:
public void DoSomething(IEnumerable<object> things)
{
foreach(var foo in things.OfType<IFoo>())
{
foo.Bar();
}
}
It accomplishes the same thing, but in a neater way :)

I would expect the method to look like this, it seems much safer:
public void DoSomething(IEnumerable<IFoo> things)
{
foreach(var o in things)
{
o.Bar();
}
}
To read about the referred violation of the Liskov Principle: What is the Liskov Substitution Principle?

If you want to know why the commenter made that comment, probably best to ask them to explain.
I would not consider the code you posted to be "bad". A more "genuinely" bad practice is to use interfaces as markers. That is, you're not planning on actually using a method of the interface; rather, you have declared the interface on a class as a way of describing it in some way. Use attributes, not interfaces, as markers on classes.
Marker interfaces are hazardous in a number of ways. A real-world situation I once ran into where an important product made a bad decision on the basis of a marker interface is here: http://blogs.msdn.com/b/ericlippert/archive/2004/04/05/108086.aspx
That said, the C# compiler itself uses a "marker interface" in one situation. Mads tells the story here: http://blogs.msdn.com/b/madst/archive/2006/10/10/what-is-a-collection_3f00_.aspx

A reason is that there will be a dependency on that interface that is not immediately visible without digging in the code.

The statement
checking whether the object has implemented the interface , rampant
as it may be, is a bad thing
Is overly dogmatic in my opinion. As other people have answered, you may well be able to pass a collection of IFoo to your method and achieve the same result.
However, interfaces can be useful to add optional features to classes. For example the .net framework provides the IDataErrorInfo interface*. When this is implemented it indicates to a consumer that in addition to the class' standard functionality, it can also provide error information.
In this case, the error information is optional. A WPF view model may or may not provide error information. Without querying for interfaces, this optional functionality would not be possible without base classes with huge surface area.
*We'll ignore for the moment the terrible design of the IDataErrorInfo interface.

If your method requires that you inject an instance of an interface, you should treat it the same regardless of the implementation.
In your example you generally wouldn't have a generic list of object, but a list of ISomething's and calling an ISomething.Bar() would be implemented by the concrete type, therefore calling it's implementaiton. If that implementation is to do nothing, then you don't have to do a check.

I dislike this whole "switch on type" style of coding for a couple of reasons. (Examples drawn in relation to my industry, game development. Apologies in advance. :) )
First and foremost, I think it's sloppy to have a heterogeneous collection of items. E.g. I could have a collection of "everything everywhere," but then when iterating the collection to apply bullet effects or fire damage or enemy AI, I have to walk this list which is mostly stuff I don't care about. It's much "cleaner" IMHO to have separate collections of bullets, raging fires, and enemies. Note that there's no reason why I can't have a single item in multiple collections; a single burning robotic missile could be referenced in all three of those lists to do parts of its "update" as appropriate for the three types of logic it needs to run. Outside of having "one single collection that references everything," I think a collection containing everything everywhere is not terribly useful; you can't do anything with anything in the list unless you query it for what it can do.
I hate doing unnecessary work. This really ties into the above, but when you create a given thing you know what its capabilities are (or can query them at that point), so you might as well take the opportunity at that time to put them in the right more specific collections. You have 16ms to process everything in the world, do you want to waste your time dealing with, querying, and selecting from generic things, or do you want to get down to business and operate only on the specific things you care about?
In my experience, transforming a codebase from generic operation on heterogeneous datasets to one that has homogeneous datasets has resulted in not only performance increases but also comprehension increases that come from simpler code doing more obvious work and in general a reduction in the amount of code required to do any given task.
So yeah, it's dogmatic to say that querying interfaces is bad, but it does seem to make things simpler if you can figure out how to avoid needing to query anything. As for my "performance" statements and the counter that "if you don't measure it, you can't say anything about it," it should be obvious that not doing something is faster than doing it. Whether or not this is important to an individual project, programmer, or function is up to the person with the editor, but if I can simplify code and while doing so make it do less work for the same results, I'm going to do it without bothering to measure.

I don’t see this as a “bad thing” at all, at least not in itself. The code is merely a literal transcription of “x all of the y in z”, and in a situation where you need to do that, it’s perfectly acceptable. You can of course use things.OfType<Foo>() for the sake of concision.
The main reason to recommend against it is that, according to OOP theology, interfaces are intended to model the different kinds of “black box” for which an object may substituted. Predicating an algorithm on fulfillment of an interface constitutes moving behaviour to the algorithm that should be in that interface.
Essentially, an interface is a behavioural role. If you think OOP is a good idea, then you should use interfaces only to model behaviours, so that algorithms don’t have to. I don’t think what passes for OOP these days is in fact a good idea, so this is as far as my answer can be useful.

Why do core types implement interfaces only partly?

Q1 Why do new classes from .NET implement interfaces only partially?
Q2 Shall I do the same in my code?
I asked this question here, so I thought, okay that was long time ago, you can have different usage etc etc, and now such implementation is supported only for consistency reasons. But new classes also do that.
Old
int[] list = new int[] {};
IList iList = (IList)list;
ilist.Add(1); //exception here
New
ICollection c = new ConcurrentQueue<int>();
var root = c.SyncRoot; //exception here
UPDATE
I am not worried why I get exceptions, it is clear. But I don't understand why classes implement the well defined contract, but not all the members (which can lead to unpleasant run time exceptions)?

You could argue that the interfaces weren't granular enough in the original design. For example, most people never use SyncRoot - it could perhaps have been on a different interface. Likewise, it is unfortunate that no interface offers read-only indexer access, for example.
As it stands, the interfaces are what they are. It is still very convenient to implement the main IList[<T>]/ICollection[<T>]/IEnumerable[<T>] interfaces though - it offers the majority of callers access to what they need... so indexers in the first example, and Add in the second.
To be fair, they do also offer IsFixedSize and IsReadOnly - querying the first would have led you to not call Add. Re SyncRoot - that presumably can't make sense inside ConcurrentQueue<T>, and any implementation would break the logic of the type. Normally I would say "then it isn't that type; don't implement the interface", but to repeat my earlier statement... most people never use SyncRoot - so I'm OK with it ;p

One minor point, all interfaces have to be fully implemented. All methods and properties of an interface must be implemented by any implementor – otherwise the compiler. You are referring to the runtime errors that can be thrown when you call some methods of an interface.
The documentation for IList states:
IList is a descendant of the ICollection interface and is the base interface of all non-generic lists. IList implementations fall into three categories: read-only, fixed-size, and variable-size. A read-only IList cannot be modified. A fixed-size IList does not allow the addition or removal of elements, but it allows the modification of existing elements. A variable-size IList allows the addition, removal, and modification of elements.
When you call a method that cannot be satisfied by a particular implementation then you get an exception.
Why was the interface designed this way? One can only speculate, but this particular design allows for the IsFixedSize, IsReadOnly etc. properties to change during the lifetime of an instance of the interface.
Should you design your interfaces this way? That depends on whether such a design is desirable and meets your needs.

From OOP standpoint this is simply wrong. They should either have made smaller interfaces or not put them on stuff like Arrays. However the .NET Framework designers are not stupid and they probably made some tradeoff. For example IEnumerable is required to implement IDisposable which does not make sense from OOP design standpoint but there are some performance benefits for database readers for example. So probably implementations that are hacked into a class (like your example) have some benefit but from OOP point of view they are wrong and you should not do it unless you are aware what you are trading the good design for.

I suspect the existence of partially-implemented interfaces is a consequence of a design decision not to allow a class or interface to have independent readable property and writable properties of the same name and automatically use them appropriately (e.g. if a class has a readable property 'foo' and a writable property 'foo', use the readable property for reads and the writable one for writes). This design decision made it awkward to split off the reading and writing aspects of certain interfaces.
Ideally, instead of having a single interface IList, there would have been generic contravariant interface IReadableByIndex, generic covariant interfaces IWriteableByIndex, IAppendable, IGrowableByIndex (includes various insert and delete functions), and non-generic IMovableByIndex (index-based copy, swap, and roll functions) and maybe IComparableByIndex (given two indices, compare the items). An interface IList could implement all of those, but there would be many useful subsets as well (many of which could be contravariant or covariant). Note that the existence of some non-generic routines would allow things like sorts to be implemented on any collection that implements IComparableByIndex and IMovableByIndex without having to worry about the exact type of the collection.
Unfortunately, for a split of IList to have been really useful, it would have been necessary to have IReadableByIndex and IWritableByIndex as separate interfaces. This in turn would have posed difficulties when trying to write code that would inherit both interfaces, as the compiler would complain about ambiguity when trying to use the indexed accessor. Since the IReadableByIndex and IWritableByIndex ended up having to be combined, Microsoft probably figured it may as well lump everything into IList.

Why does IList<T> not provide all the methods that List<T> does? Which should I use?

I have always been taught that programming against an interface is better, so parameters on my methods I would set to IList<T> rather than List<T>..
But this means I have to cast to List<T> just to use some methods, one comes to mind is Find for example.
Why is this? Should I continue to program against interfaces, but continue to cast or revert?
I am a little bit confused why Find (for example) isn't available on the IList<T> which List<T> inherits from.

Personally I would use IList<T> rather than List<T>, but then use LINQ (Select, Where etc) instead of the List-specific methods.
Casting to List<T> removes much of the point of using IList<T> in the first place - and actually makes it more dangerous, as the implementation may be something other than List<T> at execution time.

In the case of lists you could continue programming against interfaces and use LINQ to filter your objects. You could even work with IEnumerable<T> which is even higher in the object hierarchy.
But more generally if the consumer of your API needs to call a specific method you probably haven't chosen the proper interface to expose.

I am a little bit confused why Find
(for example) isn't available on the
IList which List inherits from.
While I'm not privy to the decision process of the designers, there are a few things they were probably thinking.
1) Not putting these methods on IList keeps the intent of the contract clearer. According to MSDN, IList "Represents a collection of objects that can be individually accessed by index." Adding Find would change the contract to a searchable, indexable collection.
2) Every method you put on an interface makes it harder to implement the interface. If all of those methods were on IList, it would be much more tedious to implement IList. Especially since:
3) Most implementations of these methods would be the same. Find and several of the others on List would really be better placed on a helper class. Take for example, ReadOnlyCollection, Collection, ObservableCollection, and ReadOnlyObservableCollection. If I had to implement Find on all of those (pre-LINQ), I would make a helper class that takes IEnumerable and a predicate and just loop over the collections and have the implementations call the helper method.
4) LINQ (Not so much a reason why it didn't happen, more of why it isn't needed in the future.) With LINQ and extension methods, all IEnumerable's now "have" Find as an extension method (only they called it Where).

I think it's because IList can be different collection types (ie. an IEnumerable of some sort, an array or so).
You can use the Where extension method from System.Linq. Avoid casting back to List from IList.

If you find that the IList<T> parameter being passed between various classes is consistently being recast into List<T>, this indicates that there is a fundamental problem with your design.
From what you're describing, it's clear that you want to use polymorphism, but recasting on a consistent basis to List<T> would mean that IList<T> does not have the level of polymorphism you need.
On the other side of the coin, you simply might be targeting the wrong polymorphic method (e.g., Find rather than FirstOrDefault).
In either case, you should review your design and see what exactly you want to accomplish, and make the choice of List<T> or IList<T> based on the actual requirements, rather than conformity to style.

If you expose your method with a IList<> parameter, someone can pass, for exemple, a ReadOnlyCollection<>, witch is an IList<> but is not a List<>. So your API will crash at runtime.
If you expose a public method with a IList<> parameter, you cannot assume that it is a specific implementation of an IList<>. You must use it as an IList<> an nothing more.

If the list is some part of an Api or service that is exposed then it is probably better to have as an IList to allow the change of the implementation internally.
There is already much discussion on this topic.

No, in this case it has no sense to program to interfaces, because your List is NOT an IList, having extra methods on it.

How can i implement the NULL Object Design Pattern in a generic form?

Is there a way to implement the null object design pattern in a generic form so that i don't need to implement it for every buisness object.
For me, there are two high level classes you'll need for every business class. One for a single record and another for a list. So i think there should be a way to implement the NULL Object design pattern at a high level and not have to implement it for every class.
Is there a way and how please?

In my understanding, the NULL-class does not have to be implemented for every class you have, but rather for every interface you have. In that case, you could surely write some method that generates an empty standard-implementation for any given interface using reflection. However, the desired behavior of a NULL-object may have special cases for certain interfaces, in which case a generic solution would fail.
For instance, you could have an interface that implements IComparable. In some cases, you may want the NULL-object to be equal to all other objects, and in other cases, you want it to be smaller than all other objects.
EDIT: The IComparable was just an example. The point is, that I do not think it is smart to have a generic NULL-class implementation. You use the NULL-class, so your program can work without having to handle the special cases of NULL return values. If you have a default implementation, then you would most certainly have to check for special cases again, and the whole point of the pattern would be missed.

As discussed already before here an SO, the implementation of a NULL object is domain-dependent, so I don't think there is a general answer to your question. Perhaps you will find a more-or-less generic solution to your kind of business objects. If you provide some examples what you have in mind, you will probably get some better answers.

Which interface should I expose a List<T> via?

In a response to this question runefs suggested that "unless you have a very specific reason for using IList you should considere IEnumerable". Which do you use and why?

IEnumberable<T> is read-only, you have to reconstruct the collection to make changes to it. On the other hand, IList<T> is read-write. So if you expect a lot of changes to the collection, expose IList<T> but if it's safe to assume that you won't modify it, go with IEnumerable<T>.

Always use the most restrictive interface that provides the features you need, because that gives you the most flexibility to change the implementation later. So, if IEnumerable<T> is enough, then use that... if you need list-features, use IList<T>.
And preferably use the strongly typed generic versions.

The principle I follow is one I read a while back:
"Consume the simplest and expose the
most complex"
(I'm sure this is really common and I'm mis-quoting it, if anyone can knows the source can you leave a comment or edit please...)
(Edited to add - well, here I am a couple of weeks later and I've just ran into this quote in a completely different context, it looks like it started as the Robustness Principle or Postel's Law -
Be conservative in what you do; be liberal in what you accept from others.
The original definition is for network communication over the internet, but I'm sure I've seen it repurposed for defining class contracts in OO.)
Basically, if you're defining a method for external consumption then the parameters should be the most basic type that gives you the functionality you require - in the case of your example this may mean taking in an IEnumerable instead of an IList. This gives client code the most flexibility over what they can pass in. On the other hand if you are exposing a property for external consumption then do so with the most complex type (IList or ICollection instead of IEnumerable) since this gives the client the most flexibility in the way they use the object.
I'm finding the conversation between myself and DrJokepu in the comments fascinating, but I also appreciate that this isn't supposed to be a discussion forum so I'll edit my answer to further outline the reasons behind my choice to buck the trend and suggest that you expose it as an IList (well a List actually, as you'll see). Let's say this is the class we are talking about:
public class Example
{
private List<int> _internal = new List<int>();
public /*To be decided*/ External
{
get { return _internal; }
}
}
So first of all let's assume that we are exposing External as an IEnumerable. The reasons I have seen for doing this in the other answers and comments are currently:
IEnumerable is read-only
IEnumerable is the defacto standard
It reduces coupling so you can change the implementation
You don't expose implementation details
While IEnumerable only exposes readonly functionality that doesn't make it readonly. The real type you are returning is easily found out by reflection or simply pausing a debugger and looking, so it is trivial to cast it back to List<>, the same applies to the FileStream example in the comments below. If you are trying to protect the member then pretending it is something else isn't the way to do it.
I don't believe it is the defacto standard. I can't find any code in the .NET 3.5 library where Microsoft had the option to return an concrete collection and returned an interface instead. IEnumerable is more common in 3.5 thanks to LINQ, but that is because they can't expose a more derived type, not because they don't want to.
Now, reducing coupling I agree with - to a point - basically this argument seems to be that you are telling the client that while the object you return is a list I want you to treat is as an IEnumerable just in case you decide to change the internal code later. Ignoring the problems with this and the fact that the real type is exposed anyway it still leaves the question of "why stop at IEnumerable?" if you return it as an object type then you'll have complete freedom to change the implementation to anything! This means that you must have made a decision about how much functionality the client code requires so either you are writing the client code, or the decision is based around arbitrary metrics.
Finally, as previously discussed, you can assume that implementation details are always exposed in .NET, especially if you are publicly exposing the object.
So, after that long diatribe there is one question left - Why expose it as a List<>? Well, why not? You haven't gained anything by exposing it as a IEnumerable, so why artificially limit the client code's ability to work with the object? Imagine if Microsoft had decided that the Controls collection of a Winforms Control should appear as IEnumerable instead of ControlCollection - you'd no longer be able to pass it to methods that require an IList, work on items at an arbitrary index, or see if it contains a particular control unless you cast it. Microsoft wouldn't really have gained anything, and it would just inconvenience you.

When I only need to enumerate the children, I use IEnumerable. If I happen to need Count, I use ICollection. I try to avoid that, though, because it exposes implementation details.

IList<T> is indeed a very beefy interface. I prefer to expose Collection<T>-derived types. This is pretty much in line with what Jeffrey Richter suggests doing (don't have a book nearby, so can't specify page/chapter number): methods should accept the most common types as parameters and return the most "derived" types as return values.

If a read-only collection is exposed via a property, then the conventional way to do it is to expose it as ReadOnlyCollection (or a derived class of that) wrapping whatever you have there. It exposes full capabilities of IList to the client, and yet it makes it very clear that it is read-only.