اصل تکمسئولیتی؛ وقتی خودِ قاببندی مسئلهساز است
· ۱۷ دقیقه مطالعه
این نوشته دربارهی این نیست که کسی اصل تکمسئولیتی را «بد اجرا کرده» و اگر کمی دقیقتر اجرا میکرد، همهچیز درست میشد. نقد من کمی ریشهایتر است: خودِ قاببندی این اصل گاهی ما را با سؤال اشتباهی وارد طراحی میکند.
بهجای اینکه از خودمان بپرسیم «این مرزبندی در طول زمان چه هزینهای دارد؟»، خیلی زود میپرسیم: «این کلاس چند مسئولیت دارد؟» همین تغییر کوچک در سؤال، ما را آرامآرام به سمت شکستن کد بر اساس مسئولیتهای ظاهری میبرد: Validator، Policy، Factory، Writer، Service.
گاهی نتیجه، کدی است که از دور مرتبتر و حرفهایتر به نظر میرسد؛ اما تصمیم اصلی دامنهای در آن مالک روشن ندارد. حرف اصلی این متن همین است: جداسازی باید هزینهی آینده را کم کند؛ اگر فقط ظاهر امروز را تمیزتر کند، هنوز باید از خودش دفاع کند.