Why you should avoid `final` in Composer packages

• 1. Limiting Extensibility
• 2. Breaking the Open/Closed Principle
• 3. Hindering Mocking and Testing
• 4. Creating Version Compatibility Issues
• 5. Contradicting the Philosophy of Open Source
• Don't use it!

In the PHP world, the final keyword is used to indicate that a class cannot be extended. It's a feature that ensures encapsulation and design immutability. However, when developing Composer packages, declaring classes as final can create a host of problems for other developers who use your package. This article discusses the reasons why you might want to avoid using the final keyword in your PHP Composer packages.

¶1. Limiting Extensibility

Problem: One of the most significant issues with using the final keyword in Composer packages is that it severely limits the extensibility of the code. Other developers cannot extend your classes to add or modify functionality, which is often a necessary part of integrating packages into diverse projects.

Solution: Allow your classes to be extensible by default, providing users the freedom to tailor the functionality as per their project's requirements.

¶2. Breaking the Open/Closed Principle

Problem: The Open/Closed Principle, one of the SOLID principles, suggests that objects or entities should be open for extension but closed for modification. Declaring a class as final violates this principle as it closes the class for extension.

Solution: Ensure your classes respect the SOLID principles to make your package more robust and flexible, promoting a healthy object-oriented design.

¶3. Hindering Mocking and Testing

Problem: Final classes can create difficulties in testing, as they cannot be mocked. Developers often use mocking frameworks to substitute dependent objects with mock objects, which is impossible with final classes.

Solution: Avoid the final keyword to ensure that your package is test-friendly and maintainable, allowing other developers to write tests easily by mocking and extending your classes.

¶4. Creating Version Compatibility Issues

Problem: If a class is final, developers who need to extend it might end up forking your package and making their adjustments. This fragmentation can lead to compatibility issues and difficulties in maintaining and updating packages.

Solution: Facilitate smooth upgrades and maintenance by keeping your classes non-final, enabling other developers to adapt your package to their needs without altering the original codebase.

¶5. Contradicting the Philosophy of Open Source

Problem: The open-source community thrives on collaboration, sharing, and freedom to modify. Using the final keyword goes against these principles by imposing unnecessary restrictions on how your code is used and extended.

Solution: Embrace the open-source ethos by allowing other developers to freely use, extend, and contribute to your code, enhancing the package's utility and impact.

¶Don't use it!

While the final keyword has its place in PHP for ensuring that certain aspects of your code remain unchanged, its use in Composer packages should be approached cautiously. Striking a balance between protecting your code and allowing flexibility is crucial. As a package maintainer, your aim should be to create a tool that other developers can easily use, extend, and integrate into their projects, fostering a collaborative and innovative development environment, so don't use it.