مبادئ SOLID من خلال قرارات تصميم صغيرة
تعامل مع SOLID كأدوات لتقليل أسباب التغيير وتحسين الاختبار، لا كقواعد تدفعك إلى عشرات الواجهات والطبقات.
Single Responsibility: سبب واحد مهم للتغيير
المسؤولية الواحدة لا تعني أن كل class يحتوي دالة واحدة. ابحث عن أسباب التغيير التي تأتي من جهات مختلفة. إذا كانت خدمة إصدار فاتورة تحسب السعر وتنسق PDF وترسل البريد، فإن تعديل ضريبة أو قالب أو مزود بريد يلمس المكان نفسه. فصل الحساب عن العرض والتسليم يجعل كل قرار أوضح وأسهل اختبارًا.
لا تفصل الشيفرة لمجرد أن الملف تجاوز عددًا عشوائيًا من الأسطر. ابدأ عندما ترى مفاهيم مستقلة أو اختبارات تحتاج تجهيزًا مختلفًا. الفصل الجيد يقلل المعرفة المطلوبة للتعديل، والفصل السيئ يجبرك على فتح خمسة ملفات لفهم سطر واحد.
Open/Closed وLiskov دون شعارات
عندما تتغير طريقة حساب الخصم كثيرًا، يمكن تمثيلها كاستراتيجية لها عقد واحد بدل if ضخمة تتكرر في أماكن متعددة. يصبح إضافة نوع جديد امتدادًا صغيرًا. لكن إنشاء interface لشيء له تنفيذ واحد ولا يتوقع تغييره قد يكون تكلفة بلا قيمة.
مبدأ Liskov يسأل إن كان البديل يحافظ على توقعات المستدعي. إذا كان نوع فرعي يرمي خطأ في عملية وعد العقد بأنها متاحة، فهو ليس بديلًا حقيقيًا. صمم العقود حسب السلوك المضمون، لا حسب التشابه الاسمي بين الكائنات.
type DiscountPolicy = {
apply(subtotal: number): number;
};
class CheckoutService {
constructor(private discount: DiscountPolicy) {}
total(subtotal: number) {
return subtotal - this.discount.apply(subtotal);
}
}Interface Segregation وDependency Inversion
الواجهة الصغيرة المبنية حول احتياج المستهلك أفضل من واجهة ضخمة تجبر كل تنفيذ على دوال لا يستخدمها. شاشة تعرض اسم المستخدم لا تحتاج مستودعًا يعرّف الحذف وتغيير الدور وكشف كل البيانات. عقد قراءة ضيق يقلل الصلاحيات ومساحة الاختبار.
Dependency Inversion تعني أن منطق المجال لا يرتبط بتفصيل متغير مثل Prisma أو مزود بريد بعينه. مرر له عقدًا يؤدي العملية المطلوبة. لا يعني ذلك بناء container معقد دائمًا؛ constructor parameter أو دالة تمرر كاعتماد قد تكون كافية.
- •ابدأ من احتياج المستهلك عند تعريف العقد.
- •أبقِ تفاصيل الشبكة وقاعدة البيانات عند الحواف.
- •اختبر منطق المجال ببديل صغير يمكن التحكم فيه.
متى تتوقف عن التجريد؟
إذا لم تستطع تسمية التغيير المتوقع أو الألم الحالي، لا تضف طبقة احتياطًا للمستقبل. انتظر حتى يظهر نمط ثانٍ حقيقي، ثم استخرج الجزء المشترك دون إزالة الاختلافات المهمة. قاعدة الثلاث مرات مفيدة كإشارة وليست قانونًا.
راجع التصميم بسؤالين: هل يستطيع مطور جديد تتبع المسار الأساسي بسهولة؟ وهل يمكن اختبار قرار العمل دون تشغيل كل البنية التحتية؟ إذا كانت الإجابة نعم، فغالبًا لديك توازن جيد حتى لو لم يبدو الرسم المعماري كبيرًا.
المراجع ومزيد من القراءة
عن المؤلف
يراجع أسامة زيدان محتوى كود هاب بهدف تقديم شرح عربي واضح يربط المفاهيم البرمجية بالقرارات التي يواجهها المتعلم أثناء التطبيق.
صفحة المؤلف