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
-
Additionally helps in build time. When the data impl changes the ABI of the interface would not be changed. So the domain can avoid recompilation (compile avoidance) and all modules above it.
Is the build time saving (which I honestly don't think would be a lot if you're keeping your repos lean) really worth the extra indirection complexity?
-
-
May I know what do you mean by lean? We don't follow domain -> data, we call them bridge modules that only has interfaces and serves as contract for other modules/features. Implementation is injected by DI. Additionally I prefer fakes instead of mocks and interfaces help.
-
I understand this requirement for multi-module apps - they wouldn't work otherwise. By lean I mean that each of the repositories (or however they are called) is responsible for one thing so doesn't have a huge implementation.
Koniec rozmowy
Nowa rozmowa -
-
-
Written a little Java code generator to have a feeling about this perf question. It's creating 150+ classes depending on each other. With interfaces, in this very limited scenario, I gain up to 60% of the incremental build time (see gdocs)...https://github.com/glureau/InterfaceImpactOnBuildTime …
-
But even with a gain of 20% on a real app, the indirection while navigating through the code is such a nightmare, class explosion etc. I'd not recommend writing interfaces "by default" if they are not required.
Koniec rozmowy
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.