In C#/VB, how do YOU determine whether a method is declared normally or as an extension method?

Question

Extension methods are useful for types that you don't own and can't/don't want to derive from and extend (e.g. reference types and interfaces).

Obviously, interfaces should be kept as short and to-the-point as possible, so extension methods for interfaces are particularly useful (e.g. LINQ).

For classes, especially classes that you own, they're still useful - but I'm wondering how you determine what should be an extension method or what should be a method in the class itself.

Personally, every time I think about it, I keep going round in circles with the following thoughts:

• If it's useful enough, it should be in the class.
• It's not part of the core responsibility of the class, it should be an extension method - but if it's useful enough, surely it should be the responsibility of the class...

What do you think?

Answer 1

Typically, I limit the creation of extension methods to interfaces only, e.g.:

public ISomething GetSomething(this ISomewhere somewhere) {  }

This is mainly because you want to perform some common operation on an interface, but because interfaces don't have an implementation, we can't.

The other time I will create extension methods, is for types that I don't own, but want to wrap up a series of operations into a single method.

Answer 2

Extension methods are usefull for extending classes that you don't have the source code for, especially if you want to extend a bunch of classes that derive from a particular base, but don't want to create your own derived version of them just to add a new method. They can also be usefull when you want to extend some classes that implement one or more interfaces, but you cannot make them all derive from a base class. I wouldn't really user them for anything else.

Answer 3

I come across this exactly situtation in a project using DDD architecture and find extension methods really useful for decorating the class with behaviors that is only suitable for a particular context/layer but not necessarily part of the core functionality.

A simple example: say in the underlying domain model you may have a Student entity which encapsulates all its core operations such as enroll, attend, defer and etc. Say one of the subsystem in the project allow student to register for job notification and being notify by email when new job is posted. The behaviors such as student.registerForJob and student.notifyJobPosting aren't really the core functionality. So even though I have the full access to Student class code, I wouldnt add these behaviors to the Student core entity as it may breaks your design boundary or principles (such as open/closed or YAGNI) Instead, it make more sense to create these extension methods for Student entity within the job posting subsystem only.

Obviously sub classing Student through inheritance can also allow you to achieve the same thing, but extension method clearly offer a very flexible alternative. In essence, extension method is really a way to realize the use of decorator design pattern. Read more into the motivation of using decorator design pattern may clarify those doubts even further.