تقييم الموضوع :
  • 0 أصوات - بمعدل 0
  • 1
  • 2
  • 3
  • 4
  • 5
[مقال] خاطرة في تصميم التوابع Methods
#1
Lightbulb 
هذا الكود السابق مقتبس من كتاب مايكروسوفت Programming in C#. في هذا الكود فقط أود أن أتطرق إلى نقطة وهي أيّ (بتشديد الياء) التابعين أفضل من حيث البيانات (البرامترات) الممررة إليه؟
سأترك لك أولا وقت للتفكير،،
كود :
//LISTING 1 Passing a complete customer to a method

public Distance CalculateDistanceTo(Customer customer)

{

      Distance result = … // Some difficult calculation that uses customer.Address

      return result;

}



//LISTING 2 Passing only an address to a method

public Distance CalculateDistanceTo(Address address)

{

      Distance result = … // Some difficult calculation that uses address

      return result;

}

لكن إن أردت إشارات لتساعدك على الإختيار بنفسك فلك ذلك، سأطرح عليك بعض النقاط
1. أيّ الكودين يعتبر أوضح و أسهل للفهم من حيث المعلومات المطلوبة لإجراء عملية حساب المسافة؟
2. أي الكودين فيه سهولة في الصيانة مقارنة بالآخر؟ أو بمعنى آخر أي الكودين في سعة أكبر في استخدامه دون إجراء تعديلات؟ مرة أخرى ركز على المعلومات (البرامتر) الممرر لكلا التابعين.
طبعا الإجابة على كلا السؤالين هو الكود الثاني.

بالنسبة للسؤال الأول،،
 طبعا الكود الثاني أوضح وأسهل للفهم وذلك لأنه واضح من حيث متطلبات عمله فهو يطلب عنوان حتى يقوم بعملية حساب المسافة، في حين أن التابع الأول مبهم، فأنت ببساطة لا يمكنك استنباط أي البيانات التي يحتاجها التابع من كائن من صنف Customer للعمل حيث أنه يطلب الحصول على نسخة أو مرجع للكائن من نوع زبون. وبالتالي لا تعلم أي البيانات المجودة داخل هذا الكائن التي سوف يعتمد عليها في تقرير المسافة ربما يكون العنوان وقد يكون رمز المنطقة Postcode أو رمز الهاتف لتحديد المدينة أو...

قد يتبادر إلى ذهنك وما المشكلة في ذلك؟ لنفترض أنك تريد حساب المسافة لكل الزبائن المعروضين في جدول للزبائن الذين أجروا عملية شراء خلال الشهر الماضي في أحد واجهات لتطبيقك الجميل. طبعا الجدول لن يحتوي جميع معلومات الزبائن وإنما يعرض فقط بعض المعلومات عنهم. عندما تريد أن تحسب المسافة لزبون معين ستضطر عندما تستخدم التابع الأول إلى لتأمين معلومات الزبون كاملة من قاعدة البيانات قبل تمريرها، بينما التابع الثاني لا يتطلب منك سوى العنوان والذي في أغلب الظن قد يكون متوفر ولا تحتاج إلى الاستعلام عنه في قاعدة البيانات. على كل إن لم تقتنع فلا مشكلة فالسبب الثاني سيكون كفيل بتبيهك إلى أمر أكثر أهمية والذي ستخلص من خلاله إلى أن تصميم الكود الثاني هو الأفضل بلا منازع.

بالنسبة للسؤال الثاني،،
لنفترض بعد مدة من الزمن تم التعديل على الصنف Customer ليحتوي حقل جديد WorkAddress مالذي سوف يحدث؟! لن تكون قادرا على استخدام التابع الأول لحساب المسافة باستخدام الحقل الجديد WorkAddress. أليس كذلك؟! ومع ذلك إن ألححت بمقدرتك على استخدام التابع الأول سيتطلب منك تعديل التابع الأول حتى يتثنى لك حساب المسافة لكل من Address و WorkAddress. لن أتطرق إلى كيفية التعديل، إذا أنه ومع الشروع بالتعديل ستكتشف العديد من المشاكل الأخرى. حالة أخرى توضح مدى المشاكل التي يمكن أن تحصل فقط جراء سوء تصميم التابع. لنقل أننا أردنا استخدام التابع مع مشروع آخر أو مع صنف آخر مثل Student.Address ، ستطلب إجراء تعديلات. بينما لو استخدمنا التابع الثاني لن نواجه أي من المشاكل السابقة وعلى العكس ستشعر بمتعة حسن تصميم التابع. بالعودة للحالة الأولى WorkAddress، فقط بإمكانك استدعاء التابع وتمرير قيمة WorkAddress بدلا من Address. وكذلك الحال بالنسبة للصنف Student.

الخلاصة: ان التابع الثاني أفضل من التابع الأول فهو سهل الفهم وأيضا لا يتطلب عملية تعديل على أقل تقدير للحالات آنفة الذكر.
الرد }}}}
تم الشكر بواسطة: abulayth , myalsailamy , ابو ابراهيم
#2
كلام جميل و انتقاء رائع منك ،، أعجبني
اسم معرفي : محمد يحيى
الرد }}}}
تم الشكر بواسطة:


التنقل السريع :


يقوم بقرائة الموضوع: بالاضافة الى ( 1 ) ضيف كريم