Abstraction Can Make Your Code Worse

Summary

The script discusses the tradeoffs between abstraction and coupling in software design. It illustrates how abstraction can reduce code repetition but increase coupling, using examples like transitioning from XML to JSON and creating a 'FileSaver' class. The speaker argues that abstraction is beneficial only when its value outweighs the coupling it introduces, suggesting that sometimes a bit of code repetition is preferable to over-coupling.

Takeaways

• 🔄 **Abstraction vs Coupling**: Abstraction is good for reducing code repetition, but it can also increase coupling.
• 🎮 **Game Object Class**: In game development, a 'Game Object' class can handle position tracking and rendering to reduce duplication.
• 🔗 **Coupling Impact**: Coupling can make systems hard to modify, and its effects are often not felt until changes are needed.
• 📄 **XML to JSON Example**: Moving from XML to JSON for data storage can illustrate the trade-offs between abstraction and coupling.
• 📑 **Separation of Concerns**: Keeping XML and JSON writers as separate classes simplifies the removal of one without affecting the other.
• 🚫 **Avoid Premature Abstraction**: Creating a 'File Saver' class just to avoid assigning file names twice is an example of unnecessary abstraction.
• 🔄 **Interface for Save Method**: Introducing a common interface for saving can increase coupling without providing significant benefits.
• 🔑 **Conditional Logic**: Using an if statement to decide which class to instantiate and save with can be cleaner than forcing an interface.
• 🔍 **Value of Abstraction**: Abstraction is only beneficial when its value outweighs the increased coupling it introduces.
• 🔄 **When to Abstract**: Abstraction is justified when it simplifies adding more options or when the decision of what to save is separated from when to save.

Q & A

What is the purpose of creating the 'Game Object' class in the example?

The 'Game Object' class is created to handle shared functionality, such as tracking position and rendering images, for multiple types of game objects like the main character, enemy characters, and obstacles. This avoids code repetition by allowing subclasses to only specify which image to show.

What is the hidden tradeoff of abstraction according to the script?

The hidden tradeoff of abstraction is coupling. When adding abstraction to remove repetition, you increase coupling, which can make systems harder to modify because different parts of the code become more interdependent.

How does coupling manifest in software design?

Coupling manifests when different parts of a system become interdependent due to abstraction. This makes it difficult to modify or remove parts of the system without affecting other connected components.

Why is coupling considered an 'opposite reaction' to abstraction?

Coupling is considered an 'opposite reaction' to abstraction because for every bit of abstraction added to simplify code, there is an increase in interdependence between parts of the system, making it harder to isolate or change individual components.

What is the downside of adding a 'file saver' class in the second example?

The downside is that both the XML and JSON saving classes would become coupled to the idea of taking a file as input. This creates a limitation that would break the abstraction if a non-file input, like a database or cloud connection, was needed in the future.

Why does the speaker consider the 'file saver' abstraction unnecessary?

The abstraction is considered unnecessary because it saves very little—just the reassignment of a file variable—while introducing coupling that limits future flexibility. The value of this abstraction does not outweigh the potential downsides.

When would creating a common save interface be useful, according to the speaker?

A common save interface would be useful if there were more save options, such as three or more, or if the save process needed to happen at different points, such as saving every 5 minutes. In these cases, the abstraction would simplify the decision-making process around saving.

Why does the speaker argue that some code repetition is acceptable?

The speaker argues that some code repetition is acceptable because it causes less pain when modifying code compared to dealing with over-coupled systems. Repetition is often easier to manage than the unintended complexity of unnecessary abstractions.

What is the advantage of keeping the XML and JSON savers as distinct classes?

Keeping them as distinct classes avoids unnecessary coupling and allows for easier modification or removal of one class without affecting the other. This approach also avoids the limitations imposed by a forced abstraction.

What are the two cases where abstraction becomes worthwhile according to the speaker?

Abstraction becomes worthwhile when (1) there are multiple save options with different parameters, such as database configuration, and (2) there is a need to defer or repeat saving, like in an 'IntervalSaver' class that doesn't need to know which saver it's using.