21:54
Why I use final
PHP Annotated
Overview
This video explores the use of the `final` keyword in PHP, arguing that while controversial, it encourages better code design. The speaker, an open-source maintainer, explains that `final` classes cannot be extended, which simplifies maintenance by reducing unpredictable behavior from third-party extensions. Furthermore, `final` can force developers to adopt better architectural patterns like composition over inheritance and the Single Responsibility Principle, leading to more robust, testable, and maintainable code. The key is not `final` itself, but how it prompts developers to think more deeply about their design choices from the outset.
How was this?
Save this permanently with flashcards, quizzes, and AI chat
Chapters
- The `final` keyword in PHP prevents a class from being extended.
- There's a notable division among developers regarding the use of `final`.
- While not strictly necessary for good code (e.g., Laravel), `final` offers perceived benefits.
- The speaker's preference for `final` stems from its influence on code structure and maintainability.
Understanding the differing perspectives on `final` is crucial for engaging in software design discussions and making informed decisions about code structure.
- Using `final` simplifies maintenance by limiting how users can alter a package's behavior.
- It reduces the likelihood of unexpected bugs caused by third-party extensions overriding methods.
- By preventing extensions, `final` eliminates a broad category of potential issues.
- This leads to fewer support requests and bug reports for the maintainer.
For open-source maintainers, `final` can significantly reduce the burden of managing unpredictable user modifications, leading to a more stable codebase.
A package maintainer doesn't have to worry about users overriding methods in their library, which could introduce bugs that the maintainer then has to fix.
- The speaker argues `final` doesn't inherently make code better, but it forces developers to make better design decisions.
- Without `final`, developers might create overly complex classes with many extension points, leading to messy code.
- The frustration of being blocked by `final` often reveals underlying design flaws, such as a single class handling too many responsibilities.
- Refactoring to address `final` limitations often leads to adopting principles like Single Responsibility and composition over inheritance.
Viewing `final` as a design constraint can push developers towards more modular, focused, and maintainable code structures.
Instead of extending a large `BlogPostAPI` class to change authentication, refactoring involves creating separate `Authenticator`, `Dispatcher`, and `Mapper` classes, which are then composed into an `APIGateway`.
- The refactoring prompted by `final` often leads to using interfaces instead of concrete classes for dependencies.
- This promotes composition over inheritance, building functionality by combining smaller, focused components.
- Using interfaces makes mocking for testing significantly easier.
- Small, well-defined classes/interfaces are easier to test in isolation than large, monolithic ones.
Embracing composition and interfaces, often encouraged by `final`, results in more flexible, testable, and maintainable software architectures.
An `APIGateway` depends on an `Authenticator` interface, allowing different authentication strategies (e.g., OAuth, API Key) to be easily swapped in or mocked for tests.
- A common criticism is that `final` hinders flexibility and forces developers to babysit users.
- However, poorly designed packages that simply add `final` without proper architecture (like interfaces) will indeed cause problems.
- The real issue isn't `final` itself, but the underlying design that `final` exposes.
- When `final` is considered from the project's inception, these issues are largely avoided.
Recognizing that `final`'s effectiveness depends on thoughtful design, rather than just keyword placement, is key to leveraging its benefits.
A framework designed with `final` in mind from the start (like Tempest) enforces that non-interface classes must be `final`, preventing the problems that arise from haphazardly applying the keyword.
- The core argument is that `final` encourages better code design and structure.
- It forces developers to think critically about how classes interact and their responsibilities.
- Implementing `final` effectively requires a conscious design choice, not just adding the keyword.
- When used correctly within a well-thought-out architecture, `final` leads to more robust and maintainable code.
Ultimately, `final` can be a valuable tool for improving code quality, provided it's integrated thoughtfully into the software's architecture.
The Tempest framework's architecture rule, enforcing `final` for most non-interface classes, demonstrates a system built with `final` as a core design principle.
Key takeaways
- The `final` keyword in PHP prevents class inheritance, which can simplify code maintenance by reducing unpredictable extensions.
- While not essential for good code, `final` can act as a catalyst, forcing developers to consider design patterns like composition over inheritance.
- Frustration with `final` often signals underlying design issues, such as overly large classes or lack of interfaces.
- Refactoring to accommodate `final` can lead to smaller, more focused classes and the use of interfaces, improving testability.
- Effective use of `final` requires architectural consideration from the project's start, not just adding the keyword to existing classes.
- The benefits of `final` stem from the improved design it encourages, rather than the keyword itself.
- Open-source maintainers can benefit from `final` by limiting the scope of potential bugs introduced by third-party code modifications.
Key terms
final keywordclass inheritanceopen-source maintainercode maintenancecomposition over inheritanceSingle Responsibility Principleinterfacesdependency injectionmockingarchitecture testing
Test your understanding
- How does the `final` keyword impact the ability of other developers to extend a class?
- Why might an open-source maintainer find the `final` keyword beneficial for their work?
- What underlying design principles does the speaker suggest `final` encourages developers to adopt?
- How can the frustration caused by encountering a `final` class lead to improved software design?
- What is the relationship between `final` classes, interfaces, and the practice of composition over inheritance?