تكرار السؤال: …
الإجابة المختصرة
البرمجة الدفاعية تفترض أن جميع المدخلات غير موثوقة ويجب فحصها في كل دالة لتفادي الانهيار، بينما Design by Contract يحدد عقداً صريحاً بين المستدعي والمستدعى يتحمل كل طرف مسؤوليته فيه.
الشرح
الإفراط في البرمجة الدفاعية يؤدي لملء كل دالة داخلية بفحوصات if (arg == null) متكررة في كل طبقة حتى داخل الدومين الآمن. أما DbC فيحدد: الشروط المسبقة تقع على عاتق المستدعي (لو أرسلت قيمة سالبة فالخطأ خطؤك أنت)، والشروط اللاحقة يضمنها المنفذ. في الأنظمة الحديثة، تُستخدم البرمجة الدفاعية الصارمة على حدود النظام الخارجية (API Gateways, User Inputs)، بينما يعتمد الدومين الداخلي على DbC والأنواع القوية (Type Safety) لمنع التكرار.
مثال بالكود
// حدود النظام (Defensive Validation):
const body = validateSchema(req.body); // دفاعي صارم على الحدود
// منطق الدومين الداخلي (Contract):
executeTransfer(source, target, body.amount); // يثق في صحة النوع المنقىأخطاء شائعة
- تطبيق البرمجة الدفاعية على كل دالة private داخلية، مما يؤدي لتضخم الكود وإخفاء الأخطاء المنطقية بدلاً من كشفها في الاختبارات.