1. نظرة عامة
يوجد مفتاح التأكيد في لغات C وC++، وهو ما يعني التأكيد.
في Java، هناك أيضًا الكلمة الأساسية تأكيد، مما يعني التأكيد، الاستخدام والمعنى متشابهان.
2. القواعد
في Java، تم تقديم الكلمة الأساسية التأكيد من JAVA SE 1.4 لتجنب الأخطاء الناجمة عن استخدام الكلمة الأساسية التأكيد في الإصدارات الأقدم من كود Java، لا تقوم Java بتمكين التحقق من التأكيد بشكل افتراضي عند التنفيذ (في هذا الوقت، سيتم تفعيل جميع عبارات التأكيد). سيتم تجاهلها!) ، إذا كنت تريد تمكين التحقق من التأكيد، فأنت بحاجة إلى تشغيله باستخدام المفتاح -enableassertions أو -ea.
إن بناء جملة الكلمة الأساسية تأكيد بسيط جدًا وله استخدامان:
1. تأكيد <التعبير المنطقي>
إذا كان <التعبير المنطقي> صحيحًا، فسيستمر تنفيذ البرنامج.
إذا كان الخطأ خطأ، فسيقوم البرنامج بطرح خطأ AssertionError وينهي التنفيذ.
2. تأكيد <التعبير المنطقي>: <تعبير رسالة الخطأ>
إذا كان <التعبير المنطقي> صحيحًا، فسيستمر تنفيذ البرنامج.
إذا كانت خاطئة، فسيقوم البرنامج بطرح java.lang.AssertionError وإدخال <تعبير رسالة الخطأ>.
3. أمثلة التطبيق
ويرد أدناه مثال لتوضيح استخدامه:
انسخ رمز الكود كما يلي:
الطبقة العامة AssertFoo {
public static void main(String args[]) {
// نتيجة التأكيد 1 صحيحة، ثم تابع التنفيذ.
تأكيد صحيح؛
System.out.println("لا توجد مشكلة في التأكيد 1، انطلق!");
System.out.println("/n-----------------/n");
// نتيجة التأكيد 2 خاطئة وينتهي البرنامج
تأكيد خطأ: "فشل التأكيد، سيتم إخراج معلومات هذا التعبير عند طرح استثناء!";
System.out.println("لا توجد مشكلة في التأكيد 2، انطلق!");
}
}
احفظ الكود في C:/AssertFoo.java، ثم قم بتنفيذه كما يلي واعرض مخرجات وحدة التحكم:
1. تجميع البرنامج:
ج:/>javac AssertFoo.java
2. يتم تنفيذ البرنامج بشكل افتراضي دون تشغيل المفتاح -ea:
ج:/>جافا AssertFoo
التأكيد 1 على ما يرام، انطلق!
------------------
التأكيد 2 لا توجد مشكلة، اذهب!
3. قم بتشغيل المفتاح -ea وقم بتنفيذ البرنامج:
C:/>java -ea AssertFoo
التأكيد 1 على ما يرام، انطلق!
------------------
استثناء في مؤشر الترابط "الرئيسي" java.lang.AssertionError: فشل التأكيد، سيتم حذف معلومات هذا التعبير
سيتم الإخراج عند طرح استثناء!
في AssertFoo.main (AssertFoo.java:10)
4. الفخ
الكلمة الأساسية تأكيد سهلة الاستخدام، ولكن استخدام التأكيد غالبًا ما يجعلك تقع في فخ أعمق وأعمق. ينبغي تجنبه. وبعد البحث لخص المؤلف الأسباب التالية:
1. يجب تمكين الكلمة الأساسية التأكيد بشكل صريح في وقت التشغيل حتى تصبح سارية المفعول، وإلا فإن تأكيدك سيكون بلا معنى. في الوقت الحالي، لا تعمل أدوات Java IDE السائدة على تمكين وظيفة التحقق من التأكيد -ea افتراضيًا. هذا يعني أنه إذا كنت تستخدم أدوات IDE للبرمجة، فسوف تواجه بعض المشاكل عند تصحيح الأخطاء والتشغيل. علاوة على ذلك، بالنسبة لتطبيقات Java Web، يتم نشر رمز البرنامج في الحاوية، ولا يمكنك التحكم مباشرة في تشغيل البرنامج. إذا كان يجب عليك تشغيل المفتاح -ea، فستحتاج إلى تغيير معلمات التكوين قيد التشغيل لحاوية الويب. وهذا يجلب إزعاجًا كبيرًا لزرع البرامج ونشرها.
2. استخدام التأكيد بدلاً من if هو الفخ الثاني. حكم التأكيد مشابه لحكم عبارة if، لكن وظائف الاثنين مختلفة بشكل أساسي: الكلمة الأساسية تأكيد مخصصة للاستخدام عند اختبار البرنامج وتصحيح أخطاءه، ولكن إذا استخدمت التأكيد عن طريق الخطأ للتحكم في عملية الأعمال للبرنامج البرنامج، لن يتم استخدامه أثناء الاختبار والتصحيح، وإزالة الكلمة الأساسية تأكيد بعد الانتهاء يعني تعديل المنطق العادي للبرنامج.
3. في حالة فشل تأكيد التأكيد، سيخرج البرنامج. لن يتم التسامح مع هذا في بيئة الإنتاج. يتم حل الأخطاء المحتملة في البرنامج بشكل عام من خلال معالجة الاستثناءات. لكن استخدام التأكيدات أمر خطير للغاية، وبمجرد فشله، سيتعطل النظام.
5. أفكار حول التأكيد
نظرًا لأن التأكيد مخصص لتصحيح أخطاء برامج الاختبار وليس للاستخدام في بيئات الإنتاج الرسمية، فيجب عليك التفكير في اختبار JUint بشكل أفضل لاستبدال وظيفته، حيث يوفر JUint وظائف رئيسية أكثر من التأكيد. بالطبع، يمكن إجراء التصحيح والاختبار من خلال تصحيح IDE. ومن وجهة النظر هذه، فإن مستقبل التأكيد قاتم.
لذلك، يجب عليك تجنب استخدام الكلمة الأساسية تأكيد في Java، ما لم تدعم Java يومًا ما المفتاح -ea افتراضيًا، فيمكنك التفكير في ذلك. قارن بين مقدار الفائدة ومقدار المتاعب التي يمكن أن يجلبها لك التأكيد. هذا هو المبدأ الذي يجب أن نختاره من عدمه.
================================================================================================== ==========
تعليق:
من ناحية أخرى، في بعض المكونات مفتوحة المصدر، مثل أداة التحقق من الصحة وJunit، يبدو أن عملية الحكم تستخدم أسلوب التأكيد. ومن المحتمل جدًا استخدام عدد كبير من التأكيدات، لكن المؤلف لا يمكنه التأكد قبل النظر في الأمر كود المصدر.
إذا كان اختبارًا بسيطًا أثناء مرحلة التطوير، فإن junit أداة مريحة وقوية، فلا يوجد سبب لعدم استخدامه عند كتابة التأكيدات الخاصة بك.
================================================================================================== ==========
تعليق:
أولاً يمكن استخدامه في رمز اختبار الوحدة. Junit متطفل للغاية. إذا كان هناك عدد كبير من التعليمات البرمجية في المشروع بأكمله يستخدم Junit، فسيكون من الصعب إزالته أو اختيار إطار عمل آخر. إذا كان هناك الكثير من رموز اختبار الوحدة وتريد إعادة استخدام حالات اختبار الوحدة هذه، فيجب عليك اختيار التأكيد بدلاً من junit لتسهيل استخدام أطر عمل اختبار الوحدة الأخرى، مثل TestNG. لنفس السبب، يجب ألا يظهر Junit في التعليمات البرمجية الوظيفية الرسمية على الإطلاق، ويجب استخدام التأكيد.
التأكيد مناسب بشكل أساسي للفئات الأساسية، وفئات الإطار، وفئات الواجهة، وفئات التعليمات البرمجية الأساسية، وفئات الأدوات. بمعنى آخر، من الضروري استخدامه عندما يكون المتصل بالرمز الخاص بك هو رمز عمل مكتوب بواسطة مبرمج آخر، أو نظام فرعي آخر. على سبيل المثال، إذا قمت بإجراء خوارزمية الفرز السريع
انسخ رمز الكود كما يلي:
قائمة ثابتة عامة<int> QuickSort(List<int> list){
قائمة التأكيد! = فارغة؛
// تقدم بطلب للحصول على مساحة مؤقتة
//ابدأ الفرز
ل(int أنا: قائمة){
//
}
}
في هذه الحالة، إذا لم يتم التحقق من صحة المعلمات الواردة، فسيتم طرح خطأ مؤشر فارغ لا يمكن تفسيره. قد لا يعرف المتصلون بك تفاصيل التعليمات البرمجية الخاصة بك، كما أن تصحيح خطأ المؤشر الفارغ في النظام يعد مضيعة للوقت. يجب عليك إخبار المتصل بشكل مباشر وواضح بوجود مشكلة في المعلمات التي تم تمريرها. وإلا فإنه سوف يشك في أن الكود الخاص بك به خطأ. يمكن أن يؤدي استخدام التأكيد إلى منع اثنين من المبرمجين من إلقاء اللوم على بعضهما البعض بسبب مشاكل في الكود الذي كتبوه.
ينطبق التأكيد على الأخطاء التي تعرف بالضبط ما هو الخطأ، وقد اتفقت أنت والمتصل بك على أنه يجب على المتصل الخاص بك إزالة الأخطاء أو التحقق من وجودها. تخبر المتصل الخاص بك عن طريق التأكيد. لا ينطبق التأكيد على الأخطاء التي تسببها الأنظمة الخارجية، مثل الأخطاء في بيانات إدخال المستخدم أو أخطاء التنسيق في ملف خارجي. لا تنتج هذه الأخطاء عن المتصل بك بل عن المستخدم، وهي ليست حتى استثناءات، لأن أخطاء الإدخال وأخطاء تنسيق الملف شائعة، ويجب التحقق من هذه الأخطاء بواسطة رمز العمل.
يعد التأكيد أكثر ملاءمة للفئات الأساسية التي يتم استدعاؤها بشكل متكرر، ورمز إطار العمل، وفئات الأدوات، والرمز الأساسي، ورمز الواجهة، ولهذا السبب تتم إزالته في وقت التشغيل. يجب أن يقوم رمز الاختبار بتمكين المعلمة -ea أثناء مرحلة الاختبار لتسهيل الاختبار الدقيق للكود الأساسي في عمق النظام.
السبب وراء استخدام Java للتأكيد بشكل أقل هو أن Java لديها نظام OO كامل جدًا وأن تحويل النوع القسري يحدث بشكل أقل تكرارًا، لذلك ليست هناك حاجة للتحقق بشكل متكرر مما إذا كان نوع المؤشر صحيحًا وما إذا كان المؤشر فارغًا مثل C. في الوقت نفسه، نادرًا ما تدير Java الذاكرة أو المخازن المؤقتة بشكل مباشر، لذلك ليست هناك حاجة للتحقق بشكل متكرر مما إذا كان المخزن المؤقت الوارد فارغًا أو تجاوز الحدود.
لكن استخدام التأكيد بشكل جيد يمكن أن يساعد في تحسين صحة كود إطار العمل وتقليل وقت تصحيح الأخطاء لمستخدمي كود إطار العمل.
================================================================================================== =============
تعليق:
الغرض من التأكيد هو السماح للمبرمجين باكتشاف الأخطاء المنطقية الخاصة بهم بسهولة دون التأثير على كفاءة البرنامج. يجب ألا تحدث الأخطاء التي تم العثور عليها بواسطة التأكيد على الإطلاق ولا يمكن استبدالها بالاستثناءات. الاستثناءات مسموح بها من قبل النظام، أو هي "أخطاء" لا يمكن للنظام السيطرة عليها، وهي ليست مشاكل منطقية للمبرمج.
يجب تشغيل التأكيد أثناء التطوير وإيقاف تشغيله بعد الإصدار.