يعد الـ Observer design pattern واحد من أشهر الـ design patterns .. ومستخدم بشكل أساسي في تطوير تطبيقات الأندرويد والـ IOS .. خلونا في هذا الثريد الشامل نتعرف أكثر على هذا الـ design pattern ومميزاته وعيوبه .. وكيف ممكن نستخدمه في مجال تطوير التطبيقات
#كوكبة_المبرمجين #اندرويد
#كوكبة_المبرمجين #اندرويد
ينتمي الـ observer design pattern إلى فئة الـ behavioral DPs .. طبيعة تطوير تطبيقات الاندرويد والـ IOS جعلت منه الرقم واحد في الاستخدام في كثير من الـ use-cases وكثير من اللغات باتت تدعم مكتبات وإضافات تستخدم هذا الـ design pattern بشكل رئيسي
المشكلة الأساسية اللي حلها هذا الـ DP هي مشكلة الـ tight coupling مابين الكلاسات التي تتواصل مع بعضها البعض بشكل يصعب علينا إعادة إستخدامها وإختبارها .. وخصوصاً لما نتعامل مع بيئة تطبيقات الجوال اللي تعتبر بيئة محدودة من ناحية الموارد اللي من الممكن إنها تخصص لك ولتطبيقك
لذلك بدأنا نرى توجه كبير من جوجل وأبل في تطويرهم لمكتبات تتمحور حول هذا الـ DP .. وأهم هذه المكتبات على الاندرويد مكتبة LiveData واللي كانت من أهم الأسباب اللي ساعدت في انتشار مفهوم الـ MVVM (Model – View – ViewModel) في تطوير تطبيقات الأندرويد
حتى نستطيع فهم الـ observer design pattern بطريقة سهلة .. لنأخذ مثال لتطبيق مختص بمعرفة آخر أخبار الأسهم .. بحيث يقوم التطبيق بإرسال notification بشكل مباشر للمستخدم في حال تغيرت حالة (state) السهم سواء بالسلب أو بالإيجاب ..
يتكون مفهوم الـ observer من فكرتين أساسية:
- الكائن المراد معرفة حالته الجديدة بمجرد تغير حالته القديمة وهو في مثالنا السابق يمثل السهم ويسمى بالـ observable
- الجهة المهتمة بمعرفة آخر حالة للـ observable أو السهم وهو في مثالنا السابق يمثل المستخدم للتطبيق ويسمى بالـ observer
- الكائن المراد معرفة حالته الجديدة بمجرد تغير حالته القديمة وهو في مثالنا السابق يمثل السهم ويسمى بالـ observable
- الجهة المهتمة بمعرفة آخر حالة للـ observable أو السهم وهو في مثالنا السابق يمثل المستخدم للتطبيق ويسمى بالـ observer
لفهم آلية عمل هذا الـ DP سنقوم بشرح الـ use-case السابقة بشكل تطبيقي
بمجرد دخولك للتطبيق كمستخدم جديد ستقوم بإخبار السهم أو الـ observable بأنك مهتم بالحصول على آخر تحديثاته وهو مايعرف بعملية الـ registration .. حيث يقوم فيها الـ observable بتسجيل كل المهتمين به من الـ observers
بمجرد دخولك للتطبيق كمستخدم جديد ستقوم بإخبار السهم أو الـ observable بأنك مهتم بالحصول على آخر تحديثاته وهو مايعرف بعملية الـ registration .. حيث يقوم فيها الـ observable بتسجيل كل المهتمين به من الـ observers
بعد ذلك .. بمجرد تغير حالة السهم أو الـ observable سيقوم مباشرة بإخطار كل الـ observers المسجلين لديه .. ولكن من المهم إختيار طريقة مناسبة لإخبار الـ observers بتغير حالتك .. وتكون على نوعان
النوع الأول .. هو إرسال الحالة الجديدة للـ observable إلى كل الـ observers بشكل مباشر .. وهو أمر مكلف وخصوصاً في حال كانت الـ state الجديدة ثقيلة .. ولكنك تضمن بأن جميع الـ observers وصلت لهم الحالة الجديدة وبدون أي مشاكل
النوع الثاني .. كما توقعت .. هو إخبار الـ observers بتغير حالتك بدون إرسال أي معلومات أو ما يعرف بالـ light message .. وستكون مهمة معرفة الـ state الجديدة من نصيب الـ observers بحيث يقوموا هم بجلب المعلومات المطلوبة من الـ state الجديدة للـ observable
لا يوجد خيار أفضل من خيار .. من المهم جداً تقييم الـ use-case المراد تطبيق فكرة الـ observer DP عليها وإختيار الأفضل ..
السؤال الآن .. ماذا لو كنا نملك أكثر من component داخل التطبيق .. ونحتاج أن يلعب هذا الـ component دور الـ observable ودور الـ observer في نفس الوقت .. سنعود مجدداً لنفس المشكلة .. وهي الـ tight coupling ما بين هذه الـ components ولو بشكل غير مباشر
هذه المشكلة كانت سبباً في إنشاء أسلوب بناء أو Architecture كامل قائم على فكرة الـ observer DP وهو ما يعرف بالـ Event-Driven Architecture أو EDA .. وواحد من أشهر الامثلة على الـ EDA هو ما يعرف بالـ event bus pattern
يقوم هذا الـ pattern على فكرة إسناد مهمة إخبار الـ observers بتغير حالة الـ observable إلى component منفصل ومستقل عن الجميع يعرف باسم Event Bus .. حيث تقوم جميع الـ components بالاشتراك في هذا الـ event bus لارسال واستقبال events تعمل بنفس الطريقة العادية السابقة
يختلف مفهوم الـ event bus في أن الـ components عندما تسجل نفسها كمستفيدة من هذا الـ bus تستطيع التواجد كـ observable وكـ observer بنفس الوقت .. وهو حل مباشر للمشكلة
في حال رغبتك بلعب دور الـ observer ستقوم بإخبار الـ bus بنوع الـ event المهتم بها وسيقوم الـ bus بتنبيهك في حال دخول event جديد من نفس النوع .. وفي حال رغبتك بلعب دور الـ observable ستكون قادراً على إرسال أي event للـ bus ليتم معالجته من باقي الـ components ..
كلام كبير صح ??
كلام كبير صح ??
بعيداً عن هذا الكلام هل في الواقع يوجد تطبيقات تستخدم هذا الـ architecture بشكل فعلي ؟ الجواب هو نعم ولكن بطريقة غير مباشرة
يوجد نوع من أنواع الـ EDA يطلق عليه إسم Event Sourcing .. يقوم هذا النوع بتخزين جميع الـ events المهتم بها component معين قبل تغيير حالة هذا الـ component
يوجد نوع من أنواع الـ EDA يطلق عليه إسم Event Sourcing .. يقوم هذا النوع بتخزين جميع الـ events المهتم بها component معين قبل تغيير حالة هذا الـ component
بسبب تخزينه لكل الـ events .. يمَكنك الـ event sourcing من العودة والتنقل بين states قديمة للـ component وتسهيل عملية الـ debugging في حال حدوث مشكلة .. " بس دقيقة .. مايذكرنا هذا النظام بأداة نستخدمها في تطوير المشاريع البرمجية؟ " .. بالضبط .. نظام الـ git versioning control ..
نظام الـ git ومن قبله cvs كلها تعتمد على هذا الـ architecture .. بحيث يكون الكود الذي تعمل عليه .. هو الـ component وعند حدوث أي event مثل push or pull تقوم الأداة بتخزين الـ event قبل تغيير الكود البرمجي بحيث يمكنك الرجوع إلى أي state قديمة والتعديل عليها
في عالم تطوير تطبيقات الأندرويد .. وفي ظل التوجه إلى مفهوم الـ single activity application .. نحتاج لوجود الـ event bus لتسهيل عملية تواصل الـ fragments المختلفة مع الـ container activity .. بدلاً من الطريقة المعتادة وهي الاعتماد على الـ interfaces للتواصل
من أشهر المكتبات اللي تساعدك في تطبيق هذه الفكرةفي تطبيقك الأندرويد هي مكتبة greenrobot وبإمكانك زيارة المكتبة على الـ github من خلال الرابط بالأسفل
للتعرف أكثر عن موضوع التغريدات .. أنصح بقراءة موضوع الـ EDA من مهندس البرمجيات Martin Fowler .. انتهى
github.com
للتعرف أكثر عن موضوع التغريدات .. أنصح بقراءة موضوع الـ EDA من مهندس البرمجيات Martin Fowler .. انتهى
github.com
جاري تحميل الاقتراحات...