You should not be able to inherit from object which was not explicitly designed to be extended (`final` by default). [1](https://matthiasnoback.nl/2018/09/final-classes-by-default-why/), [2](http://whiley.org/2011/12/06/final-should-be-default-for-classes-in-java/) You get much better object encapsulation, you know exactly how you object behaves.
In 3/2022 I have found a similar pattern that breaks object-encapsulation. The feature is **implicit support for object serialization**. Let's say we have an object:
# The storyv
```php
classUserId{
...
...
@@ -41,7 +37,13 @@ There is no public change of behaviour. There is no way outer observer should be
Boom! 🔥 Application hard crashed for every user that has been logged-in on _session deserialization_. That is because implicit serialization made public interface from a private property.
This magic behaviour is [an explosive mine 💥](https://en.wikipedia.org/wiki/Explosive_mine), that you cannot easily spot from the surface or even in code-review. You have to inspect whole code life-cycle including code history.
### Summary
Implicit serialization support is [an explosive mine 💥](https://en.wikipedia.org/wiki/Explosive_mine), that you cannot easily be spot from the surface or even in code-review. You have to inspect whole object life-cycle including code history. Almost impossible to spot.
This is very similar to disabling inheritance support from object which was not explicitly designed to be extended – `final` by default. You can find good reasoning at [1](https://matthiasnoback.nl/2018/09/final-classes-by-default-why/), [2](http://whiley.org/2011/12/06/final-should-be-default-for-classes-in-java/).
**TL;DR:** You get much better object encapsulation, you know exactly how you object behaves.
