views:

412

answers:

10

All over our codebase we have this repeated pattern where there's an interface with one method. Is this a real design pattern? If so what is it and what would the benefits be?

Here are a few examples:

    public interface IRunnable
    {  
     void Run();  
    }

    public interface IAction
    {
        void Perform();
    }

    public interface ICommand
    {
        void Execute(ActionArgs _actionargs);
    }
+5  A: 

I've seen this referenced as the Command pattern.

I first learned about it reading Uncle Bob's Agile Principles, Patterns, and Practices in C#.

I believe its elegance is its simplicity. I've used it when I wrote a file processing service. The service performed all of the administration of reading / deleting files. When a file needed to be processed, it's respective plugin was loaded. Each plugin implemented a Process method, and did whatever was needed to process that type of file. (Mainly, parse the contents and insert into a database.)

Everytime I had to process a new file type with a new layout, all I had to do was create a new Plugin that implemented Process.

This worked for me because I needed a simple solution. If you need to take in more than one parameter, this probably is not the pattern to use.

Aaron Daniels
+1  A: 

This was a big thing back in the day for early Java dev. Main benefit was for standardization of naming.

Not sure what it was called though.

theG
+2  A: 

Any of these could very well be specific cases of the Command Pattern, depending on how it's being used and the context. Part of this would depend on why and how you're setting this up.

The command pattern also normally includes a concept of state and of various objects. Typically, this type of interface would suggest that, so I'm guessing this is what you are thinking of as a design pattern here, but without the caller or multiple targets it's difficult to tell if this is a classic example of it or not...

However, this, in and of itself, is just basic interface abstraction to me, and not something I'd classify as a design pattern.

Reed Copsey
+1  A: 

I'm not sure whether you could call it a design pattern as the interfaces you provided does not provide solutions to commonly experienced problems but rather solution to very specific problems in the project that you're developing.

The reason you're properly using interfaces is due to the fact that you cannot have all your classes that needs these methods extend a base class that contains these, yet you need to know that specific classes promise to implement these.

Might be, as some of the previous posters suggested: http://en.wikipedia.org/wiki/Command_pattern

Qua
+1  A: 

You can remove this repetition (or prevent it for future code) by using lambda expressions. Lambda expressions are exactly for this situation.

Jules
+1  A: 

If anything, then it's a functor. It's used in languages without first class function( pointer)s for the sort of things function( pointer)s are used for, such as the main function for a thread.

Pete Kirkham
+1  A: 

There are applications for Interfaces with only one method. I mean, in .NET there are plenty - INotifyPropertyChanged, for one (the PropertyChanged event). It just guarantees that an object has a certain method (regardless of what type of object it actually is), so you can call it (again, regardless of type).

Dim runnableObjects As List(Of Object)
runnableObjects.Add(New MyRunnableObject1)
runnableObjects.Add(New MyRunnableObject2)

For Each o As IRunnable In runnableObjects
  o.Run()
Next
Brandon Montgomery
+2  A: 

As It was said it is a Command Design Pattern. But it is ( as for me ) more like Java way of achieving the result. In C# you can use delegates and in the C++ function pointers and functors.

There is no big sense to create more and more classes if you already have some implementation of the reaction in a some Class method. Which you can bind in the C++ or set to delegate in the C#. In Java I suppose you have no choice but to write the code you have found.

Mykola Golubyev
A: 

Maybe I'm missing something, but the first two look like they could be part of the strategy pattern. Basically, an object has a member of type IAction, and that member is assigned/reassigned at runtime based on the needs of the system to perform a task in a particular way (ie using a particular strategy).

SnOrfus