Can anyone explain to me the continued prominence of "Object-Oriented Design" as part of a fundamental computer science curriculum?
It seems to me that the basics of OOP, the kind of things that most programmers need to know about, can be covered in a single lecture or two as part of a general programming or software engineering class. Java-oriented design patterns and general API design seem more appropriate as an advanced/optional offering for students who are interested.
The linked curriculum has 6 weeks dedicated to Object-Oriented Design in the intermediate part of the "core programming" section. It seems like that much time could be spent on something more fundamental.
This is explained by the teaching staff having been there for 25 years and no effective process in place to force them to change the curriculum.
I’m a CS professor. My colleagues and I have complete control of the program. When you see an outdated program it’s the faculty’s fault in general and the leadership’s fault in particular for not forcing the issue.
Not that my opinion matters, I don't have any advanced degree and no experience building curricula. But if I were going to include OO in a curriculum here's how I'd do it:
1. (Intermediate/Core) I'd cover basic OO in Python. I'd demonstrate basic features like instantiation, introspection, properties and methods before moving on. I would not cover defining new classes before I had covered creating a dispatcher with first-class functions in a hash-map/dictionary. I would not cover defining new classes unless I could cover pros and cons of using OO style versus simple functions that accept rich data structures like lists and hash-maps.
2. (Intermediate/Optional) I'd offer Java, C# and(or) Smalltalk classes at the intermediate level, where the goal would be competence with the chosen language's implementation, tooling, ecosystem and common programming idioms. These classes would involve object-oriented principles, given how important the paradigm is to these languages, but it wouldn't be the sole focus of the class. Edit: Also C++ if possible.
3. (Intermediate/Optional) A design patterns practicum. (Visitor, observer, factory, etc.). Just a programming-heavy class where you solve problems using as many of the common design patterns as possible.
4. (Advanced/Optional) A bottom-up class where we'd cover implementation details of object systems in a low-level systems language like C. Perhaps a semester-long project might be to build a working object system in C. The pedagogical goal would be impart an understanding of the kinds of problems that object-oriented programming was invented to solve by relying on first-hand experience rather than dogmatic instruction and hand-waving about the evils of procedural style.
5. (Advanced/Optional) An Object Oriented Design class that would cover issues in designing large-scale systems using object-oriented programming. It would cover issues relating to inheritance, Object-Relational Mapping, and API design. This is where you'd cover UML and that sort of thing.
I think the main issue with structuring a curriculum like this (assuming the classes are sequential) is that it would take 2.5 years of university to cover it all. That's a A LOT of class time to cover only one programming paradigm when the average CS curriculum is already heavy and lacking slots for electives.
Someone would need to start this Sophomore year and not miss a single course until graduation in order to complete this... While that's fine for core classes like Chemistry which have multiple timeslots offered per semester, having such a brittle pathway for a less-taught topic would cause some grief to plan around.
The basics of chess can be taught in 1 hour but learning to be an expert takes many years. I see OOP in the same way.
Most software today is written in an object oriented language, and for large software systems the quality of your object oriented design has a huge impact on how much it costs to maintain and improve over time. I've been writing software for 20 years and I've never had to implement hash table or search algorithm, but almost every day I'm thinking about my software design using object oriented principles. Personally I think a 6-week course is too short.
There's really no amount of classroom learning that will replace 20 years of experience with object-oriented systems. If you're going to put an inexperienced recent graduate in charge of design for your large software system, you deserve what you get. Ideal coupling of data to code is an arbitrarily complex, context-sensitive problem and each individual company might take a different approach. At best, that is the sort of topic best covered in an advanced class for students specifically interested in problems associated with a large codebase. It's not a good fit for introductory-to-intermediate "learn how to program" instruction.
We could debate the importance of teaching search algorithms, too. But it's a different issue. Search algorithms are a solved problem[1]. Algorithms like that, in addition to being mental exercises, programming practice, and preparation for a career in academic research, are usually used to demonstrate complexity analysis and space/time tradeoffs. The space/time tradeoff is a problem you will face in nearly every environment no matter what language or technology you use.
[1] As far as we know... there might still be research on searching algorithms but for the purposes of the vast majority of software engineers, sorting functions aren't something they'll ever need to implement.
You are more likely to get a job fixing existing software than coding something new. Plenty of existing software is already written in an object oriented style. The majority of Java jobs out there would require a reasonable understanding of the paradigm.
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.
It seems to me that the basics of OOP, the kind of things that most programmers need to know about, can be covered in a single lecture or two as part of a general programming or software engineering class. Java-oriented design patterns and general API design seem more appropriate as an advanced/optional offering for students who are interested.
The linked curriculum has 6 weeks dedicated to Object-Oriented Design in the intermediate part of the "core programming" section. It seems like that much time could be spent on something more fundamental.