I would say it really depends on the use case. If you are dealing with, say, an E-Bay like second hand shop, then modeling the steering wheel of a car as a separate class is definitly overkill. But if you are writing software for a car manufacturer, then it could be totally fine.
I'm not saying that this overkill never happens. Sadly it happens all too often. However, there are two things to consider here:
1) OOP does neither protect you from, nor does it encourage, over-engineering. You can over-engineer a C program, a Haskell program, you name it.
2) An experienced software engineer will not overdo it with classes - and in particular inheritance - when there is no need for it. The most over-engineered code I've seen is coming from junior developers and students. More experienced programmers tend to be pragmatic about it, and that's a good thing. Thankfully, we have very powerful refactoring tools these days. So even if your initial solution turns out to scale badly (e.g. maybe you used an Enum that you now have to constantly expand) you don't have to stick with it forever, you refactor the problematic part into a more elaborate solution. When people come looking at this code afterwards, they may think that it is over-engineered. But they were not aware of all the cases which caused you to refactor the "simple" code in the first place. It's often easy to call a solution over-engineered by looking at it for 5 minutes. But to give a definitive answer requires a very deep dive into all the use cases.
There is also a very large "gray zone" here where it isn't always clear at all if an abstraction is necessary or not. Some people would say that, for example, the Spring Framework is a total overkill in this regard. As somebody who uses a very large portion of it in my day-to-day work, I would argue that it is perfectly on point.
Oh I see, I didn't get that part - sorry.
I would say it really depends on the use case. If you are dealing with, say, an E-Bay like second hand shop, then modeling the steering wheel of a car as a separate class is definitly overkill. But if you are writing software for a car manufacturer, then it could be totally fine.
I'm not saying that this overkill never happens. Sadly it happens all too often. However, there are two things to consider here:
1) OOP does neither protect you from, nor does it encourage, over-engineering. You can over-engineer a C program, a Haskell program, you name it.
2) An experienced software engineer will not overdo it with classes - and in particular inheritance - when there is no need for it. The most over-engineered code I've seen is coming from junior developers and students. More experienced programmers tend to be pragmatic about it, and that's a good thing. Thankfully, we have very powerful refactoring tools these days. So even if your initial solution turns out to scale badly (e.g. maybe you used an Enum that you now have to constantly expand) you don't have to stick with it forever, you refactor the problematic part into a more elaborate solution. When people come looking at this code afterwards, they may think that it is over-engineered. But they were not aware of all the cases which caused you to refactor the "simple" code in the first place. It's often easy to call a solution over-engineered by looking at it for 5 minutes. But to give a definitive answer requires a very deep dive into all the use cases.
There is also a very large "gray zone" here where it isn't always clear at all if an abstraction is necessary or not. Some people would say that, for example, the Spring Framework is a total overkill in this regard. As somebody who uses a very large portion of it in my day-to-day work, I would argue that it is perfectly on point.
And sometimes your program just needs to do enough things to warrant the number of classes.
Yes, I agree with this. It's important to strike a balance between the extensibility of the program and the mental overhead of numerous classes.