ابسط طريقة لتحليل الانظمة في الOOP هي ان تستمع للعميل وهو يقص عليك رحلة عميله مع النظام المتخيل Use Cases سيسرد مجموعة اسماء و افعال. الاسماء ستصبح Classes و الأفعال تصبح Methods في ال Class diagram. ثم تدون تخاطب هذه الاشياء مع بعضها في Sequence Diagram.
هذا تستطيح .نعم
(سلسلة)
هذا تستطيح .نعم
(سلسلة)
للمعلومية فحتى هذا التسطيح لم يكن موجوداً في الثمانينات. فعندما سأل بعض الحضور مصمم لغة ++C عن كيفية تحديد الClasses اجاب انها شيء اشبه بالحلم الذي يسعى لتحقيقه الجميع. او كما وصفها بالكأس المقدسة Holy Grail او دواء كل الامراض panacea الذي تحاول البشرية الوصول له من فجر التاريخ.
يظهر ان السيد Stroustrop وقتها متأثر بالStructured Programming في لغة C و يظهر ذلك من تسميته الاولى ل++C بـ C with Objects بالاضافة الى تصريحه الواضح ان ++C ليست لغة Object Oriented. في الحقيقة لا توجد لغة OO حيث ان الOO هو طريقة تفكير لا تقنية. كلام Stroustrop كان عام 1985
التاريخ مهم هنا حيث انه في عام 1972 اعلن Dijkstra في مؤتمر عن كارثة البرمجيات Software Crisis قبلها بعام فقط ظهرت Simula بمفهوم الClasses لكن هذا لا يعني وجود الObject Oriented. فالهدف من Simula كان المحاكاة
ولم تنضج فكرة الOOP بعد.
ولم تنضج فكرة الOOP بعد.
في عام 1986 ابو هندسة البرمجيات Fred Brook قال انه لا توجد رصاصة فضية لقتل المستئذب ( Software crisis ) و لم يتكلم احد. لكن في عام 1992 اي بعد 6 سنوات كتب شخص يدعى Brad Cox وهو مصمم لغة Objective-C مقالاً يرد فيه على Brook بـ ماذا لو كان هناك رصاصة فضية بالفعل؟.
هنا اخذ Grady Booch و صديقيه زمام الأمور لاثبات ذلك الأمر و ظهر مفهوم الOOAD .. Object Oriented Analysis & Design او ما تسمى اختصارا Booch Method.
ما سبق كان مجرد مقدمة , لأن موضوع السلسلة هو الانسنة .
ما سبق كان مجرد مقدمة , لأن موضوع السلسلة هو الانسنة .
الطريقة في اول السلسلة هي ما تدرس في الكتب و المناهج عادة و هي التي يتبعها اغلب المبرمجين. فإذا لم تسمع مصطلح استعارة Metaphor و انسنة Anthropomorphization فقد تحتاج لمراجعة فهمك لل الOOP.
نستطرد قليلاً, كتاب كليلة و دمنة التي ترجمها ابن المقفع للعربية, استخدم فيها المؤلف انسنة الحيوانات لحل مشاكل اخلاقية. الانسنة هنا انه جعل الحيوانات تنطق و تحاكي البشر في تصرفاتهم والاستعارة هو اختياره لحيوانات معينة للقيام بدور معين.
هذا جزء من نظرية العقل , العقل تقبل في هذا السياق ان يتكلم الاسد و الثور و تنطق الحمامة فالمهم هو الهدف. و الكتاب مع قدمه تُرجم لاغلب لغات اهل الارض و هذا دليل نجاح.
نعود للOOP. طريقة التحليل في اول السلسلة لا تكفي, فالObject او الClasses التي ستستخرج من حديث العميل لا تتعدى ان تكون Data Structure و هذا ما يحصل فعلاً. تتحول تلك الكلاسات الى حاضنة بيانات تمثل جداول في قاعدة البيانات. ثم يتم ادارتها من Class اخر في الApplication Layer مثلا.
الانسنة تقتضي هنا انه كما ان هناك كلاسات تحمل و تمثل البيانات فإيضاً يجب ان يكون هناك كلاسات تمثل الBehavior. فمثلاً لو لدينا Student و Teacher و Classroom. في الواقع يسجل المعلم الطالب في الصف.
لكن ليس هذا هو الواقع, فهناك موظف اخر يقوم بهذا, ربما مساعد ولا يهمنا وظيفته هنا او اسمه بل يهمنا دوره .. عندها يمكن تسميته StudentRegistrar
الفكرة هي في انسنة الObjects بأن نتخيلها اشخاص لهم ادوار معينة و ندخلهم بداخل الProcess حتى تكتمل العملية و يتحقق الهدف , حتى لو ظهر معنا 100 كلاس لهذه الجزئية. تقليلها هو دور الRefactoring بجعل الProcess أبسط و اكثر كفائة, كما يفعل مهندس الاجراءات ,
هندسة الاجراءات مهمه لأي منشأة. هناك انظمة تعمل لكن لها ضجيج , استهلاك للذاكرة استهلاك للCPU , تأخر , تكلفة , تعقيد .. الخ. هذا يعني ان هناك خلل في ادارة الاجراءات او التواصل بين الClasses او الCompnenets بداخل النظام. الموضوع ليس تقني بحث و هذا عمل الArchitect الحقيقي.
قبل ان انسى لاحظ ايضاً ان هذا التفاعل او التخاطب بين الطالب و الاستاذ و الفصل و المسجل في المثال السابق في ارض الواقع لا يوجد من يديره مباشرة, بل هي شيء اشبه بالاحداث Events تستجيب لبعضها حتى تكتمل المهمة. كل Object يعرف مهامه و مسؤولياته و قواعد عمله ثم يترك في العالم.
الDDD اتت بأدوات تساعد على التحليل و التصميم ايضاً لكن دائماً في هذه المرحلة كن اقرب للمشكلة Problem Space لا للحل. هناك مقولة لا اذكرها تحديداً لكن مفادها ان المشكلة ان تفحصتها جدياً فستخبرك هي بالحل.
انسى الاشياء التفصيلية الثانوية المتغيرة عادة كقواعد البيانات و الapi و الشاشات فهي لسيت برنامجك هي مجرد تفاصيل Details بلسان Uncle Bob.
- هذا ودمتم.
- هذا ودمتم.
جاري تحميل الاقتراحات...