Object-Oriented Programming is Good*

TL;DR

The video critiques and redefines object-oriented programming concepts.

Transcript

a few years ago I made some videos laying out a case against object-oriented programming and since then I've been meaning to make a positive case for an alternative a prescription for how code should be written rather than how it shouldn't it's taken me a while to work out what I think can be said about how to write code wit... Read More

Key Insights

• The video revisits criticisms of object-oriented programming (OOP), advocating for a modular approach that distinguishes between state and logic modules.
• Logic modules should be devoid of internal state, focusing solely on functions that operate on explicitly passed data, thereby decoupling logic from state management.
• State modules should encapsulate private state and interact through public interfaces, promoting encapsulation without the rigid constraints of OOP.
• The video argues against conflating modules with objects, suggesting that modules can be significantly larger and not limited by size constraints typical in OOP.
• Data types should be defined in the module where they are most used, but they should not belong to any module, similar to how protocols function between clients and servers.
• Polymorphism and inheritance are discussed, with an emphasis on their utility across module boundaries rather than within a single codebase.
• The video critiques OOP for encouraging excessive abstraction, suggesting that good abstractions take time and should not be the default approach in application development.
• The procedural approach is favored for its simplicity and practicality, advocating for modularization based on necessity rather than speculative generalization.

Questions & Answers

Q: How does the video propose structuring code differently from traditional OOP?

The video suggests structuring code using modules rather than the traditional object-oriented approach. It differentiates between state and logic modules, where logic modules operate without internal state and focus on functions with explicitly passed data. This modular approach promotes cleaner, more efficient code by decoupling logic from state management.

Q: What is the role of logic modules in the proposed code structure?

Logic modules are designed to operate without internal state, focusing solely on functions that handle explicitly passed data. They are responsible for generating and mutating data as specified in their documentation, with side effects managed by their callers. This approach decouples logic from state management, promoting cleaner code.

Q: How does the video suggest handling data types in modular programming?

The video proposes that data types should not belong to any specific module, similar to how protocols function between clients and servers. Instead, data types should be defined in the module where they are most used, ensuring flexibility and avoiding rigid constraints typical in object-oriented programming.

Q: What is the video’s stance on encapsulation in programming?

The video supports encapsulation but critiques the over-aggressive form often seen in object-oriented programming. It advocates for state modules to encapsulate private state and interact through public interfaces, promoting clean code boundaries without the rigid constraints of traditional OOP. Encapsulation is seen as a useful concept when applied appropriately.

Q: What are the video’s criticisms of object-oriented programming?

The video criticizes object-oriented programming for conflating modules with objects, encouraging excessive abstraction, and promoting a design with too many small pieces. It argues that good abstractions take time and should not be the default approach in application development, advocating for a more practical procedural approach.

Q: How does the video view the role of polymorphism and inheritance?

Polymorphism and inheritance are seen as useful primarily across module boundaries, particularly between an API and its consumer. The video suggests avoiding interfaces unless external extensibility is needed, as they require speculative generalization. Inheritance is critiqued for its potential to create fragile code due to shared implementation.

Q: What is the procedural alternative to object-oriented programming as discussed in the video?

The procedural alternative emphasizes simplicity and practicality, advocating for modularization based on necessity rather than speculative generalization. It encourages introducing abstractions only when they are likely to be useful, contrasting with object-oriented programming's tendency to create numerous small, independent pieces in anticipation of future needs.

Q: Why does the video argue against excessive abstraction in programming?

The video argues that excessive abstraction, a common trait in object-oriented programming, can lead to complex and unwieldy code. Good abstractions require significant thought and time to develop and should emerge slowly over iterations. Instead of defaulting to abstraction, the video advocates for a more straightforward procedural approach that prioritizes practical solutions.

Summary & Key Takeaways

• The video revisits previous criticisms of object-oriented programming, proposing a modular approach that separates state and logic modules. Logic modules should operate independently of internal state, focusing on explicitly passed data. This separation promotes a cleaner, more efficient code structure.

• State modules should encapsulate private state, interacting only through public interfaces. This encapsulation is crucial for maintaining clean code boundaries without the constraints typical in traditional object-oriented programming. The video also argues against conflating modules with objects, suggesting a more flexible approach.

• Polymorphism and inheritance are explored, with an emphasis on their utility across module boundaries. The video critiques object-oriented programming for encouraging excessive abstraction, advocating for a procedural approach that introduces abstractions only when necessary, promoting simplicity and practicality.