نبدأ نصمم الكلاسات للعبة الشطرنج , عندنا Game فيها Player و Board و الBoard يحتوي قطع هي King الملك , Queen ( الوزير - الملكة ) عندنا Rook ( غراب (رخ) - قلعة ) عندنا Bishop ( فيل - صاروخ - جمل ) و عندنا Knight ( حصان ) و 8 Pawns ( جنود - بيادق ). (سلسلة )
الOOP عند التصميم خصوصاً للClass Diagram تتعلق بالInterface و ليس بالImplementation لذلك علينا النظر من زواية اعلى دون التفكير في التفاصيل. فنكتب مثلا اسم الميثود دون التطرق إلى عملها.
فاذا كان هناك علاقة مخفية بداخل احد الMethod مع كلاس اخر فمن الافضل تجاهلها لاننا مثل ما ذكرت فنحن هنا نتكلم عن الInterface و ليس عن الImplementation. و محتويات الميثود تعتبر Implementation.
لاحظ ان ما ذكرناه في البداية جميعهم قطع فهنا ممكن نستخدم الInheritance بإنشاء Abstract Class نسميه Piece (قطعة) و نضيف فيه كل الصفات و الاعمال المشتركة مثل name و move ثم نرسم علاقة Inheritance بينهم. بحيث يصبح الPiece عبارة عن Super class.
بعدها في كل كلاس نقوم بعمل Override للMethods مثل move و نضع به طريقة و قوانين حركته و ربما من خلال استدعاء كلاس اخر يحسب لنا التنقلات الممكنة لتلك القطعة.
تقسيمنا للClasses و فصلها يجب ان يكون مدفوعاً بمباديء SOLID . كل كلاس يقوم بوظيفة واحدة و يكون قابل لاضافة مميزات من دون تغيير الكلاس نفسه و يكون مرادف للسوبر كلاس الى اخر الSOLID.
من قواعد لعبة الشطرنج ان البيدق ( الجندي ) اذا وصل إلى اخر الرقعة يمكن استبداله بأي قطعة اخذها الخصم. هذه شيء خاص فقط بالجندي . فهنا يمكن عمل Interface نسميه IReplaceable يقوم كلاس الPawn فقط بعمل Implementation له. هذا Liskov Principle.
لعبة الشطرنج تختلف عن البرامج الاخرى مثل البرامج المالية او اي برنامج فيه Process واضح. فاللاعب هنا حر في تنقلاته ضمن الشروط و لذا فنحن هنا اما نظام Event Driven اي اننا سنستجيب للأحداث التي يقوم بها اللاعبين.
فكلاس اللعبة Game سيحدد دور من الان, و اذا قام اللاعب بمسك حجر ( Event ) سيتجيب كلاس الMovement مثلا بتحديد المواقع الممكنة و اذا كان في الموقع حجر اخر له سيمنعه و اذا كان حجر للخصم سيقوم بقتله و يعدل النتيجة.
ايضا هناك Events تطلقها الاحجار للتنبيه او اعلان المقتل , مثل اذا كان هناك كش ملك Check mate فمن الافضل ان يقوم الملك بإرسال الحدث اذا وقع في مرمى حجر خصم او ربما انشأنا كلاس اخر نسميه KingGuard مهمته المراقبة و حراسة الملك و اخر اسممه GameWatcher. هنا الفن و المتعة.
التحليل و التصميم عملية ممتعة خصوصاً اذا ابتعدنا عن التفكير في الCode. فهي عملية بلا حدود و لا يوجد بها صح او خطأ فقط افضل و أسوا و قد تبدأ بالاسوأ ثم تحسن . الشيء المهم جداً فيها ان تكون فاهم للبزنس ( طريقة اللعبة و قوانينها ).
لعبة كهذه يمكن تطبيق اغلب المفاهيم و الطرق البرمجية عليها فيمكن تجربة الDomain Driven Design و تكون الاحجار Entities و الBoard مثلا Aggregate و ValueObject للنقاط. ثم يمكن بناء جعل الحل موافق للClean Architecture ثم نربط به قواعد البيانات و الUI من الخارج.
إيضاً بالنسبة للDesign Patterns فيمكن استخدام الFactory و الBuilder ايضا الStrategy pattern و الMemento للUndo مثلا. ايضا يمكن استخدام الObserver pattern. افضل طريقة للتعلم هي توظيفها في مشروع و ليس مجرد example.
اكتفي بهذا حتى لا أكثر و يمكن مناقشة النقاط التي ذكرتها في التعليقات لمن اراد تفاصيل اكثر. في السلسلة القادمة سأتحدث عن المرحلة الثانية و هي كيف نصنع لاعباً آلياً.
جاري تحميل الاقتراحات...