Make Your Code Clean With the SOLID Principles
Вставка
- Опубліковано 30 вер 2024
- Writing clean code gets more and more essential the bigger your projects get. The SOLID principles help you do that.
⭐ Get certificates for your future job
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:
pl-coding.com/...
💻 Let me personally review your code and provide individual feedback, so it won't backfire and cost you a fortune in future:
elopage.com/s/...
Regular programming advice on my Instagram page: / _philipplackner_
Checkout my GitHub: github.com/phi...
You like my free content? Here you can buy me a coffee:
www.buymeacoff...
0:00 Introduction
0:51 Find problem with existing code
1:36 S = Single Responsibility Principle
4:05 O = Open Extensions, Closed Modifications
7:09 L = Liskov Substitution
9:43 I = Interface Segregation
11:31 D = Dependency Inversion
Great explanation with a simple to understand example. Amazing videos as always.
Vn
Vvvvvvvvv
Hv
Gvv
Ggvvv
Play the video in 2x speed then you'll be learning SOLID in 10 minutes
But you will understand 2x less as well
@@feepin2058 not necessarily
Lmao
So scary 😂
Writing code is simple but writing simple code is difficult. Good work Philip, it helped me to learn SOLID principles 😅
For Interface segregation principle; I think we shouldn't create a function (that sometimes needed and sometimes not) - printLogs() function in this video - inside the same interface, We should create another interface and declare this function in it and if we need this functionality we can implement this interface and plus other interfaces like FileLogger interface in this video
Agree! But the video still is amazing.
You're right
That's what I thought. Apart from that, video was good.
Yeah! I did note that and agree with your response!
Also agree. If I have an instance of FileLogger and call printLogs(), I'd expect it to print the logs, but it won't. Moving the printLogs() to a separate interface such as LogPrinter, would make more sense.
finally , now i understand why interfaces are so important ,I struggled so much to find reason to use them , Thank you philipp
Same here
Me too... I knew what an interface is in general, but not what it really means in coding (at least I had a bright moment)...
In example for open/closed, you treated the FileLogger class as being completely closed. Your CustomFileLogger was effectively another implementation of a FileLogger interface. It is ok to add new functionality to the FileLogger class, for example adding another function called timestampedError(), as long as you do not change the logError() function it adheres to the open/closed principle. All existing consumers of FileLogger will work exactly as they did before.
For your example of Liskov substitution, the CustomErrorLogger class does not violate Liskov substitution. All instances of FileLogger can be replaced with CustomErrorLogger and will work exactly the same. This is because all calls to logError() will still go to the base FileLogger via inheritance.
Your explanation is great. But, I have a question here, we already have a function named logError() in class FileLogger. So if we add timestampedError() to FileLogger it is not violating single resposibility principle? Kindly help me understand better
@@avigneswaranwaran well ... first of all timestampedError is not a good function name IMO. I follow the pattern of naming a function with a verb prefix. That, plus vonn didn't say what that function does makes it hard to know what vonn intends that function to do. But ... if that function is about logging to a file (logs a timestamped error?) then it does adhere to single responsibility (SR). Then again, vonn's comment is about Open/Closed (O/C) ... why are you asking about SR?
I think a more appropriate example of Liskov substitution principle would be if an overriden function were to do something unexpected and contrary to its implementation in the base class. This can be shown with a base function that changes the state of the class which is overriden by a function that doesn't call the super method. The example provided doesn't break this principle. I liked the other explanations.
Experience is so freaking important!.
6 months ago, i saw this video i didnt understand anything of it.
Now i understand everything! Because without knowing, i used all of this on my job, day to day on Android.
Excelent!
Now going for theory behind design patterns
I believe you got the Liskov Substitution principle wrong.
The principle is that you should not override the behavior of the parent class. Let's say the method of the parent class changes an attribute of the parent class which depends on it. Then when the child class overrides the method and changes the behavior so the attribute is not changed in a way the parent class expects. So this leads to bugs such as when the parent class is used in a code, it expects the behavior of the parent class and if it is substituted by the child implementation, the behavior is changed.
In your example, when you added a new function, that's ok. It doesn't break the parent class. I don't think your example is good. There is a good example with rectangle and square. Just google it :)
Anyways, good job explaining the rest :)
Finally found a Bible for SOLID.❤️🙏
Hi!) I am from Russia and I am learning English to find a job in another country. You have good English I understand almost everything and your videos help me to learn the language))
Hey Philipp , What about MVI pattern?Can we have any tutorial on it. Thanks
Make video on this also please Phillip
For the optional interface function, you could also do = Unit instead of the empty function braces.
Yea sure was just a quick demo here
@@PhilippLackner I think you must do make separate interfaces for every method. So you can use multiple inheritance for every method you need. Because function with empty body standing in the interface not a good case that much.
Thanks for the explanations with easy examples 👌👏
Well done video. Just pay attention to interface segregation. Interface segregation does not mean that clients do not need to implement the entire interface. It means that you should segregate different functions under several interfaces, and then it's up to the client to decide which interfaces to implement. I don't think the example here was demonstrative of interface segregation.
agreed, thanks for the feedback!
Probably onClickListener and OnLongClickListener are examples of it. Those 2 could be in a single interface, but that way you would have forced the class to implement these 2 methods even you want to use either of them.
If possible also make a video on Design Patterns 😅
Please make video on things we do wrong, without even knowing it.
For the open-closed principle, would you then be violating it if you provided a default parameter with the file path name, so that one could change the output location without extending the original class? Not sure if that's what you mean by closed to modification
Thakyou ❤, Please make more free contents like that, i check your "The Essentials of Industry-Level Android App Development course" but its price like my father's monthly salary in my country 🥲
Can you please make video on Important design patterns for Android developers?
Thanks in advance.
The video we didn't ask for, but really needed..
Really amazing video
Very good presentation
... but off the mark on several aspects. I think you did well on S and D.
5:10: "we don't want to affect our whole code with just one change" Cannot disagree more strongly. This is exactly what code should be written to enable. Maybe you misspoke.
Open/closed principal does not strictly imply subclassing. It's a more general concept. It's about factoring the code so that one does not need to modify it as time progresses. Let's say I have a class that supports communications with a device that supports 10 commands. Later, the device adds support for an 11th command. I should not need to modify my existing classes to support that 11th command. The design should be such that I add a class to support the 11th command. This is a common design, right? We often see a class that supports something today and then needs updating when that thing is updated. In fact, such a class does satisfy the single-responsibility principle and it's a common design pattern. But, it's not good since it requires mods as time progresses. The OCP is about writing code one time and then never modifying it! And that is a foreign concept for most developers. We think: I can always change it in the future. But, the goal is to _not_ change it. To get the classes right and then use them like lego blocks. Not to keep re-engineering each lego block.
The liscov breaking example does _not_ break the principle. I can use the subclass just like I use the superclass. Total missed that one. An example would be to override logError and to do something other than log an error.
Interface segregation: it's about clients depending on things it doesn't need; not on subclasses implementing things that don't apply. Miss. Actually, your example for dependency inversion is also a good example for interface segregation.
I think you are covering some useful coding issues, techniques and common problems. But not covering SOLID very well.
Philip God bless you soooooooo much.... i can't thank you enough
Dear Philipp, your explanation about Interface segregation principle is not correct. This principle about that you should have several specific interfaces other then one common interface. Sorry for my criticism.
I liked explanation, Thanks! but Interface segregation principle is not explained properly. It states that, should have kept printLogs method in different interface and then can be implemented in classes wherever required.
I think the explanation for open for extension but closed for modification was a bit confusing.
I hope I'm understanding correctly that by modifying you mean adjusting functionality in pre-existing functions that already work fine.
Repo is dependent on FirebaseAuth object which is wrong, Should be asbtracted and repo should also be abstracted with separating out implementation, and separate class for logging code.
The thing that I liked about the video was not wasting my time to learn this SOLID buillshit. Thanks for summarizing.
really the most informative explanation of SOLID principles. appreciated and thanks a lot man:)
I like how you explain complex things so easy👍nice
The Liskov example is incorrect, because the child class still implements the parent class's method and still serves as an appropriate substitute. In this example the child class fails to implement it's own method, but still successfully fulfills the parent class method.
I do not understand why we need separate authenticator interface for Firebase. We already have an abstraction for repository and we can simply create another implementation with another dependencies. Why to double abstractions there?
This guy does it again!!! Nice explanations.
Glad you like them!
I'm more disturbed with the way you put your brackets, but that's just me :)
You explain like Indians ❤ simple and easy to understand with examples.
Bro, you are my new superhero, much much better than any other fictional superhero
Hey Phillipp we need more videos on clean architecture, if possible please make a playlist on it. I will buy that playlist if it is paid but please make that playlist
Iam developing an app in java ..in that navigation drawer menu items are not getting clicked and not opening sir help as soon as possible
thanks' a lot Philipp, appreciated your efforts
as a programmer that has never seen any Kotlin code, "suspend fun" made me cackle
Perfection!
Thank you!
Its good to see the stuff I usually do put into a list.. notice I said USUALLY hehe
Please Make A Series About Clean Architecture...
This is a most important video in the internet for devs today. It's not easy to explain this topic the way he did. Kudos @Philipp
do you have an example of project with clean arhitecture?
1:36 A module should be responsible to one, and only one, actor. © Uncle Bob
I got goosebumps when he said, "This changes the entire implementation in one line of code. 🦋"
This is programmer porn
What a nerd 💀
The "Inject" part is as hard to understand as usual.....
So if u want to write two lines of code u need to write 50 lines of code good lesson philip 😄
Thanks a lot for that awesome explanation!
it is good, but I need the new version of this video ... if you have a chance to do it.
Thank you it was very simple and easy to understand
Yes, Clear as Mud = Will have to re-watch :)
You got some perfect communication skills
Thanks ❤️
@@PhilippLackner Great video. I do have one doubt regarding auth in Dependency inversion. If we call auth.signInWithEmailAndPassword(), then which would be called among the functions in FirebaseAuthention and CustomApiAuthentication classes?Thanks in advance
@@satyasaineelapala570 you have to pass authenticator object while creating instance of Repository, if you've passed firebaseAuthenticator then it'll use that, and vice versa
@@mrwhoknows Thanks
This guy is really good.... Keep it up bro
Video title should rename it to:
What other Tutorial dont tell you!
Best video about SOLID I've ever seen
is there somewhere that you put this code? thanks!
Didn't realize I already did all of it long time ago.
Very good video. One question regarding the Open Closed Principle: If I would create method for changing the path e.g.: open fun getPath(){...} Does this violate the principle?
Thank you for your content Philipp! It helps so much and I'm glad there are developers who strive to make code as good as possible!
chatgpt:
The Open/Closed Principle (OCP) suggests that you should design your software in a way that allows for new functionality to be added through extension, rather than modification of existing code.
This is particularly important for mature and stable codebases, as modifying existing code can be risky and can introduce new bugs or unexpected behavior. By using inheritance, composition, or polymorphism to add new functionality, you can reduce the risk of introducing new bugs or breaking existing code.
//It does not make sense not to modifing a new code while developing new feature
Drop this and use Kotlin, instead
I would've killed for this video when I first started learning Android and programming; Thank you.
With these vdo, I've understood what SOLID is.. Will you make a playlist making another project following MVVM, SOLID, Jetpack Compose etc... it would be nice
Planned for future yes, but not a specific date yet
@@PhilippLackner would love it if it comes ASAP.. maybe some app related to sports ....
So realy clearest explanation ever and simple practical
Thank you Philipp
Thanks mate!
Someone actually disliked this gem of a video...??! Outrageous...
Thanks man. Really helpful.
You have such a nice way of explaining things brother. Keep making these videos please. Thank you.
need to watch some more time. Thanks a lot
Most of the examples here come down to requirements not principles. For example 13:30. If there is no requirement to support different auth implementations then don't implement it. It adds noise to the code and violates KISS principles.
Even the crazy file logging example from the start shouldn't be changed if there is no need to support different output filenames (of course there is a need and burring the filename inside a function is pretty bad) but that's a requirement not a principle
Been binge watching all your recent videos. Amazing Android content 👏🏽 👌🏽
Thank you so much for clear explanation of SOLID 🙏
Thank you so much dear philipp for record this courses ,
I just wanted say i love you ❤️😘
Vielen vielen Dank lieber Philipp für diese tolle Erklärung. Du hast da wirklich ein Talent solche Dinge sehr einfach für jeden verständlich zu machen.
Liebe Grüße aus Österreich.
Thank you for the explanation I learned something new today
Keep making such videos.👍 It truly helps a lot.😌 Thank you 🙏🙂
Great content. You made it clear for me. Thank you so much.
.
.
.
Thank you so much.
thank you mr philipp
Wao..👍👍👍👍👍
Simplest and best example with clean examples just like your clean codes @Philipp ! Awesome :)
Hi Philipp.... Could you please do a video on How to use Ktor on an Android client...
This is simple AF , nobody showed this important principle with this level of simple and easy examples ! Take a bow @Philipp
👍
Just the thing I needed.
Surely will start using all these principles in my future projects.... Thanks bro...
super simple the best :D
I watched this video after watching your multi module course. So clearly explained .. I clearly understand why you inject abstractions using hilt instead of concrete implementation ..... Thank you so much Philip
grateful :)
Great explanation
Thanks for this video man!, Big fan of your channel
I love you philip 🥰
We need more of this
Can you Mix this with an app tutorial
With mvvm , injection
Nice explanation on very complex and ambiguous topic. 👍👍 Plus i think we can do diff approach for interface segregation instead of giving default implementation.
Kudos Philip. This explanation was easy to grasp
You are the best 👌
Thanks Philipp
please have video on websocket.......................
I have a full course on it. Check pl-coding.com/premium-courses
Well, guess I'll be here for the rest of my college, bout to dive head first into android dev.
Excellent bro !