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
Pokaż ten wątek
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 interfacePokaż ten wątek -
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?Pokaż ten wątek
Koniec rozmowy
Nowa rozmowa -
-
-
I think it's when people split layers into presentation, domain and data. The interface would go in a domain module while the implementation would go in a data module. Domain layer cannot depend on data layer, so it interacts with the interface in the business logic.
-
But....why. It just seems like creating class explosion for no reason other than to play tribute to a sense of clean code. Is just having the class without interface in your Data layer and using it directly wrong? What problem does it cause?
- Pokaż odpowiedzi
Nowa rozmowa -
-
-
The CS answer is The Dependency Inversion Principle (the D of SOLID). Relying on abstractions, using a DI framework and whatnot. In reality I think you'd want the interface as a way to force consistency when you inevitably add a second Repository and you want the two to match
-
"when you inevitably add a second Repository and you want the two to match"
I have never had to do that.
And even if you did have to do it, what's the problem of extracting an interface *at that point* rather than before. - Pokaż odpowiedzi
Nowa rozmowa -
-
-
I will only do this in multiplatform projects. There is no mocking there. And if there is only one implementation I would add a private class on that interface. interface Repo { private class Impl(): Repo {} companion object { fun create(): Repo = Impl() } }
-
Can't you mock public class methods in multiplatform projects?
- Pokaż odpowiedzi
Nowa rozmowa -
-
-
Tests written with mocks are often tied with the implementation. The problem becomes worse when you're using asynchronous data sources using RxJava et al requiring you to use extra safe-guards like these:https://github.com/simpledotorg/simple-android/pull/1155 …
-
Is this an argument for not using mocks at all or just for more advanced testing cases?
- Pokaż odpowiedzi
Nowa rozmowa -
Wydaje się, że ładowanie zajmuje dużo czasu.
Twitter jest przeciążony lub wystąpił chwilowy problem. Spróbuj ponownie lub sprawdź status Twittera, aby uzyskać więcej informacji.