I think many academic courses are stuck with old OOP theories from the 90s, while the rest of the industry have learned from its failures long time ago and moved on with more refined OOP practices. Turns out inheritance is one of the worst ways to achieve OOP.
I think a lot of academic oop adds inheritance for the heck of it. Like they’re more interested in creating a tree of life for programming than they are in creating a maintainable understandable program.
That’s the problem, a lot of CS professors never worked in the industry or did anything outside academia so they never learned those lessons…or the last time they did work was back in the 90s lol.
Doesn’t help that most universities don’t seem to offer “software engineering” degrees and so everyone takes “computer science” even if they don’t want to be a computer scientist.
There’s an alternative system where this doesn’t happen: pay university professors less than a living wage.
You do that, and you’ll get professors who work in the industry (they have to) and who love teaching (why else would they teach).
I studied CS in country where public university is free and the state doesn’t fund it appropriately. Which obviously isn’t great, but I got amazing teachers with real world experience.
My son just finished CS in a country with paid and well funded university, and some of the professors were terrible teachers (I watched some of his remote classes during covid) and completely out of touch with the industry. His course on AI was all about Prolog. Not even a mention of neural networks, even while GPT3 was all the rage.
To be clear, I’m not advocating for not paying living wages to professors, I’m just describing the two systems I know and the results.
I don’t know how to get teachers who are up to date with industry and love teaching. You get that when teaching doesn’t pay, but it’d be nice if there was a better way.
OOP can be good. The problem is that in Java 101 courses it’s often taught by heavily using inheritance.
I think inheritance is a bad representation of how stuff is actually built. Let’s say you want to build a house. With the inheritance way of thinking you’re imagining all possible types of buildings you can make. There’s houses, apartment buildings, warehouses, offices, mansions, bunkers etc… Then you imagine how all these buildings are related to each other and start to draw a hierarchy.
In the end you’re not really building a house. You’re just thinking about buildings as an abstract concept. You’re tasked to build a basic house, but you are dreaming about mansions instead. It’s just a curious pastime for computer science professors.
A more direct way of building houses is to think about all the parts it’s composed of and how they interact with each other. These are the objects in an OOP system. Ideally the objects should be as independent as possible.
This concept is called composition over inheritance.
For example, you don’t need to understand all the internals of the toilet to use it. The toilet doesn’t need to be aware of the entire plumbing system for it to work. The plumbing system shouldn’t be designed for one particular toilet either. You should be allowed to install a new improved toilet if you so wish. As long the toilet is compatible with your plumbing system. The fridge should still work even if there’s no toilet in the house.
If you do it right you should also be able to test the toilet individually without connecting it to a real house. Now you suddenly have a unit testable system.
If you ever need polymorphism, you should use interfaces.
The Design Patterns book itself (for many an OO-Bible) spends the first 70 something pages going all about general good OO programming advice, including (repeatedly emphasised) that OO design should favour delegation over inheritance.
Personally for me (who started programming professionally in the 90s), that first part of the book is at least as important the rest of it.
However a lot of people seemed to have learned Patterns as fad (popularized by oh-so-many people who never read a proper book about it and seem to be at the end of a long chinese-whispers chain on what those things are all about), rather than as a set of tools to use if and when it’s appropriate.
(Ditto for Agile, where so many seem to have learned loose practices from it as recipes, without understanding their actual purpose and applicability)
I think many academic courses are stuck with old OOP theories from the 90s, while the rest of the industry have learned from its failures long time ago and moved on with more refined OOP practices. Turns out inheritance is one of the worst ways to achieve OOP.
I think a lot of academic oop adds inheritance for the heck of it. Like they’re more interested in creating a tree of life for programming than they are in creating a maintainable understandable program.
That’s the problem, a lot of CS professors never worked in the industry or did anything outside academia so they never learned those lessons…or the last time they did work was back in the 90s lol.
Doesn’t help that most universities don’t seem to offer “software engineering” degrees and so everyone takes “computer science” even if they don’t want to be a computer scientist.
@einsteinx2 @magic_lobster_party
This is most definitely my experience with a lot of CS professors unfortunately.
There’s an alternative system where this doesn’t happen: pay university professors less than a living wage.
You do that, and you’ll get professors who work in the industry (they have to) and who love teaching (why else would they teach).
I studied CS in country where public university is free and the state doesn’t fund it appropriately. Which obviously isn’t great, but I got amazing teachers with real world experience.
My son just finished CS in a country with paid and well funded university, and some of the professors were terrible teachers (I watched some of his remote classes during covid) and completely out of touch with the industry. His course on AI was all about Prolog. Not even a mention of neural networks, even while GPT3 was all the rage.
Professors love doing academic research. Teaching is a requirement for them, not a passion they pursue (at least not for most of them).
Yeah, that makes it even worse.
To be clear, I’m not advocating for not paying living wages to professors, I’m just describing the two systems I know and the results.
I don’t know how to get teachers who are up to date with industry and love teaching. You get that when teaching doesn’t pay, but it’d be nice if there was a better way.
deleted by creator
OOP can be good. The problem is that in Java 101 courses it’s often taught by heavily using inheritance.
I think inheritance is a bad representation of how stuff is actually built. Let’s say you want to build a house. With the inheritance way of thinking you’re imagining all possible types of buildings you can make. There’s houses, apartment buildings, warehouses, offices, mansions, bunkers etc… Then you imagine how all these buildings are related to each other and start to draw a hierarchy.
In the end you’re not really building a house. You’re just thinking about buildings as an abstract concept. You’re tasked to build a basic house, but you are dreaming about mansions instead. It’s just a curious pastime for computer science professors.
A more direct way of building houses is to think about all the parts it’s composed of and how they interact with each other. These are the objects in an OOP system. Ideally the objects should be as independent as possible.
This concept is called composition over inheritance.
For example, you don’t need to understand all the internals of the toilet to use it. The toilet doesn’t need to be aware of the entire plumbing system for it to work. The plumbing system shouldn’t be designed for one particular toilet either. You should be allowed to install a new improved toilet if you so wish. As long the toilet is compatible with your plumbing system. The fridge should still work even if there’s no toilet in the house.
If you do it right you should also be able to test the toilet individually without connecting it to a real house. Now you suddenly have a unit testable system.
If you ever need polymorphism, you should use interfaces.
This was a nice analogy, thanks for the write-up.
The Design Patterns book itself (for many an OO-Bible) spends the first 70 something pages going all about general good OO programming advice, including (repeatedly emphasised) that OO design should favour delegation over inheritance.
Personally for me (who started programming professionally in the 90s), that first part of the book is at least as important the rest of it.
However a lot of people seemed to have learned Patterns as fad (popularized by oh-so-many people who never read a proper book about it and seem to be at the end of a long chinese-whispers chain on what those things are all about), rather than as a set of tools to use if and when it’s appropriate.
(Ditto for Agile, where so many seem to have learned loose practices from it as recipes, without understanding their actual purpose and applicability)
I’ll stop ranting now ;)