اصل تکمسئولیتی رو اشتباه فهمیدیم
خلاصهٔ کاملتر
نویسنده اول یه نکتهی کلی میگه: همهی الگوها و اصول مثل SOLID و Clean Architecture و DDD برای یه هدف ساخته شدن، اینکه کار رو ساده کنن تا با تلاش ذهنی کمتری بتونیم مسائل پیچیده رو حل کنیم. به گفتهی نویسنده هر الگو از دل یه مشکل به دنیا اومده، پس اگه اون مشکل رو تجربه نکردی، اون الگو رو هم لازم نداری. کار مهندس نرمافزار اینه که نه over-engineering کنه نه under-engineering، اول مشکل رو بشناسه بعد الگو رو روش سوار کنه.
بعد میره سراغ اصل Single Responsibility که میگه شاید کمفهمیدهشدهترین اصل SOLIDـه. خود Uncle Bob که سازندهی این اصله هم گفته اسمش گمراهکنندهست و باعث شده برنامهنویسها فکر کنن هر ماژول باید فقط یه کار بکنه. نویسنده میگه این یه جور «بازی تلفن» بین برنامهنویسهاست، یکی به اون یکی میگه و هیچکس واقعاً عمیق دنبال فهمیدنش نمیره.
برای روشن کردن قضیه از مثال پیک پیتزا استفاده میکنه. مسئولیت پیک یه چیزه: رسوندن پیتزا. ولی رفتارهایی که بابتشون پاسخگوئه خیلیان، گذاشتن درست پیتزا تو کیف، روشن کردن موتور، رانندگی امن، زنگ زدن در خونه. اینها چند تا مسئولیت نیستن، رفتارهای زیرمجموعهی یه مسئولیتان. نکتهی کلیدی همینه: مسئولیت با رفتار فرق داره.
نویسنده میگه اگه این تفاوت رو نفهمیم، کد به شکل افتضاحی تیکهتیکه میشه، کلاسهایی مثل MotorcycleStarter و HeartbeatsFactory که هر کدوم یه متد پنج خطی دارن. نتیجهش اینه که برای فهمیدن یه قانون کسبوکار باید بیست تا فایل رو باز کنی و ذهنی به هم وصلشون کنی، انگار داری پازل غولپیکر میچینی. این دقیقاً برعکس هدف اصلی یعنی کم کردن بار ذهنیـه.
به نقل از Clean Architecture، یه ماژول مجموعهای از توابع و ساختار دادههاست که با هم منسجم (cohesive) هستن، و انسجام همون نیروییـه که کد رو به یه actor واحد گره میزنه. پس کاملاً درسته که یه کلاس PizzaDeliveryPerson با متد deliver_pizza داشته باشیم که pizza و customer و motorcycle رو میگیره و همهی اون رفتارها توش باشه، چون جای دیگهای دنبال نحوهی تحویل پیتزا نمیگردیم.
نویسنده میگه مشکل اصلی که SRP حل میکنه انسجام پایینـه. اگه یه کلاس به اسم CalculateAccounting رفتار «گرم کردن فر آشپزخونه» رو داشته باشه، SRP نقض شده، چون هیچ برنامهنویسی برای تغییر دمای فر سراغ کلاس حسابداری نمیره. چنین کلاسی دو تا دلیل برای تغییر داره و طراحیش شکننده میشه.
فرمول جادویی نویسنده برای رعایت SRP اینه: از اسمهای کلی مثل Service و Manager فرار کن، قبل کد زدن وقت بذار قانون کسبوکارت رو به ساختارهایی با اسمهای منسجم ترجمه کنی، و از خودت بپرس آیا این کلاس با مسئولیت X باید پاسخگوی رفتار Z باشه یا نه. نرمافزار خوب از نظر نویسنده اونیه که حتی یه آدم غیرفنی هم بتونه فایلهاش رو باز کنه و سرسری بفهمه چی داره میگذره.
نکات کلیدی:
- مسئولیت با خود رفتار فرق داره، مسئولیت یعنی پاسخگو بودن نسبت به یه مجموعه از رفتارها
- SRP دربارهی مسئولیت و رفتار و نحوهی منسجم توصیف کردنشونه، نه «فقط یه کار کردن»
- انسجام بیشتر به اسمهایی که به کلاس و تابع و متغیر میدیم برمیگرده
- هر الگو فقط وقتی ارزش داره که بار ذهنی رو کم کنه، وگرنه نباید استفادهش کرد
- شکستن بیش از حد کد به اسم SRP باعث over-engineering و باز کردن دهها فایل برای یه قانون ساده میشه
