Classes are a means to an end: objects. Objects give us the three core components of OOP:
* encapsulation
* message passing
* late binding
Things like inheritance tend to muddy the waters. If you aren't benefiting from the above 3 things, then you are probably either using objects wrong or you are applying them to a problem for which encapsulated, late-bound message passing isn't a good solution.
As a corollary, state management and OOP are in my opinion orthogonal. You can write and program with immutable objects just as you can with mutable ones.
I do agree with some other comments that OOP in college isn't taught very well. Most people leave their first OOP class not really knowing anything about OOP or why it's useful. My hunch is that OOP is something that should be taught later in a program, not earlier.
IMO, when people talk about OOP they aren't talking about bags of static functions -- that's just a namespace. The interesting objects are those which hold state.
You can have an encapsulated object that is immutable and is not a bag of static functions anymore than any object is a bag of static functions. Look at Scala's interfaces for immutable collections.
* they are encapsulated. You don't know how the data is stored internally.
* There is message passing involved (at the JVM level). The methods are virtual and you don't know exactly which method is being called. There can also be multiple implementations using different data structures.
* Late binding is again as defined by the JVM (interface table method lookup)
In contrast, a static function is no different than a global variable. When you call it, you know exactly (sans JVM linking) which function you are calling.
Right. I'm not saying inheritance should never be used; just that it can be a distraction for learning what OOP is really about. If I were to teach OOP in Java to new students, I might start out just focusing on interfaces.
* encapsulation
* message passing
* late binding
Things like inheritance tend to muddy the waters. If you aren't benefiting from the above 3 things, then you are probably either using objects wrong or you are applying them to a problem for which encapsulated, late-bound message passing isn't a good solution.
As a corollary, state management and OOP are in my opinion orthogonal. You can write and program with immutable objects just as you can with mutable ones.
I do agree with some other comments that OOP in college isn't taught very well. Most people leave their first OOP class not really knowing anything about OOP or why it's useful. My hunch is that OOP is something that should be taught later in a program, not earlier.