Object-Oriented Programming is Embarrassing: 4 Short Examples

Summary

The speaker critiques the overuse of object-oriented programming (OOP) concepts, particularly polymorphism, arguing that procedural code is often simpler and more efficient. Using examples from Robert C. Martin's code, they highlight how OOP can introduce unnecessary complexity, especially with abstractions and recursion. The speaker contrasts this with a procedural approach that uses basic data structures like hash maps to achieve the same goal in a more straightforward manner. Ultimately, the video advocates for clarity in coding, suggesting that simpler solutions often lead to better software development.

Takeaways

• 😀 Object-oriented programming (OOP) is criticized as a bad practice, with the speaker claiming it leads to confusion and complexity in code design.
• 😀 The speaker argues against the idea that OOP makes code easier to scale, suggesting that procedural programming is a simpler and more effective alternative.
• 😀 The critique includes how OOP forces developers to conceptualize data as objects with responsibilities, a mistake according to the speaker who believes data should remain inert.
• 😀 One of the core criticisms of OOP is that it leads to a confusing mix of data and actions, where verbs are turned into nouns, complicating the logic of the program.
• 😀 The speaker rejects the circular logic of OOP, where failures in design are blamed on not following OOP principles exactly, even when the theory behind them doesn't work in practice.
• 😀 The video discusses real-world examples of OOP code, such as a class for processing patents, and shows how rewriting the code in a procedural style leads to simpler, clearer solutions.
• 😀 One example involved rewriting a Ruby class that handled multiple responsibilities (downloading, parsing, and updating a database) into smaller, simpler functions, arguing for a procedural approach.
• 😀 The speaker critiques object instantiation in OOP, particularly when classes serve only as containers for methods, and advocates for replacing classes with simple functions or hashes in procedural code.
• 😀 UML (Unified Modeling Language) is critiqued as a poor tool for planning code, with the speaker arguing that textual code and pseudo-code are more effective and flexible at handling complexity.
• 😀 The video presents another example, where branching logic in a game (coin flip) is handled with polymorphism, but the speaker believes a simpler switch statement would suffice, arguing against over-engineering in OOP design.

Q & A

What is the main critique of polymorphism presented in the transcript?

The speaker argues that polymorphism can introduce unnecessary complexity, especially when the branching logic is not parallel across the code. In dynamic languages like Ruby, polymorphism doesn't provide the same guarantees as in static languages, which weakens its utility.

Why does the speaker consider the use of polymorphism 'perverse'?

The speaker believes that polymorphism, when used to replace branching logic, is often a misguided approach. This is because the logic in real-world scenarios is more complex and non-parallel, making the introduction of polymorphism a conceptual overhead without clear benefits.

What does the speaker think about the abstract classes and recursive structures in Uncle Bob's code?

The speaker finds the use of abstract classes and recursive structures in Uncle Bob's code unnecessary and confusing. They question why Uncle Bob used an abstract class instead of an interface and criticize the recursive nature of the data structures, as they complicate the code without providing clarity or functionality.

How does the speaker's solution differ from Uncle Bob's approach to parsing command-line arguments?

The speaker proposes a much simpler procedural solution, using a single `args` class with hash maps for boolean, string, and integer values. Unlike Uncle Bob's solution, which uses multiple classes and abstract structures, the speaker's version avoids unnecessary complexity, focusing on clarity and simplicity.

What is the core task the speaker is solving in their proposed solution?

The speaker's core task is to parse command-line arguments and transform them into a more convenient data structure. This allows easier querying of argument values without the need for complex OOP concepts.

Why does the speaker criticize the use of exceptions for error handling in Uncle Bob's code?

The speaker prefers explicit error handling over relying on exceptions. They argue that exceptions can obscure the logic and that being explicit about potential errors makes the code clearer and easier to understand.

What does the speaker think about object-oriented programming (OOP) in general?

The speaker is skeptical of OOP, particularly when it introduces unnecessary complexity. They argue that OOP often makes code harder to understand and maintain compared to procedural programming, which focuses on simplicity and clarity.

How does the speaker view the argument made by Sandy Mets about object-oriented code?

The speaker is critical of Sandy Mets' argument that OOP allows developers to work without fully understanding the code. They believe that understanding your code and its underlying logic is essential, and that OOP can obscure this understanding rather than promote clarity.

What is the speaker’s perspective on the simplicity of their own solution?

The speaker values the simplicity of their solution, which they believe is more straightforward and easier to understand. Their approach avoids the unnecessary complexity of OOP and focuses directly on the task of parsing and transforming data.

What would the speaker likely change about their own solution to make it more concise?

The speaker suggests making the hash map fields public and accessing them directly, instead of using separate getter methods. This would eliminate some verbosity, as long as error handling is explicitly managed.