Static / Shared Helper Functions vs Built-In Methods
- by Nathan
This is a simple question but a design consideration that I often run across in my day to day development work. Lets say that you have a class that represents some kinds of collection.
Public Class ModifiedCustomerOrders
Public Property Orders as List(Of ModifiedOrders)
End Class
Within this class you do all kinds of important work, such as combining many different information sources and, eventually, build the Modified Customer Orders.
Now, you have different processes that consume this class, each of which needs a slightly different slice of the ModifiedCustomerOrders items. To enable this, you want to add filtering functionality. How do you go about this? Do you:
Add Filtering calls to the ModifiedCustomerOrders class so that you can say:
MyOrdersClass.RemoveCanceledOrders()
Create a Static / Shared "tooling" class that allows you to call:
OrdersFilters.RemoveCanceledOrders(MyOrders)
Create an extension method to accomplish the same feat as #2 but with less typing:
MyOrders.RemoveCanceledOrders()
Create a "Service" method that handles the getting of Orders as appropriate to the calling function, while using one of the previous approaches "under the hood".
OrdersService.GetOrdersForProcessA()
Others?
I tend to prefer the tooling / extension method approaches as they make testing a little bit simpler. Although I dependency inject all my sourcing data into the ModifiedCustomerOrders, having it as part of the class makes it a little bit more complicated to test. Typically, I choose to use extension methods where I am doing parameterless transformations / filters. As they get more complex, I will move it into a static class instead.
Thoughts on this approach? How would you approach it?
