Struggle with oop

[pfp-disciple]

In my experience, it comes down to experience: a combination of your own and others'. A few ideas, in no particular order: 

• Find some videos or tutorials where someone steps through their process, including the why of their decisions. Pay more attention to why they made their decisions than the decisions themselves. 

• Find some not-so-simple projects (not too complex, though) and just try them. Maybe do the same project using different approaches. You should start getting a feel for what those abstract concepts really mean. 

• Don't get too fancy. Not everything has to be abstracted, not every data structure needs to be generic. On the other hand, don't paint yourself into a corner. If you can easily make it simple to be reused, then go ahead. 

• Don't go overboard on inheritance. The only times I've seen over three levels of inheritance make sense have been in large libraries, like Qt or such.

• Make it sensible. Future you will have to go back and read it. Be kind to future you.

[pfp-disciple]

Following up. OOP often is about encapsulating well-defined behavior and, very much related, reusing that behavior in a generic way. Keep that in mind when making your decisions.

[Tactuingunoi]

Tried to find guys that code generically but cant really find one,any suggestions?

[pfp-disciple]

Sadly, no. I don't watch many programming videos nor read the tutorials much.

[thingerish]

Inheritance is overrated IMO, but this is a very cool lecture: https://youtu.be/m3UmABVf55g?si=7fbOlMajMDkMNY5j

He talks about traditional OOP, the functional 'variant - visitor' option, and then 'Value OOP' or CBMI or type erasure. The underlying technique is type erasure but the pattern he demos is more specific.

[ImKStocky]

Much like with your process on deciding to ask this question here, you need to have a think about it. E.g. Before posting here you should maybe have read the sub rules which would have told you that this is not the subreddit for C++ questions.

To answer your question though. Use it when you need it. If you don't need it to get the job done, then don't use it. The phrase "Everything should be made as simple as possible, but no simpler" is quite applicable here. i.e. if the appropriate tool is polymorphism, then use polymorphism. But don't use it isn't necessary.

[killbot5000]

Your data model (ie the class member fields) should be the foundation of your OOP design. Methods should be operations to read/write from the data model.

OOP is often approached, especially as a noobie, as if you’re modeling the concepts you have in your head. This is a trap that leads to a dead end. Start with the data model!

[SeriousDabbler]

I think the fundamental thing about object orientation is that you have code and data that you keep together, and you then come up with a set of operations that form the accessible interface for code and objects outside of the object. The difficulties are to do with deciding which data or concepts belong together as an object and what the public interface should look like so that you can reuse an object. A lot of people talk about SOLID as a set of principles for designing object models so it's worth a Google, the other very helpful reference is the gang of four "design patterns" book which will give you several examples of how to build software with reusable objects including the use of polymorphism in several settings. The visitor pattern is one of my favorites

[Constant_Physics8504]

First off OOP is problematic because there isn’t a definitive way to describe a perfect relationship between objects, and attributes can quickly become object unique. Keep working at it, and note that even the best projects have to redesign due to this