Wrapping Business Logic In Extension Methods For POCOs

Question

I have recently stumbled upon a use case of extension methods and wanted to gather some design thoughts.

The problem: A IEnumerable of a POCO and within that list there should exist a POCO that satisfies a condition say POCO.IsTheRightOne == true.

You could write and extension class for this query

public static class POCOExtensions
{
   public static bool GetIsTheRightPOCO(this List<POCO> source){
      return source.Single(poco => poco.IsTheRightOne == true).UsefulProperty;
   }

}

Now this to me is clean. It is easily testable, their is no need for a utils or helper class to be in the middle, the logic is encapsulated, and no side effects or other classes are needed.

Another way I could go about this is create a POCOList class and wrap the behavior in that and then you would get the same benefits and still have the ability to override behavior if needed. But since this is a poco class chances of me needing that are pretty slim.

Something about this pattern though just doesn't sit right with me. I feel like I'm paying a unseen cost. What other drawbacks to this design am I missing?

Answer 1

Extension methods are Bad(tm)

1. Static methods cant be mocked out

   Sure you can test this method, but can you unit test something that uses it?

2. Extension methods are hard to find.

   Unless you know the namespace and package to include for this method you have no way to find it. As opposed to a method on the Poco itself or a service for the over all operation.

3. It has all the downsides of a helper library.

   What you have here is a orphaned helper method, It's hard to name, it's hard to group up with the data or other object that need it, its hard to know what references it and what will break if you change it.

Instead, I would suggest this should be a private method on a service class which does whatever larger operation you are performing with your Pocos. That encapsulates it with other methods and data related to the process and gives you a nice DoWhateverWithPocosService() class which can be interfaced and mocked as required.

Answer 2

My litmus test whether to use extension methods - or not - are the following two criteria:

1. One cannot easily add the method to the extended type directly, because it would require changing a library outside of ones control, or add an undesired dependency to the library where the type is defined.

   List<T> is part of the framework, so clearly out of your control. But as you said, you could derive POCOList from List<POCO> and hence create a type which you can extend.

2. The added method "fits well" to the abstraction of the type which gets extended.

   By "fits well", I usually think of methods which are not exclusively supporting just one specialized use case, but make sense for the type itself, often with some potential to be reused in different use cases (at least in the context of the application or system where the extension method "lives"). Note this is also a criterion I would expect to be fulfilled for a derivation like POCOList.

Sure, the second criterion may be somewhat opinionated, but the way you described, it seems this is not fulfilled here. Hence I think Ewan's suggestion to place a method in the outer context (like some service) is ok here.

Where I strongly disagree to that (otherwise good) answer, however, is that extension methods are "generally bad". Such statements are quite unprofessional and too dogmatic for my taste.