I’ve gone back and forth on this one, sometimes preferring the simplicity of an available collection and other times wanting all the benefits you get with a strategy pattern.

The compromise I find myself using these days is to have ctors that accept the “most minimal” interface required so the class can to its job (IEnumerable in your example), and then ensure that interface is available on the repository, usually via direct implementation but sometimes using an adapter. I find this doesn’t really add any measurable work, keeps the objects simple, seperated, and testable, and fits extremely well with IoC frameworks.

The first example that takes a sequence of holiday dates would be a stateful class that is used to perform multiple calculations on a set of data which requires the data to be consistent between the calculations, and then the instance would be discarded. The second example that takes a repository would be a stateless class that performs a single calculation on a set of data that is retrieved each time.

So which one you choose would depend on whether you need to perform multiple calculations that share a consistent data set. You might even combine both approaches and have a stateless service which retrieves data from the repository and then constructs a stateful class for the duration of the method call using the list of dates, to perform a number of calculations that need consistent data.