Lecture: Object-Oriented Programming Critique

Introduction

• The lecture critiques Object-Oriented Programming (OOP).
• Emphasis on why OOP is problematic and why procedural programming might be preferable.

Key Arguments Against OOP

• OOP is seen as a disaster for the software industry.
• Data should be treated as data, not "things with responsibilities".
• Confuses the separation between actions and data.
• Encourages unnecessary complexity and philosophical debates about code entities.

Lecture Goals

• Provide concrete examples to demonstrate the inefficiency of OOP.
• Compare with simple procedural style for clarity.
• Discuss the Single Responsibility Principle and its nebulous definition.

Examples Highlighted

Example 1: Patent Processing in Ruby

• Original code: Class with methods run, download_file, parse, and update_patents.
• Critique: Class is unnecessary and confusing; it acts as a namespace.
• Suggested solution: Use procedural code without classes.

Example 2: Coin Flipping Game in Java

• Original code: Used UML and multiple classes (Player, Coin, CoinGame) for a simple task.
• Critique: Over-complicated for a simple function.
• Suggested solution: Procedural code with minimal classes.

Example 3: Branching Logic and Polymorphism

• Original code: Complex branching logic replaced with polymorphism.
• Critique: Polymorphism is unnecessary; simple branching suffices.
• Suggested solution: Use a switch or if-else logic instead of polymorphic classes.

Example 4: Command Line Argument Parsing

• Original code: Uses multiple classes and abstract classes for argument parsing.
• Critique: Overly complex with recursive structures.
• Suggested solution: Simplified procedural approach with straightforward data structures.

Overall Critique of OOP

• OOP leads to unnecessary complexity.
• Procedural code is often more straightforward and easier to comprehend.
• The supposed benefits of OOP, like modularity and easier code changes, are questioned.

Final Thoughts

• Encourage understanding of code and tools rather than abstracting complexity away.
• Question the idea that complex object systems allow for code changes without understanding the whole system.