Możesz dodawać lokalizację do Twoich Tweetów, jak miasto czy konkretne miejsce, z sieci lub innych aplikacji. W każdej chwili możesz usunąć historię lokalizacji swoich Tweetów. Dowiedz się więcej
Fellow devs - if you have a "repository"-like object that only has a single implementation do you do this? If so - why?pic.twitter.com/GRogvFc7qu
In my opinion it's much better to avoid the needless interface and just do this instead. Before anyone mentions tests and mocking - good mocking frameworks can mock classes no problem - you don't need an interface, so what else is it?pic.twitter.com/oS1pA6ddlq
Really nice to see the variety of answers on this thread. I think this is broken down into two use cases:
If you are building a monolith or you know there'll only be a single implementation - do not use an interface
If you are building multi-module you need an interface
The only argument for using an interface for testing I've seen is when using Kotlin native, where you can't mock a final class.
I still haven't seen a good explanation of why mocking a class when you're just writing for the JVM is bad though. Anyone?
I used to do that having inherited this convention from a Spring backend; before I knew better. Now I realize you only need the interface if 1.) you actually have multiple implementations, and 2.) you actually rely on that interface for polymorphism (otherwise it's just coupling)
Exactly!
No! Why add an interface, when you have only one implementation? It doesn't make any sense!
Yes. It's good way to provide abstraction and limit access to specific methods. And also good for code style
Impl is a code smell.
They'll tell you its because of tests, mocks are bad bla bla
Also that project has no fake implementation, no mocks, and no unit tests
Twitter jest przeciążony lub wystąpił chwilowy problem. Spróbuj ponownie lub sprawdź status Twittera, aby uzyskać więcej informacji.
