re: It’s all about the abstractions baby VIEW POST

VIEW FULL DISCUSSION

I always like posts about abstraction which is crucial in the developer's daily routine.

I've one enhancement to your interface. I hope you won't take this personally. Please treat this as an improvement.

In your example, you use List type which is a concrete type. I'd suggest you take more abstract type like in examples below:

public interface IMyObjectRetriever
{
   IList<MyObject> GetMyObjects(MyObjectCriteria criteria);
}

or even better (but depends on your needs)

public interface IMyObjectRetriever
{
   IEnumerable<MyObject> GetMyObjects(MyObjectCriteria criteria);
}

That makes you interface more abstract.

Cheers.

And if you want to abstract even further, instead of an concrete MyObjectCriteria & MyObject, you can extract an interface, thus making it more testable/abstract.

public interface IMyObjectRetriever
{
   IEnumerable<IMyObject> GetMyObjects(IMyObjectCriteria criteria);
}

I think it's overengineering but wanted to point out that abstraction can go far to the point it's unmanageable (but could be easier to mock & test).

heh, indeed! I've gone down this path a few times, sometimes for actual reasons even! It gets real weird when you're working with everything as interfaces and then start pulling in some visitor pattern action to avoid casts of your interfaces into their concretes. Every time I try to remember how to use or read the visitor pattern, my brain explodes just a tad.

I try to remember how to use or read the visitor pattern

I believe the percentage of people who can implement the Visitor Pattern without a cheat sheet should be about the same as number of devs show can do CSS gradient without looking up 😀

code of conduct - report abuse