DEV Community

Cover image for It’s all about the abstractions baby

It’s all about the abstractions baby

Russ Hammett on September 27, 2018

“abstract illustration” by Art by Lønfeldt on Unsplash I’ve been a developer my whole life, professionally about 10 years. In those 10 years, I ...
Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

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.

Collapse
 
dance2die profile image
Sung M. Kim

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).

Collapse
 
kritner profile image
Russ Hammett

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.

Thread Thread
 
dance2die profile image
Sung M. Kim

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 😀

Collapse
 
kritner profile image
Russ Hammett

indeed, good call :)

Collapse
 
birdayz profile image
Johannes Brüderl

the moment when classes with behavior are considered the "least good abstraction"...after all Java is an objected oriented language.

I suggest to read martinfowler.com/bliki/AnemicDomai... .

Collapse
 
qm3ster profile image
Mihail Malo

Are you suggesting the database be hardcoded into the objects, or passed to the constructor?
Storage is not a concern of the business object "MyObject".

Collapse
 
birdayz profile image
Johannes Brüderl

no. it's a statement against shallow data classes without behavior.

Thread Thread
 
qm3ster profile image
Mihail Malo

I don't see why you'd assume MyObject doesn't have rich methods and doesn't protect its invariants.

Thread Thread
 
kritner profile image
Russ Hammett

Sorry maybe I'm missing something the purpose of this and your original comment, can you elaborate?

I didn't think there was really any model type classes in this post; save the undefined MyObject. I'm not saying that classes with behavior are bad, I meant more as if it's implementing an interface, then the consumers can work with the interface, rather than the concrete. This, at least in my opinion, is a better high level design, and makes it easier on consumers/callers to understand a system, rather than getting bogged down in the details of implementation.

Collapse
 
taowen profile image
Tao Wen

To me abstraction is just a means to the end. Code reuse is the goal. To generalize, we have to specialize. The problem is, does the code worth reusing at the first place? If yes, how to reuse it, is not a big problem. Interface/template/multi dispatching, we can always make it work. But I found many times, we are not reusing it on purpose, the cost and saving is not well calculated.

Collapse
 
kritner profile image
Russ Hammett

I haven't done a whole lot of functional unless you count LINQ and maybe SQL, so I'm afraid I wouldn't know the differences. Can you provide an example?

And yeah, over-abstraction is definitely a thing I've seen, and done before. :(

Collapse
 
caseycole589 profile image
Casey Cole

Interfaces and abstract classes are code bloat if you ask me, and they are a waste of time why should I define a method signature then later implement it. Seems like a extra step for no reason to me.

Collapse
 
alanmbarr profile image
Alan Barr

I had a similar feeling in the past especially working with code where someone made an interface for every single object. However, now I see the use cases for library components and making code more flexible for use. Code can sometimes be too strict in what it allows and an interface allows a more generic option to be used that still matches the contract.

Collapse
 
marekmosiewicz profile image
Marek Mosiewicz

I do not see the point. Abstracting factory can be done in singelton. I just do not see too much rationale for all Spring IOC. It can be useful in some scenarios, but in my opinion it is overused.