الذي عقد (تصميم العقد) هو أفضل ؟

Question

لنفترض أن لدي طريقة

public Patient(int id)
{
    ----
}

أن يعود المريض كائن معين معرف..أنا يمكن تعريف عقد في 2 طرق

1. طريقة سيعود لاغية إذا كان المريض غير موجود
2. طريقة رمي استثناء إذا كان المريض لا وجود لها.في هذه الحالة أنا أيضا تحديد طريقة الاستعلام بإرجاع true إذا كان المريض موجودا في قاعدة بيانات كاذبة أو غير ذلك...

الذي عقد يجب استخدامها ؟ أي اقتراحات أخرى ؟

تحديث:يرجى التعليق على هذه القضية أيضا...إذا كان ذلك لا يشكل قاعدة بيانات تعيين معرف و هو شيء يقوم المستخدم بإدخاله في واجهة المستخدم..مثل SSN ..ثم واحد الذي هو أفضل..

تعليق حول Null نمط من ستيف التي أعتقد أنها صحيحة:ربما ليست فكرة جيدة هنا ، كما أنه سيكون من المفيد حقا أن تعرف على الفور عندما هوية لم تكن موجودة.

وأعتقد أيضا Null نمط هنا سيكون نوعا ما ثقيل الوزن

تعليق من روب ويلز على رمي استثناء بسبب سوء Id:لا أعتقد خطأ مطبعي في اسم المريض هو ظرف استثنائي" IMHO

Answer 1

نضع في اعتبارنا أن تسير "فوق السلك" إلى فئة أخرى (إذا كانت قاعدة بيانات أو خادم التطبيق) هي واحدة من أغلى الأنشطة التي يمكنك القيام بها - عادة شبكة الاتصال سوف يستغرق عدة أوامر من حجم أطول في الذاكرة المكالمات.

ولذلك يستحق هيكلة API الخاص بك لتجنب زائدة المكالمات.

النظر إذا API الخاص بك هو مثل هذا:

// Check to see if a given patient exists
public bool PatientExists(int id);

// Load the specified patient; throws exception if not found
public Patient GetPatient(int id);

ثم أنت من المحتمل أن تصل إلى قاعدة البيانات مرتين - أو أن يكون الاعتماد على حسن التخزين المؤقت لتجنب هذا.

وهناك اعتبار آخر هو:في بعض الأماكن التعليمات البرمجية الخاصة بك قد يكون "معروفة جيدا" id, في أماكن أخرى لا.يتطلب كل موقع مختلف السياسة بشأن ما إذا كان ينبغي استثناء القيت.

هنا هو النمط الذي كنت تستخدم تأثير جيد في الماضي - قد طريقتين:

// Load the specified patient; throws exception if not found
public Patient GetExistingPatient(int id);

// Search for the specified patient; returns null if not found
public Patient FindPatient(int id);

ومن الواضح GetExistingPatient() يمكن أن يبنى من خلال الاتصال FindPatient().

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

Answer 2

خيار آخر سيكون Null كائن نمط.

Answer 3

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

تحرير: إذا كنت تفعل شيئا غير صحيح على أساس استرجاع مثل البحث على أساس النص ، ثم العودة null على ما يرام.خصوصا في هذه القضية التي تعود إلى مجموعة من النتائج التي يمكن أن يكون أكثر من واحد (أكثر من مريض واحد مع نفس الاسم ونفس تاريخ الميلاد أو ما المعايير).

وظيفة البحث يجب أن يكون عقد مختلف من استرجاع وظيفة.

Answer 4

ذلك يعتمد:

إذا كنت تعتبر عملية طبيعية تؤدي إلى pation عدد غير مطابقة ملف DB ثم فارغة (NULL) سجل يجب أن تعاد.

ولكن إذا كنت تتوقع أن هوية معينة ينبغي دائما رقما قياسيا ثم عندما لم يتم العثور على (التي ينبغي أن تكون نادرة) ثم استخدام استثناء.

أشياء أخرى مثل DB خطأ في الاتصال ينبغي أن تولد استثناء.
كما كنت تتوقع في الحالات العادية الاستعلام إلى DB للعمل دائما (على الرغم من أنه قد يعود 0 السجلات أو لا).

P. S. وأود أن لا عودة مؤشر.(من يملك المؤشر??)
وأود أن العودة كائن التي قد أو قد لا يكون لديك سجل.ولكن يمكنك interogated على استمرارية السجل خلال.ويحتمل أن تكون مؤشر الذكية أو شيء قليلا أكثر ذكاء من مؤشر الذكية التي تفهم cotext.

Answer 5

من أجل هذا الظرف سيكون لدي طريقة العودة فارغة غير موجودة المريض.

أنا أميل إلى تفضيل استخدام الاستثناءات لمساعدة graeful تدهور عندما يكون هناك مشكلة مع النظام نفسه.

في هذه الحالة, فمن mosdt على الأرجح:

1. خطأ مطبعي في المريض معرف إذا كان إدخالها في نموذج البحث ،
2. وجود خطأ في إدخال البيانات ، أو
3. سير عمل هذه المسألة في أنه سجل المريض لم دخل بعد.

ومن ثم العودة فارغة بدلا من استثناء.

إذا كان هناك مشكلة في الاتصال بقاعدة البيانات ، ثم أن لدي طريقة رفع استثناء.

تحرير: فقط رأيت أن المريض ID في التوقيع كان صحيحا ، وذلك بفضل ستيفن لوي ، حتى لقد صححت قائمة من الأسباب.

بلدي النقطة الأساسية حول تحديد متى يمكن استخدام الاستثناءات (على أخطاء النظام) مقابل غيرها من أساليب إرجاع خطأ (بسيطة إدخال البيانات الأخطاء المطبعية) لا يزال قائما على الرغم من.IMHO.

HTH

الهتافات ،

روب

Answer 6

في حالة بسيطة مثل هذا 1.يبدو أن تكون أكثر من كافية.قد تحتاج إلى تنفيذ شيء مثل طريقة الاستدعاء الذي يدعو العميل أن أعرف لماذا عادت فارغة.مجرد اقتراح.

Answer 7

اتخاذ الخاص بك descriptiong في ظاهرها ، ربما تحتاج إلى كل من:

• سيئة معرفات الأخطاء/استثناءات ، كما آدم أشار ولكن
• إذا كان يتم منحك معرفات في أماكن أخرى قد اختفت, سوف تحتاج إلى طريقة الاستعلام للتحقق منها

Answer 8

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

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

Answer 9

رمي استثناء.

إذا كنت إرجاع null, رمز مثل هذا:

Console.WriteLine(Patient(id).Name);

سوف تفشل مع NullReferenceException إذا كان معرف لا وجود لها ، وهي ليست مفيدة كما يقول PatientNotFoundException(id).في هذا المثال, فإنه لا يزال من السهل نسبيا أن تعقب ، ولكن النظر:

somePatient = Patient(id)

// much later, in a different function:

Console.WriteLine(somePatient);

حول إضافة دالة التحقق من ما إذا كان المريض موجودا:ملاحظة هذا لن يمنع PatientNotFoundExceptions تماما.على سبيل المثال:

if (PatientExists(id))
    Console.WriteLine(Patient(id).Name);

-- موضوع آخر أو عملية أخرى يمكن حذف المريض بين المكالمات PatientExists والمريض.أيضا هذا يعني اثنين استعلامات قاعدة البيانات بدلا من واحدة.عادة, ومن الأفضل أن مجرد محاولة الاتصال و التعامل مع الاستثناء.

علما أن الوضع يختلف بالنسبة إلى الاستفسارات التي ترجع قيم متعددة مثلباعتبارها القائمة ؛ هنا كان من المناسب أن عودة قائمة فارغة إذا كان هناك أي تطابق.