I don't think this is sufficient reason to make it a substantial focus of the core, required curriculum. Again, I do not have a problem with OO course offerings or teaching Java, just putting it front and center as a core, fundamental computer science skill.
I would argue that a large codebase at any company is going to be impenetrable to most fresh computer science graduates. Production software architecture almost always has idiosyncracies that they can't teach you in college, no matter what paradigm is used. So you are always going to have to learn on the job in those situations. You'll pick up the necessary object-oriented principles then.
Trying to teach OO programming in to newbies in a classroom environment usually leads to a lot of incidental complexity and dogma that feels like tedious make-work to students because it is. Meanwhile, with appropriate guidance and peer review from a senior programmer or software architect, and an opportunity to observe and participate a real production build process, an OO design is likely to just "click" in a relatively short amount of time.
One of the key points of OO is that it is a discipline. OO involves explicitly coupling data to logic in encapsulated chunks with a clear separation between the API and implementation details. Trying to teach that particular discipline to students who still can't accomplish anything meaningful with code is, I believe, a waste of their time. OO features like public and private methods seem obvious when you actually have an API to maintain, whereas for a student learning the fundamental techniques and technologies it seems like an arbitrary and largely pointless distinction.
Encouraging and/or enforcing coding discipline is the responsibility of senior members of a given team and is most effective when practiced that way.
I would argue that a large codebase at any company is going to be impenetrable to most fresh computer science graduates. Production software architecture almost always has idiosyncracies that they can't teach you in college, no matter what paradigm is used. So you are always going to have to learn on the job in those situations. You'll pick up the necessary object-oriented principles then.
Trying to teach OO programming in to newbies in a classroom environment usually leads to a lot of incidental complexity and dogma that feels like tedious make-work to students because it is. Meanwhile, with appropriate guidance and peer review from a senior programmer or software architect, and an opportunity to observe and participate a real production build process, an OO design is likely to just "click" in a relatively short amount of time.
One of the key points of OO is that it is a discipline. OO involves explicitly coupling data to logic in encapsulated chunks with a clear separation between the API and implementation details. Trying to teach that particular discipline to students who still can't accomplish anything meaningful with code is, I believe, a waste of their time. OO features like public and private methods seem obvious when you actually have an API to maintain, whereas for a student learning the fundamental techniques and technologies it seems like an arbitrary and largely pointless distinction.
Encouraging and/or enforcing coding discipline is the responsibility of senior members of a given team and is most effective when practiced that way.