AzLearn

محاكاة صراف آلي بـ OOP

ATM Simulation with Classes

تطبيق ~28 دقيقة

محاكاة صراف آلي بـ OOP — ATM Simulation with Classes

في هذا الدرس ستبني نظام صراف آلي (ATM) خطوة بخطوة بمفاهيم OOP التي تعلّمتها: class, __init__, __str__, __repr__, وراثة، وتطبيق عملي لتعدد الأشكال. الهدف ليس بناء نظام بنكي حقيقي — الهدف أن ترى كيف تتعاون الكلاسات لتُنشئ نظاماً متماسكاً.

فكّر في النظام من الأعلى: الصراف يتعامل مع حسابات (Accounts)، وكل حساب يحتفظ بـسجل معاملات (Transactions). عندما تفكر هكذا — “ما هي الكيانات؟ ما هي علاقاتها؟” — أنت تفكر بطريقة OOP.

الخطوة 1: فئة Account — الحساب البنكي

نبدأ بأبسط شيء: حساب له رقم، صاحب، ورصيد.

main.go

الرصيد الافتدائي balance=0 يجعل الحقل اختيارياً — يمكن فتح حساب فارغ أو بمبلغ ابتدائي.

الخطوة 2: إضافة الإيداع

الإيداع (Deposit) عملية بسيطة: نضيف المبلغ للرصيد مع التحقق من أن المبلغ موجب.

main.go

الخطوة 3: السحب مع التحقق من الرصيد

السحب (Withdrawal) أكثر تعقيداً: نتحقق من وجود رصيد كافٍ قبل الخصم.

main.go

ValueError مناسب هنا لأن القيمة المُمرَّرة (المبلغ) غير صالحة في السياق الحالي. في نظام حقيقي قد تصنع استثناءً مخصصاً مثل InsufficientFundsError(Exception) — لكن ValueError كافٍ في هذه المرحلة.

الخطوة 4: سجل المعاملات

كل حساب بنكي حقيقي يحتفظ بتاريخ المعاملات. نُضيف فئة Transaction وندمجها في Account.

main.go

الخطوة 5: فئة Bank — البنك يُدير الحسابات

البنك (Bank) يُنشئ الحسابات ويُدير مجموعتها. هذا النمط يُسمى Aggregation — فئة تحتوي على مجموعة من كائنات فئة أخرى.

main.go

ما الذي تعلمناه؟

في هذا الدرس ربطنا جميع مفاهيم OOP معاً:

  • تعريف الفئات: Account, Transaction, Bank — كل فئة مسؤولة عن شيء واحد (Single Responsibility).
  • __init__: كل فئة تُعدّ حقولها الخاصة عند الإنشاء.
  • __str__ و__repr__: المعاملات تطبع بشكل مقروء، والكائنات لها تمثيل تقني.
  • __len__: len(account) يُرجع عدد معاملات الحساب، len(bank) يُرجع عدد الحسابات.
  • التحقق من الأخطاء: ValueError يوقف المعاملة غير الصالحة قبل أن تُعدّل الحالة.
  • Aggregation: Bank يحتوي على قاموس من Account، وAccount يحتوي على قائمة من Transaction.
تحدي — Challenge