A recent article described some problems when dealing with Java interfaces, coming from a language that allows duck typing.
The bottom line is thi...
For further actions, you may consider blocking this person and/or reporting abuse
I think, this only might be a problem when you never worked (weren't socialized) on a statically typed language.
I love the metaphor of interfaces being contracts. In implementing an interface you promise to syntactically adhere to the standards required by the contract - if you do semantically useful things is on another sheet of paper.
Unless you aren't implementing an interface, there is good reason for the compiler to suspect something errorneous and scream about it.
But beware of cargocultig interfaces for every class to write. I've seen many codebases where each and every class had its interface which is utterly nonsensical. Here too helps the contracts metaphpor:
Does it make sense to set up a contract if you are the only participant?
No. And before someon comes but with »but in the future« just let me say »Nah! YAGNI«
P.S.: I was socialized on statically typed languages but at present write only python and JS (plain no TS). I am missing nothing so far. But done my homework in statically typed languages helps me avoiding problems in the dynamically typed world.
Yeah, I had a short period where I created interfaces for everything as well. I am glad it‘s over. :) I find them most useful when communicating with external systems (where external could mean sth like microservice as well).
I am really interested what the root for this antipattern is. I have the suspicion that once people misunderstood "program to interfaces not implementations" and took it literally.
When seeing this pattern I tell programmers that every time they do this a little puppy drowns 😬
I'm curious, do you use dependency injection and unit test heavily?
I've gotten into the pattern of creating interfaces for almost all of my classes so that except for the code that needs to construct the object everything can refer to the interface. This makes mocking out that dependency WAY easier with better test performance to boot.
Agree with this. It's not just about communicating with external systems but testing would be a lot easier if dependencies are passed in and we don't create new instances that depend on other classes
Well, for me, a unit isn’t always equal to a class. In other words: I test several classes together. I know people have strong opinions about isolation- for me, it works just fine, and there are several TDD practioners who advocate this style (among them Martin Fowler and Kent Beck, if I‘m not mistaken).
Looks like Amazon skipped the I in SOLID.
The author of the other post wrote DynamoImpl interface in their own project (because the AmazonDynamoDB had interfaces they didn't intend to use) and expected the AmazonDynamoDB to automagically implement DynamoImpl because the signatures match. (This is what Go does, and the author was dissatisfied that Java did not do this.)
If Amazon can have their Java classes implement interfaces that were created after they ship their production artifacts, I'm going to start expecting my prime deliveries a lot faster
My comment wasn't about what the guy in the other article was trying to do. It was about how this interface has dozens methods. It should have either implemented 4-5 other more focused interfaces or, preferably in my opinion, used composition to own those 4-5 interfaces.
If felt with too many of the God classes and I know how they come about. Wether it's a DB or a session is the core of the context of the application so it ends up growing like Katamari.