If You Think THIS Is a Best Practice, You're WRONG in 99% of the Cases...
Вставка
- Опубліковано 9 бер 2024
- This video will show you new possibilities and why you have been wrong 99% of the time!
Get my super extensive Android testing course here:
pl-coding.com/testing
💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:
pl-coding.com/drop-table-ment...
⭐ Courses with real-life practices
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:
pl-coding.com/premium-courses/
Get my FREE PDF about 20 things you should never do in Jetpack Compose:
pl-coding.com/jetpack-compose...
Regular programming advice on my Instagram page: / _philipplackner_
Join my Discord server:
/ discord - Наука та технологія
You will not misuse use-cases, if you're not using them😂
The mistake is the assumption that every mapping operation can be performed as a simple 1-to-1 conversion. Very often it's not the case. Sometimes you need to merge data from 3 objects to create one or a pair of two. Layer to layer mapping is not bad. The bad thing is the 1-to-1 generic mapper interface. It's too inflexible. Just use concrete mappers not implementing mapper interfaces.
Using the Mapper interface can be very good for the 1:1 layer mapping classes, but I agree that in some cases it just isn't that simple. I've just had to implement a horrible mapper because I needed to merge data from 3 different objects in to one.
This is also the limit of using this approach, it is inflexible
If mapper accepts more than 1 parameter - that's not mapper, that's factory
@@alexandrpershin we are not talking about parameters here but use of generic type, mapper usually doesn’t need any parameter to begin with and if it does then that is probably a parser not mapper.
Thanks a lot for the explanation by showing an actual app and walking through step by step about the complexity. A lot of other content providers would just go through the Google documentation and explain the redundant topic. These videos helps to relate with the actual usecases developers face daily especially with large scale applications. Many a times new joiners would just get lost in the abstractions and navigating through so many classes. Please continue sharing such awesome content ❤
Glad it was helpful!
Similar question I had when I started working on a big android project I wasn’t able to understand, now it’s crystal clear thanks philipp for such an informative video keep doing the great work you inspire lots of engineers ❤
it is probably a good idea to have a usecase (especially in large projects)
but it's important to understand why you want them.
if you only use it to transfer data from repo to viewmodel, then it's not really useful,
but if you're using it to create a buffer between the viewmodel and the repo, and save data to local repo, then it's useful.
also, it's probably a better practice to use high order functions for the mapper, instead of an interface.
Great video Philipp!
I agree with you that creating abstractions that will have no more than one implementation can be overwhelming when we try to navigate from one end to another.
As a counterpoint, the main advantage that I see in my projects in implementing structures this way is the possibility of isolating contracts from concrete implementations in different modules, resulting in a reduction in the project build time when the other modules in my application reference only the modules with these contracts and not the robust modules that contain all the concrete implementations. There's a very interesting talk at Droidcon called Android at Scale @Square that exemplifies this approach.
Absolutely and if you stick to such a multi-module architecture, these abstractions have a value as you described :)
I should've added here that isolating layers is also a purpose of them, yet abstractions within one layer are rarely useful (like for use cases or mappers). My feeling is more that people blindly abstract everything they find because it's a "best practice". This video was meant as a push to those people to not only start learning what should be done, but also why and when something should be done :)
I wanted to comment exactly this but you beat me to it :)
My most common situation is to have the domain in a kotlin module and abstracting repositories so they can be implemented in the various data modules
Exactly what I've been arguing in all the architecture talks, nice!
We all need to go through the process of doing too little such abstractions, then we do too much, and then we go back to doing just as much as we actually need to. This video is great in describing this. I am sure people who disagree will be able to come back to this in 2 years and find themselves agreeing instead. Great work on this one Philipp.
Thanks!
Great video ❤
i agree about over usage of abstraction, i'd only have usecase for common API exposed to other modules in project with mapping logic
Great detailed explanation as always!. Instead of having test doubles can't we use mock libraries for testing purpose? Such as Mockito and Mockk?. Is there any advantage of using test double over these libraries?
We use test doubles when we want to control the working implementation of that class we're faking. Mocks are more for quick behavioural control where we dont really care much about implementations or large computations during tests
Hi Philipp, clear explanation as always, but I wish you would bring some examples here, as if you're using a complete Clean Architecture, every layer of any feature has strong directional dependency towards the center, towards the domain logic layer.
I understand this could seem like an unnecessary complication, but without it no one would be stopped when trying to inject a retrofit interface to a viewmodel or even worse a view.
I don't want to check your course to understand what you meant in the video, or if you're thinking of every scenario or most scenarios, we can all agree it shouldn't be necessary right?
Other than that, keep the good job as always!
The isolation of domain enforces what you mentioned, but if your abstractions lie in the same layer as their implementations (e.g. for use case or mappers), it has nothing to do anymore with making use of the "dependency towards center" paradigm.
For abstractions that lie in a different layer as their implementation (e.g. a repository), that point is valid which is why I also didn't talk about avoiding repository abstractions (at least when using a domain layer in the app)
make videos on the alarm manager in android 14.in android can not direct set exact alarm.if i set then the wake up after some second
Use the use case when your function needs more than one repositories and these needs to return a result. In the video, It just delegate the calls to the repository which doesn't make sense. Also, Do not put all the UI logic to the use case... Let the UI do that. For business logic, let the data layer do it too. So your use case is like a bridge to many repositories.
Thank you for the good video today too
You can also inject implementations directly which will solve the ctrl+ click navigation problem and use abstraction as architecture style enforcers.
And you successfully violate one of the most fundamental architectural principles to depend on abstractions and not concretions 😅
Which one actually make sense , LoginViewModel depends on SuspendUseCase or LoginViewModel depends on LoginUseCase :-)
Hello Philipp, I am a senior manager of JetBrains and I was in the role of developing Kotlin language, so will kotlin kmm surpass Flutter in next 2 years ?
sure
What is your AS theme? It looks great!
it looks like xcode default theme
What font does he use?
btw i'm using reflection, its that wrong?
Thank you! I think you missed an other abstraction benefit: it allows to keep the real implementation as an internal class. If you modularise an app, it could be very helpful:
Let's say you have a UseCase that needs a mapper. This mapper is used only by UseCases. You want to keep this mapper internal in the "domain" gradle module. If you expose your real UseCase implementation to your UI module, and if the mapper is given to the UseCase constructor via DI, you will need to expose your mapper too. If you use an abstraction in front of your UseCase, you can expose the abstraction only, and keep the UseCase implementation and the mapper as internal.
This way, you can avoid that the UI layer knows the data layer too.
WDYT ?
This video makes sense. I would imagine on a project, everyone has their own philosophy on when to use Abstraction. I don' think there is a clear answer.
2:52 This is why I *used to* despise Java when trying to understand someone else's Minecraft mod or plugin, more often than not they'd have functions sending variables to a slew of other classes to an unnecessary degree, it was like three dimensional spaghetti-code, the function was abstracted across multiple classes and was more passing variables than logic making it a nightmare to debug because it could've been done with potentially a few extra lines of code but kept said code inside 1 class and therefore keeping things simple.
Probably you forgot to say that we should always have interfaces (abstractions) for repositories (if we write multimodule project) because for example AuthRepository (interface) is usually placed in DOMAIN layer and AuthRepositoryImpl is placed in DATA layer, which are in the sepatere modules.
So, having only AuthRepositoryImpl we can not follow clean architecrute (correct if I am wrong)
If you have a domain layer yes, but this is not the only valid type of architecture
Nice video! In your experience, abstracting use cases might not be the most effective for testing. Since they often encapsulate business logic, testing with real implementations can be more valuable. This means using mocks or fakes for the repository layer when testing view models in the presentation layer?
Here's why: Use cases typically depend on repositories. If we don't mock the use case itself, we'd need to mock the repository to avoid hitting the real server during tests.
My question is: Considering this approach, would you prefer mocking the repository directly in the presentation layer tests?
totally agreed
The best video i watched this week 🤠
Nice video
I used to think like that. Then the reality of actual production enterprise applications used by hundreds of thousands of users that were using ever changing backend services but had backend code tightly coupled with UI code hit me hard. There is a good reason for these abstractions and personally I would use them even for toy/hobby projects.
How does abstracting a use case or mapper help with easily swapping out libraries?
@@PhilippLackner Suppose you have backend service A which you want to replace with backend service B (or A v2). A use case interface would have different implementations for each case, i.e. each implementation would use a different repository, and it would map the potentially different models of A and B to the same model consumed by the UI.
Good video explaining a great topic. But the presentation is very fast and difficult to understand without independent, in-depth analysis. It would be much better to show the structure of the example on the diagram. What should be done and how not to do it.
Philipp! I'd love to be a member of a team that you lead.
Unfortunately life does not work that way. You end up with a team lead that was here for years and is a team leader "just because".
Its true that we should find the balance between absctraction and simplicity, But in your example, I tend to disagree, since we see a repository, useCase, well mappers im not sure but it does make sense after all. Even if the only thing you need right now in the use-case of login is the login-execution method to implement, since all the functions in the applications are working that way its not that complex for the developer.
If you are working with a massive application, with dozens of use cases, it making the developer to know exactly what to expect to find when he is looking for the implementation of some function in the UI layer..
Abstraction, thats usually is the problem 😅 just use a concrete map and be happy
❤I am sakthi from India Tamilnadu,
I am biggest fan of you Bro, 😊I decided to learn native Android development jetpack Campos🌵 and teach my tamil people using UA-cam channel like you bro,🥴 but I not have much more money to spend for any courses including your courses now I am learning using free online 💸resources including your UA-cam video's I completed your kotlin playlist it is very useful for me, 🤔now I have a one big doubt, is flutter killing native Android development?🎦 Please make video for this doubt bro more new learning students have this doubt bro.
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Also having an interface for the purpose of using fakes in tests is also not needed since you can just use a mocking library to replace the real implementation with a mock. I feel like people use abstraction just for the sake of it but it's almost never needed.
Uhh, I've rarely seen people use mocks correctly. Fakes have always been way more reliable in my experience, unless you need to test legacy code or code you don't own
You can get the same fake implementation with a mock where you do "when this do that", right?. Unless this is what you mean by not using mocks correctly. A good idea for a next video maybe? @@PhilippLackner
And how can you verify a call was made to a fake, with specific parameters and specific times? You can't. Only mocks can do that.
@@gekylafasum you can verify if a call was made to a fake
How do you mock a final (by default) concrete kotlin class if not by an interface?
Finally someone to share my point of view. Unfortunately this realisation comes after 10+ years of experience, and for some it doesn't come at all. Sorry for you btw, because you will most likely receive a lot of hate for this video from the inexperienced developers who have read single clean architecture article snd think themselves of the next Jake Wharton.
this is my pet peeve
Base
The purpose of using interface when implementing mapper is for me to have a blueprint that I can follow which also act like a standard pattern for others so that the order of functions, its name and returned data type will always look the same in every implementation. The only problem I see here is the use of interface for use case since usually it doesn't even do anything other than calling the repository. I also do not like having mapper to Entity or from DTO inside my domain classes as I want it to be plain Kotlin as always. Android devs love complexity to the bone for real, but yeah too much abstraction can hurt everyone I think 1-2 level of abstraction is enough and above that makes everything complicated.
But for every blueprint you have, there's no value if people don't use it. And in order to use it, you need to communicate it to the team. And if you have to communicate something in either way, you can also just communicate that you're using simple extension functions for mapping. I get your point, however I still think the gained value of that blueprint is higher than the lost value due to the extra complexity.
Same argument would go for a use case, these also have a blueprint - they take a set of input params and generate an output. So why not there? You mentioned it doesn't do anything other than calling the repository, but doesn't the same count for mappers? All they do is map something to and from and object
@@PhilippLackner Good point. I still think for a project that handles very huge response data and many properties, using the above approach of implementing mapper is more readable and cleaner as there is a better separation of concern but that is not the case for use case where the usual recommended number of parameters is 7. Above that you will get lint warning if you use one. What I mean is compare to mapper that can be really huge and bit complex, use cases on the other hand are usually simple since most of business logic can be put in the domain itself. Communication is a must and setting standard pattern in a project I think will lead to a better quality and consistent code style so that should be the least problem I would bother. As for mapper being the constructor's parameter, I use the concrete implementation there to improve readability and lessen the complexity effect of abstraction even if it means of violating the D in SOLID principle. I will consider doing the mapping in the models too in the future since there are now plain Kotlin solution for caching and networking which makes it feel more comfortable to put it in domain for mapping.
@@bitwisedevs469 mapping in domain doesn't work as the mapper has a dependency on data
@@PhilippLackner thanks so it should be entity that holds the mapper function is that what you mean?
Phillip I love your channel but I thought it is supposed to be an educational channel.
Meaning I want to know what the video is about from the title instead of some clickbait that leaves me clueless...
Thanks for the feedback :)
If you find these videos not educational, it's of course fully up to you to not click on them. Furthermore, clickbait means that the title and thumbnail suggests something you won't find in the video. That's not the case here, as watching the video proves the title and thumbnail.
If you want pure "educational videos" (as per your definition), check my premium courses. They're independent of an algorithm :)
@@PhilippLacknerI still believe this is clickbait - just a different type :) All I am saying is that if in 2-3 months time I'll want to revise this again I will be forced to search for the video manually because typing "lackner mappers" will not yield any result most likely.
For SEO, it actually doesn't matter too much, UA-cam indexes every word that was said in the video :)
what?! you're saying that clean architecture with use cases are boilerplate and not useful in 99% of projects? You're right ;)
I laughed my ass hard on this video 😅😅
I hope I'll not encounter something like this
Something definitely triggered Philip to make this video 😂
You a wrong, abstract things look weird when it is small app, but in big projects abstractions help to reuse code a lot and don't rewrite same code million times. Another case, when you have abstraction over library for example and you use that in 100 files, then when you want to migrate to other library in that field you don't need to touch 100 files, just write 1 file with new implementation. In general in big progrects big amount of abstractions helps a lot, but you need know how to work with that properly.
Did you even listen to what I said in the video?
@@PhilippLackner 🤣
😜@@PhilippLackner
iOS apps aren't over-engineered like Android apps. I don't know why that is? Whether it;s a bravado thing.
It is because a lot of bad projects, that we had a few years ago..
I laughed my ass hard on this video 😅😅
I hope I'll not encounter something like this
I laughed my ass hard on this video 😅😅
I hope I'll not encounter something like this