OOP Classes use cases
I recently learnt OOP and now I am confused about the use cases. I understand the concept so well, but not the use cases. I need help
16 Replies
You use classes to separate parts of the code into individual, isolated units.
For example, a search bar needs to keep track of certain things like what is the current and previous query, making the network request and what results came back, or if there was an error, etc. Those things are irrelevant to the rest of the page and so they are isolated in a search class.
Another way of looking at it: if you need to create some sort of entity with both state (internal variables) and logic (functions) you can reach for a class.
I am confused with your explanation. Do you have any resources to further help me understand the use cases better ?
Checkout this page it has plenty of resources for all things JavaScript, including classes: https://javascript.info/class
This is my go to platform for JS. I have read and read. I understand the concept, I just need the use cases. Should OOP replace procedural paradigm or what exactly?
Use classes to group data with functionality that is related. For example, if you are making a game, you would have different entities, like the player, or some enemies. Each entity has data like position, speed, etc. and they also need some functionality for things like walking, jumping, flying, etc.
Use inheritance to create new classes that are similar to other classes but differ in a few ways. This allows you to reuse most of the definition of the other class to write less code. It also enables polymorphism.
Use polymorphism when you have similar actions that need to be performed by different classes. For example, every entity in a game has to be drawn, so you could have a draw() method on all of them. You could then iterate through an array of all drawable entities and call draw() on them despite being different classes. So it doesn't matter if you are drawing a cloud, mountain, zombie, or car. They all have a draw() method.
Use encapsulation when working with other developers on a large project. This point is one that nobody ever explained to me despite the fact that I have studied numerous different OOP languages. Someone on your project is probably not a good programmer and will do things that they shouldn't. Encapsulation guards your code from theirs. That makes it harder for them to misuse your code. It also makes it easier to see who is at fault when code doesn't work, so you won't be blamed for a colleauge's mistakes.
Encapsulation also helps with maintainability of code. It's easier to modify parts of your code when the different parts have some isolation.
I have read and read. I understand the concept,My advice then is that you prove it to yourself that you actually understand the concepts. Reading or watching videos is fine and all but you need to apply those concepts. You can't really say that you understand if you don't know how to use it. If you want to learn the differences go ahead and create the same app following different paradigms. A simple to-do list is the perfect example for this. Actually a video game is another great example of when to use OOP but it's much more involved. You can try however to make a game like pong or similar using these two paradigms and see how they differ. In any case, don't over think it. It's not like this is the holy grail of programming or anything, it will come naturally sa you gain experience.
Some people do pretend that OOP is the holy grail, but others insist that composition is better than inheritance.
@ChooKing @Joao thank you. You both made incredible points. I will keep practicing
Those aren't mutually exclusive concepts, though.
I mean, OOP is not mutually exclusive to composition or inheritance.
It is true that OOP languages can use both, but I was thinking about Go and Rust when I made that comment. Neither language has OOP and a design decision was made early on to use composition instead of inheritance. Rust eventually added something similar to inheritance, but the closest analogue is actually an abstract class with default implementation.
Ah yeah true. I do agree with that though, composition seems to have more flexibility overall.
I'm yet to learn Go and Rust but I'm really curious about Rust in particular because it's making this type of decisions upfront
(I am an OOP hater and style JS functionally)
one case where I used OOP was while making a simple game
there were small projectiles that were coming at you and you basically had to dodge those
in that case instead of individually updating and drawing each projectile u basically make a class , give the common properties and things that r not same for all the projectiles [like position] u keep them as variables and u pass in those as an argument for the
constructorThank you @glutonium
For game development examples I really like this channel: https://www.youtube.com/playlist?list=PLYElE_rzEw_sowQGjRdvwh9eAEt62d_Eu
YouTube
Game Development with Vanilla JavaScript
Building games from scratch with HTML canvas element and plain vanilla JavaScript. Each video is one complete project, focused on particular game development...
I like functional programming in theory but in practice I find it too complex for most practical tasks. At least as far as web development goes.
You can combine both and use whichever suits the particular problem you're trying to solve.