From dff1b3926ad862d78468352594017ef3585026ae Mon Sep 17 00:00:00 2001 From: Artem Zakirullin Date: Sun, 22 Sep 2024 16:44:23 +0300 Subject: [PATCH] add new chapter about SRP and shallow modules --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2c10960..555b28a 100644 --- a/README.md +++ b/README.md @@ -152,7 +152,7 @@ A modern implementation of this interface has **hundreds of thousands of lines o If you think we are rooting for bloated God objects with too many responsibilities, you got it wrong. ## Shallow modules and SRP -All too often, engineers end up creating lots of shallow modules, following some vague "a module should be responsible for one, and only one, thing" principle. What is this fuzzy one thing? Instantiating an object is one thing, right? How about saving a user? We introduce things like `MetricsProviderFactoryFactory` and `UserSaver` classes, and all they do is one tiny thing. The names and interfaces of such classes tend to be more mentally taxing than their entire implementations, what kind of abstraction is that? That's all very wrong. +All too often, engineers end up creating lots of shallow modules, following some vague "a module should be responsible for one, and only one, thing" principle. What is this fuzzy one thing? Instantiating an object is one thing, right? How about saving a user? We introduce things like `MetricsProviderFactoryFactory` and `UserSaver` classes, and all they do is one tiny thing. The names and interfaces of such classes tend to be more mentally taxing than their entire implementations, what kind of abstraction is that? Something went wrong. We make changes to our systems to satisfy our stackeholders and users. We are responsible to them.