From f85581cabd1e64d12ac53f9181021343d3381a06 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Kucha=C5=99?= <honza.kuchar@grifart.cz>
Date: Sat, 26 Mar 2022 12:24:46 +0100
Subject: [PATCH] updated README.md
---
README.md | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/README.md b/README.md
index 436616f..28e4af7 100644
--- a/README.md
+++ b/README.md
@@ -2,11 +2,7 @@
...and this package makes it easier for you.
-# The story
-
-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
class UserId {
@@ -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.
# The solution
--
GitLab