Is there a recognized pattern for useless objects that implement an interface?

Question

For example, (although it's not an interface) the Stream class in .NET has an implementation provided by Stream.Null which simply discards the data. PowerShell has Out-Null.

In applications I've developed, I've often found it useful to implement an interface IFoo with a default implementation NullFoo or similar when it is preferable to have a useless implementation rather than not passing an object at all.

My question is how should I refer to this practice in documenting or explaining an architecture? Is there a recognized name or GoF/Fowler design pattern for this?

Answer 1

This pattern is often refered as "NullObject" : http://en.wikipedia.org/wiki/Null_Object_pattern

Answer 2

Yep. It's the Null Object pattern.

Answer 3

Apparently it has a name, "NullObject", but the question can have a different facet:

Right from the start my whole project implementation consists on either Stub methods or Data sinkers.

I use the term "Stub" referring to external interfaces that do not yet have an implementation (but already give you a meaningfull return, allowing you to build the project from day 1).

I use a "Sinker" referring to an interface which allows me to direct data to it, but really it goes nowhere else from there, and it's not the sender's fault (so it would be cumbersome to code "don't send" condition within that scope).

Must achieve a full build, AND THEN, we start coding. With time almost all stubs become functional (and some will treat or source data) and almost all sinkers become functional. At code reviews we find that some sinkers can cease to exist, others can be grouped, etc, etc.

Answer 4

• The object seems to be called a Null Object, as other posters have pointed out
• If you are programming in the .Net environment, you might want to follow the Microsoft convention which is 'Empty' (as in String.Empty). See the following .Net BCL Examples Search