قبل تحليل لعبة الشطرنج سنبدأ بالModeling. ما هي الObjects التي لدينا في اللعبة ؟ لدينا مباراة , لاعب , لوح شطرنج , بيادق . هذه الظاهرة لنا لكن يمكن أن تظهر كلاسات اخرى مثل للنتيجة , للتحركات , اماكن التحرك الممكنة و قد تظهر اخرى اثناء التصميم.
لكن هناك اشياء علينا فهمها. (سلسلة)
لكن هناك اشياء علينا فهمها. (سلسلة)
الModeling لا يعني بالضرورة اننا نتعامل مع Object Oriented Programming فلغة Simula كانت لمحاكاة السفن بطريقة الClasses و بها Methods لكنها لم تكن OOP. الOOP ألحقيقية كانت لغة Smalltalk و طريقتها تختلف عن ما نعرفه عن OOP كما في جافا او بايثون او سي++.
حسب مبتكر مفهوم الOOP و مصمم لغة Smalltalk فإن الفكرة الأساسية في الOOP هي الMessages. في لغات مثل جافا و سي شارب لا يمكن مباشرة تطبيق هذا المفهوم و نحتاج إلى مكتبات خاصة , فمناداة ميثود من كلاس اخرى و ارسال باراميتر له لا يعني اننا ارسلنا له Message.
لكي تكون Real OO نحتاج إلى ان نغير طريقة التفكير قليلاً ( ذكرت سابقاً مثال خلايا الجسم ) تعمل مع بعضها كـTeam و ليس كـ Master Slave أي لا يوجد كلاس يأمر أخر بفعل شيء و نحتاج لتغيير طريقة التحليل فحتى UML هنا قد لا تكون مناسبة.
الFunctional Programming مثلاً مبنية على الLambda Calculus لكن الOOP ألتي نعرفها ليس لها اساس رياضي حسب علمي. هناك اجتهادات لربطها بالرياضيات لكن الربط ليس بقوة ربط الFP مع الرياضيات.
هناك نموذج رياضي يسمى Actor Model قد يعيدنا إلى الOOP الحقيقية و يمكن التعامل معه عن طريق جافا من خلال مكتبة مثل Akka و مع سي شارب بمكتبة Akka.net و لدى ما يكروسوفت مكتبة اخرى اسمها Orleans @msftorleans.
التعامل مع الActor Model مختلف قليلاً كما ذكرت , فمثلاً يتم نمذجتها بشكل افضل مع EEML بدل UML. سأفرد سلسلة مستقلة للحديث عن Orleans كونها سهلت كثير التعامل مع الActor Model و سأكتب عن فكرة الActor Model كمفهوم و كيف حل مشكلة الConcurrency مع الMulti cores.
في السلسلة التالية سأعود للحديث عن نمذجة Modeling لعبة الشطرنج بواسطة UML بالطريقة التي نعرفها جميعاً. و كيف نطبق مفاهيم و مباديء ال OOP و تقنيات الـ OOAD عليها. ثم في السلسلة القادمة سنتكلم عن المرحلة الثانية بشأن طريقة احتساب الاحتمالات و الخوارزميات اللازمة لها.
جاري تحميل الاقتراحات...