أحد أركان الOOP هو ما يسمى abstraction، وترجمتها الحرفية تعني التجريد بس معناها في السياق بتاعنا: إخفاء تفاصيل التنفيذ hiding implementation. التفاصيل دي ممكن تكون صعوبة في التنفيذ complexity أو قصور limitations في التفاصيل المخفية دي بيتم عزلها عشان ما تحسش إنها موجودة.
تعالوا ناخد مثال: العربية بتاعتك معمول فيها abstraction عظيم للموتور، الشركة المصنعة بتديك دركسيون و دواسات وفتيس عشان تشغل الموتور ده.
الموتور شغال إزاي؟ ما يهمكش.
طيب لو الموتور سخن ممكن يبوظ نعمل إيه؟ الشركة المصنعة برضو عاملة لك عزل للتفاصيل abstraction بتاعت حدود إمكانيات الموتور وعاملين دائرة تبريد عشان تتلافى المشكلة دي. لو حصل بقى إن دائرة التبريد دي فشلت و الموتور سخن وباظ (يعني عزل التفاصيل فشل لسبب ما)، قدامك حل من اتنين: يا إما تروح لميكانيكي شاطر عارف تفاصيل عمل الموتور، و بالتالي عارف إن العربية كده يبقى جابت وش سلندر فيصلحهولك، يا إما تروح التوكيل فيغيرولك الموتور كله وتدفع دم قلبك. و في الحالتين أنت هاتفضل قادر على استخدام العربية عن طريق الدركسيون و الدواسات والفتيس. الشركة المصنعة نجحت كتير في عزل تفاصيل آلية عمل الموتور، لكن أحيانا العزل ده مش بيشتغل لظروف خارجة عن إرادة العربية و بتضطر تعرف إن فيه حاجة اسمها وش السلندر ممكن يبوظ و إزاي نصلحه.
أي حد اشتغل على ال WIN32 API يعرف قد إيه حاجة زي Visual C++ سهلت الدنيا عن طريق عزل الصعوبات اللي كانت موجودة قبلها في برمجة الويندوز. و نفس الكلام الناس اللي اشتغلت .NET Framework بعد ما كانت شغالة win32 أو visual c++. السهولة دي (اللي جت من عزل التفاصيل الرخمة) خلتنا نقدر نعمل برامج ما كانش متاح عملها قبل كده. لكن أحيانا الabstraction ده بيبقى غير كافي و كنا بنضطر نتجاوزه و نفهم التفاصيل أكتر و نشتغل على الwin32 api مباشرة.
الORMs زي Hibernate أو Entity Framework عظيمة جدا، خاصة لما بيكون معاها Object Query Language زي الLinq تخليك مش محتاج تفهم sql كويس عشان تتعامل مع قاعدة البيانات، و بتديك مميزات بقى وأنت بتكتب استعلاماتك زي الstatic type checking و code auto-completion و حاجة آخر شياكة. عزل التفاصيل بتاعت التعامل مع قاعدة البيانات خلى حياة المبرمجين أسهل كتير و خلاهم يركزوا أكتر على البزنس بتاع البرنامج بتاعهم وما يشغلوش بالهم كتير بكيفية التعامل مع قاعدة البيانات. الدنيا بتفضل حلوة وجميلة لغاية لما تلبس في الحيطة في سرعة أداء performance الاستعلامات الناتجة عن الORMs. في الحالة دي بتضطر آسفا ترجع للsql عشان تكتب استعلامات ذات كفاءة.
طول ما أنت مش بتحتاج تعرف تفاصيل التنفيذ ولا بتحاول تتجاوز العزل اللي معمول عشان يخفيها عنك، فالabstraction بتاعك زي الفل. أول ما بتحتاج تفهم التفاصيل فالعزل بتاعك ابتدى يسرسب، أو ما أسماه جول سبولسكي (أحد مؤسسي stackoverflow):
Leaky Abstraction.
الحقيقة هو ما سماهوش بس، ده حط له قاعدة بتقول: إن أي عزل لتفاصيل التنفيذ، لو كان بيعزل حاجة مهمة يعني، فهو غالبا هايبقى مسرسب بدرجة أو بأخرى!
All non-trivial abstractions, to some degree, are leaky.
طيب إزاي أستفيد من القاعدة دي؟
- لما تيجي تتعلم تقنية جديدة بتعزل تفاصيل تقنية أقدم منها تؤدي نفس الغرض، تأكد إنك هاتحتاج تفهم التقنية القديمة في يوم من الأيام عشان التقنية الجديدة أكيد هاييجي اليوم اللي تسرسب فيه و تحتاج تفهم هي شغالة إزاي عشان تعالج السرسبة دي. ونفس الكلام عن الحاجات اللي بتعمل code generation عشان توفر عليك وقت التطوير، حاول تتعلم الشغل بيتعمل بلدي إزاي من غير الcode generation عشان لما الcode generation يسرسب تعرف تتعامل و ما تلبسش في الحيطة.
- لو العزل بتاعك سرسب غصب عنك ماشي هانعديهالك، لكن ما تجيش أنت تسمح بتسرب تفاصيل التنفيذ بمزاجك، تعالوا ناخد مثال شهير: لما الناس بينفذوا الrepository pattern أشهر طريقة لتنفيذه هي عن طريق إنه يعمل واحد generic و يرجع فيه IQueryable أو يقبل في Expression عام يسمح لمستخدم الrepository إنه يكتب الquery كيفما شاء. الطريقة دي في التنفيذ مسرسبة وش! كده أنت ما عزلتش تفاصيل الوصول للبيانات و خليت مستخدم الrepository عارف تفاصيل عمله. الrepository كده هايبقى سهل جدا في الاستخدام لكن بييجي من وراه مصايب كتيرة قوي. تخيل مثلا إنك لقيت query بطيء وعاوز تحسنه، في حالة الgeneric repository هاتحتاس عشان توصل للquery ده جاي منين، و بعدين هاتحتاس تاني لما تكتشف إنه متكرر في أكتر من مكان في البرنامج و محتاج تصلحه في كل الأماكن اللي هاتقعد تكتشفها بالصدفة!
أفضل طريقة لتنفيذ الrepository pattern - من وجهة نظري - هي مقالة نفسي أكتبها من زمان قوي، ربنا ييسر وتيجي قريب.
المقالة بتاعت جول سبولسكي في أول تعليق.
ياريت تنشروا المقالة لو حسيتوا إنها مفيدة، سلام
تعالوا ناخد مثال: العربية بتاعتك معمول فيها abstraction عظيم للموتور، الشركة المصنعة بتديك دركسيون و دواسات وفتيس عشان تشغل الموتور ده.
الموتور شغال إزاي؟ ما يهمكش.
طيب لو الموتور سخن ممكن يبوظ نعمل إيه؟ الشركة المصنعة برضو عاملة لك عزل للتفاصيل abstraction بتاعت حدود إمكانيات الموتور وعاملين دائرة تبريد عشان تتلافى المشكلة دي. لو حصل بقى إن دائرة التبريد دي فشلت و الموتور سخن وباظ (يعني عزل التفاصيل فشل لسبب ما)، قدامك حل من اتنين: يا إما تروح لميكانيكي شاطر عارف تفاصيل عمل الموتور، و بالتالي عارف إن العربية كده يبقى جابت وش سلندر فيصلحهولك، يا إما تروح التوكيل فيغيرولك الموتور كله وتدفع دم قلبك. و في الحالتين أنت هاتفضل قادر على استخدام العربية عن طريق الدركسيون و الدواسات والفتيس. الشركة المصنعة نجحت كتير في عزل تفاصيل آلية عمل الموتور، لكن أحيانا العزل ده مش بيشتغل لظروف خارجة عن إرادة العربية و بتضطر تعرف إن فيه حاجة اسمها وش السلندر ممكن يبوظ و إزاي نصلحه.
أي حد اشتغل على ال WIN32 API يعرف قد إيه حاجة زي Visual C++ سهلت الدنيا عن طريق عزل الصعوبات اللي كانت موجودة قبلها في برمجة الويندوز. و نفس الكلام الناس اللي اشتغلت .NET Framework بعد ما كانت شغالة win32 أو visual c++. السهولة دي (اللي جت من عزل التفاصيل الرخمة) خلتنا نقدر نعمل برامج ما كانش متاح عملها قبل كده. لكن أحيانا الabstraction ده بيبقى غير كافي و كنا بنضطر نتجاوزه و نفهم التفاصيل أكتر و نشتغل على الwin32 api مباشرة.
الORMs زي Hibernate أو Entity Framework عظيمة جدا، خاصة لما بيكون معاها Object Query Language زي الLinq تخليك مش محتاج تفهم sql كويس عشان تتعامل مع قاعدة البيانات، و بتديك مميزات بقى وأنت بتكتب استعلاماتك زي الstatic type checking و code auto-completion و حاجة آخر شياكة. عزل التفاصيل بتاعت التعامل مع قاعدة البيانات خلى حياة المبرمجين أسهل كتير و خلاهم يركزوا أكتر على البزنس بتاع البرنامج بتاعهم وما يشغلوش بالهم كتير بكيفية التعامل مع قاعدة البيانات. الدنيا بتفضل حلوة وجميلة لغاية لما تلبس في الحيطة في سرعة أداء performance الاستعلامات الناتجة عن الORMs. في الحالة دي بتضطر آسفا ترجع للsql عشان تكتب استعلامات ذات كفاءة.
طول ما أنت مش بتحتاج تعرف تفاصيل التنفيذ ولا بتحاول تتجاوز العزل اللي معمول عشان يخفيها عنك، فالabstraction بتاعك زي الفل. أول ما بتحتاج تفهم التفاصيل فالعزل بتاعك ابتدى يسرسب، أو ما أسماه جول سبولسكي (أحد مؤسسي stackoverflow):
Leaky Abstraction.
الحقيقة هو ما سماهوش بس، ده حط له قاعدة بتقول: إن أي عزل لتفاصيل التنفيذ، لو كان بيعزل حاجة مهمة يعني، فهو غالبا هايبقى مسرسب بدرجة أو بأخرى!
All non-trivial abstractions, to some degree, are leaky.
طيب إزاي أستفيد من القاعدة دي؟
- لما تيجي تتعلم تقنية جديدة بتعزل تفاصيل تقنية أقدم منها تؤدي نفس الغرض، تأكد إنك هاتحتاج تفهم التقنية القديمة في يوم من الأيام عشان التقنية الجديدة أكيد هاييجي اليوم اللي تسرسب فيه و تحتاج تفهم هي شغالة إزاي عشان تعالج السرسبة دي. ونفس الكلام عن الحاجات اللي بتعمل code generation عشان توفر عليك وقت التطوير، حاول تتعلم الشغل بيتعمل بلدي إزاي من غير الcode generation عشان لما الcode generation يسرسب تعرف تتعامل و ما تلبسش في الحيطة.
- لو العزل بتاعك سرسب غصب عنك ماشي هانعديهالك، لكن ما تجيش أنت تسمح بتسرب تفاصيل التنفيذ بمزاجك، تعالوا ناخد مثال شهير: لما الناس بينفذوا الrepository pattern أشهر طريقة لتنفيذه هي عن طريق إنه يعمل واحد generic و يرجع فيه IQueryable أو يقبل في Expression عام يسمح لمستخدم الrepository إنه يكتب الquery كيفما شاء. الطريقة دي في التنفيذ مسرسبة وش! كده أنت ما عزلتش تفاصيل الوصول للبيانات و خليت مستخدم الrepository عارف تفاصيل عمله. الrepository كده هايبقى سهل جدا في الاستخدام لكن بييجي من وراه مصايب كتيرة قوي. تخيل مثلا إنك لقيت query بطيء وعاوز تحسنه، في حالة الgeneric repository هاتحتاس عشان توصل للquery ده جاي منين، و بعدين هاتحتاس تاني لما تكتشف إنه متكرر في أكتر من مكان في البرنامج و محتاج تصلحه في كل الأماكن اللي هاتقعد تكتشفها بالصدفة!
أفضل طريقة لتنفيذ الrepository pattern - من وجهة نظري - هي مقالة نفسي أكتبها من زمان قوي، ربنا ييسر وتيجي قريب.
المقالة بتاعت جول سبولسكي في أول تعليق.
ياريت تنشروا المقالة لو حسيتوا إنها مفيدة، سلام
No comments:
Post a Comment