“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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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:
or even better (but depends on your needs)
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.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 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 😀
indeed, good call :)
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... .
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".
no. it's a statement against shallow data classes without behavior.
I don't see why you'd assume
MyObjectdoesn't have rich methods and doesn't protect its invariants.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.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.
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. :(
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.
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.
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.