آموزش اصول سالیدبرنامه‌نویسی شی‌گرا

۰۱ اصل دوم، وقتی روی کد نوشته شود

تابعی که برای هر قالب فایل یک elif دارد، هر بار که قالب تازه‌ای اضافه می‌شود ویرایش می‌شود، و همان ویرایش است که ممکن است حالت‌های قبلی را بشکند. همان منطق با یک نگاشت از پسوند به کلاس، بدون هیچ شاخه‌ای نوشته می‌شود و اضافه کردن قالب تازه فقط یک سطر داده است. کد قدیمی اصلا باز نمی‌شود، پس نمی‌تواند بشکند. شکل کاملش در راه‌های ساختن یک شی، وقتی سازنده ساده کافی نیست است.

اصل اول را هم می‌شود روی همان فایل دید: کلاسی که هم فایل را می‌خواند، هم مبلغ را حساب می‌کند و هم ایمیل می‌فرستد، سه دلیل برای عوض شدن دارد. تغییر قالب فایل، تغییر نرخ، و تغییر سرویس ایمیل هر سه همان فایل را باز می‌کنند، و هر سه ریسک شکستن دو تای دیگر را دارند.

۰۲ پنج اصل جواب هیچ چیزی نیستند اگر مسئله‌ای نباشد

خطر واقعی این فهرست پیروی زودهنگام است. کدی که برای یک حالت نوشته می‌شود و از اول با پنج کلاس انتزاعی و یک لایه تزریق وابستگی ساخته شده، از کد ساده بدتر است: خواندنش گران‌تر است و انعطافی که خریده هیچ‌وقت استفاده نمی‌شود. ترتیب درست این است که ساده بنویسید، و اولین باری که حالت دوم آمد، همان لحظه بازآرایی کنید. عوض کردن شکل، بدون عوض کردن رفتار ابزار همان لحظه است.

۰۳ جایی که کار گیر می‌کند، سوال مصاحبه است

در ایران این پنج حرف تقریبا همیشه به‌عنوان سوال مصاحبه یاد گرفته می‌شوند و نه به‌عنوان معیار بازبینی کد. نتیجه‌اش دو رفتار متضاد است که هر دو را زیاد می‌شود دید: یا هیچ‌کدام در کد واقعی به کار نمی‌رود، یا کسی که تازه خوانده‌شان کل پروژه را با پنج اینترفیس بازنویسی می‌کند برای منطقی که یک پیاده‌سازی بیشتر ندارد. راه میانه یک عادت است: هنگام بازبینی کد فقط دو پرسش بپرسید، اینکه این فایل برای چند دلیل عوض می‌شود، و اینکه اضافه کردن حالت بعدی چند سطر موجود را دست می‌زند.

۰۴ ابزار، و سالی که این حرف درست است

در سال ۲۰۲۶، اصل چهارم و پنجم را می‌شود با typing.Protocol در کتابخانه استاندارد پیاده کرد و رایگان است؛ جای کلاس پایه بزرگی را گرفته که همه از آن ارث می‌برند و نصف متدهایش را با pass پر می‌کنند. برای دیدن اینکه کدام فایل‌ها با هم عوض می‌شوند، که آزمون واقعی اصل اول است، تاریخچه خود مخزن کافی است و git log با گزینه نمایش فایل‌های هر کامیت این را می‌گوید؛ فایل‌هایی که همیشه با هم در یک کامیت‌اند یا باید یکی شوند یا مرزشان اشتباه است.

پرسش بعدی این است که وقتی همین اصل‌ها را روی مسئله‌های تکراری اعمال کنید چه شکل‌های نام‌داری بیرون می‌آید، که اینکه شی‌ها چطور با هم حرف می‌زنند اولین دسته‌اش است. و ابزاری که اصل چهارم و پنجم را ممکن می‌کند در نام بردن یک توانایی، بدون نام بردن پیاده‌سازی است.