1. يجب أن يكون الحرف الأول من اسم الفئة كبيرًا. يجب أن يكون الحرف الأول من الحقول والأساليب والكائنات (المقابض) صغيرًا. كما هو الحال مع جميع المعرفات، يجب أن تكون جميع الكلمات الموجودة بداخلها قريبة من بعضها البعض، مع كتابة الحرف الأول من الكلمة المتداخلة بأحرف كبيرة. على سبيل المثال:
انسخ الكود كما يلي: ThisIsAClassName
thisIsMethodOrFieldName
إذا ظهر حرف مُهيئ ثابت في التعريف، فاكتب جميع الحروف في معرف النوع الأساسي النهائي الثابت. سيؤدي هذا إلى وضع علامة عليها كثوابت وقت الترجمة.
تعتبر حزم Java حالة خاصة: فهي كلها بأحرف صغيرة، حتى الكلمات الوسطى. بالنسبة لأسماء امتدادات أسماء النطاقات، مثل com أو org أو net أو edu وما إلى ذلك، يجب أن تكون جميعها بأحرف صغيرة (وهذا أيضًا أحد الاختلافات بين Java 1.1 وJava 1.2).
2. عند إنشاء فصل دراسي للاستخدام العام، يرجى اعتماد "النموذج الكلاسيكي" وإدراج تعريفات العناصر التالية:
انسخ رمز الكود كما يلي:
يساوي ()
رمز التجزئة ()
إلى سلسلة ()
استنساخ () (تنفيذ قابل للاستنساخ)
تنفيذ قابل للتسلسل
3. لكل فئة تقوم بإنشائها، فكر في وضع main()، الذي يحتوي على الكود الخاص باختبار تلك الفئة. لاستخدام فئات من المشروع، ليس علينا حذف رمز الاختبار. إذا تم إجراء تغييرات من أي نوع، فمن السهل العودة إلى الاختبار. يعمل الكود أيضًا كمثال لكيفية استخدام الفئات.
4. ينبغي تصميم الطريقة في وحدة وظيفية موجزة، يمكن استخدامها لوصف وتنفيذ جزء من واجهة الفئة غير المتصلة. ومن الناحية المثالية، ينبغي أن يكون النهج موجزا ومباشرا. إذا كان الطول كبيرًا، فكر في تقسيمه إلى أجزاء أقصر بطريقة ما. يؤدي القيام بذلك أيضًا إلى تسهيل إعادة استخدام التعليمات البرمجية داخل الفصل (في بعض الأحيان، يجب أن تكون الأساليب كبيرة جدًا، لكن يجب عليها أن تفعل الشيء نفسه فقط).
5. عند تصميم فصل دراسي، يرجى وضع نفسك مكان مبرمج العميل (يجب أن تكون طريقة استخدام الفصل واضحة جدًا). بعد ذلك، ضع نفسك مكان الشخص الذي يدير الكود (توقع أنواع التغييرات التي من المحتمل إجراؤها، وفكر في طرق لجعلها أكثر بساطة).
6. اجعل الفصل قصيرًا ومختصرًا قدر الإمكان، وقم بحل مشكلة محددة فقط. فيما يلي بعض الاقتراحات لتصميم الفصل:
1. بيان التبديل المعقد: فكر في استخدام آلية "متعددة الأشكال".
2. يتضمن عدد كبير من الأساليب عمليات ذات أنواع مختلفة إلى حد كبير: فكر في استخدام عدة فئات لتنفيذها بشكل منفصل.
3. العديد من متغيرات الأعضاء لها خصائص مختلفة جدًا: فكر في استخدام عدة فئات
7. اجعل كل شيء "خاصًا" قدر الإمكان. يمكنك جعل جزء من المكتبة "عامًا" (طريقة، فئة، حقل، وما إلى ذلك) بحيث لا يمكن إزالته أبدًا. إذا قمت بإجبارها على الخروج، فقد يؤدي ذلك إلى تدمير التعليمات البرمجية الموجودة لأشخاص آخرين، مما يجبرهم على إعادة كتابتها وتصميمها. إذا قمت بنشر ما يجب عليك نشره فقط، فلا تتردد في تغيير أي شيء آخر. في البيئات متعددة الخيوط، تعد الخصوصية عاملاً مهمًا بشكل خاص. يمكن حماية الحقول الخاصة فقط من الاستخدام غير المتزامن.
8. احذر من "متلازمة الأجسام العملاقة". بالنسبة لبعض المبتدئين الذين اعتادوا على التفكير في البرمجة التسلسلية والذين هم جدد في مجال OOP، غالبًا ما يرغبون في كتابة برنامج تنفيذ متسلسل أولاً، ثم تضمينه في كائن أو كائنين ضخمين. وفقا لمبادئ البرمجة، يجب أن تعبر الكائنات عن مفهوم التطبيق، وليس التطبيق نفسه.
9. إذا كان عليك القيام ببعض البرمجة القبيحة، فيجب عليك على الأقل وضع الكود داخل الفصل الدراسي.
10. عندما تجد أن الفئات متكاملة بشكل وثيق، فأنت بحاجة إلى التفكير فيما إذا كنت تريد استخدام الفئات الداخلية لتحسين أعمال الترميز والصيانة (راجع "تحسين التعليمات البرمجية باستخدام الفئات الداخلية" في الفصل 14، القسم 14.1.2).
11. قم بإضافة التعليقات بعناية قدر الإمكان واستخدم صيغة مستند التعليق javadoc لإنشاء وثائق البرنامج الخاصة بك.
12. تجنب استخدام "الأرقام السحرية" حيث يصعب توافق هذه الأرقام بشكل جيد مع الكود. إذا كنت بحاجة إلى تعديله في المستقبل، فسيصبح بلا شك كابوسًا، لأنه ليس لديك أي فكرة عما إذا كان "100" يشير إلى "حجم المصفوفة" أو "شيء آخر تمامًا". لذلك، يجب علينا إنشاء ثابت، وإعطائه اسمًا وصفيًا مقنعًا، واستخدام المعرفات الثابتة في جميع أنحاء البرنامج. وهذا يجعل البرنامج أسهل في الفهم والصيانة.
13. عندما يتعلق الأمر بالمنشئين والاستثناءات، فأنت عادةً تريد إعادة طرح أي استثناء تم اكتشافه في المنشئ إذا تسبب في فشل إنشاء ذلك الكائن. بهذه الطريقة لن يستمر المتصل في التفكير بشكل أعمى بأن الكائن قد تم إنشاؤه بشكل صحيح.
14. بعد انتهاء مبرمج العميل من استخدام الكائن، إذا كان فصلك يتطلب أي عمل تنظيف، ففكر في وضع كود التنظيف بطريقة محددة جيدًا، باستخدام اسم مثل cleanup() للإشارة بوضوح إلى استخدامك. بالإضافة إلى ذلك، يمكن وضع علامة منطقية داخل الفئة للإشارة إلى ما إذا كان الكائن قد تم مسحه أم لا. في طريقة Finalize() الخاصة بالفئة، تأكد من مسح الكائن وتجاهل الفئة التي ترث من RuntimeException (إذا لم تكن قد تم تجاهلها بالفعل)، مما يشير إلى وجود خطأ في البرمجة. قبل اتخاذ حل كهذا، تأكد من أن Finalize() يعمل على نظامك (قد تحتاج إلى الاتصال System.runFinalizersOnExit(true) للتأكد من هذا السلوك).
15. في نطاق معين، إذا كان هناك حاجة إلى مسح كائن (لم تتم معالجته بواسطة آلية جمع البيانات المهملة)، فيرجى استخدام الطريقة التالية: تهيئة الكائن، إذا نجحت، أدخل على الفور كتلة محاولة تحتوي على جملة أخيرًا لبدء عمل التنظيف .
16. إذا كنت بحاجة إلى تجاوز (إلغاء) Finalize() أثناء عملية التهيئة، فيرجى تذكر استدعاء super.finalize() (إذا كان الكائن ينتمي إلى فئتنا الفائقة المباشرة، فهذا ليس ضروريًا). في عملية تجاوز Finalize()، يجب أن يكون استدعاء super.finalize() هو الإجراء الأخير، وليس الإجراء الأول، للتأكد من أن مكونات الفئة الأساسية لا تزال صالحة عند الحاجة إليها.
17. عند إنشاء مجموعات كائنات ذات حجم ثابت، قم بنقلها إلى مصفوفة (خاصة إذا كنت تخطط لإرجاع هذه المجموعة من إحدى الطرق). بهذه الطريقة، يمكننا الاستمتاع بفوائد التحقق من نوع المصفوفة في وقت الترجمة. علاوة على ذلك، قد لا يحتاج مستلم المصفوفة إلى "إرسال" الكائن إلى المصفوفة حتى يتمكن من استخدامها.
18. حاول استخدام الواجهات بدلاً من الفئات المجردة. إذا كنت تعلم أن شيئًا ما سيكون فئة أساسية، فيجب أن يكون خيارك الأول هو تحويله إلى واجهة. فقط عندما يتعين عليك استخدام تعريفات الأساليب أو متغيرات الأعضاء، فأنت بحاجة إلى تحويلها إلى فئة مجردة. تصف الواجهة أساسًا ما يريد العميل القيام به، بينما يتم تخصيص الفصل (أو السماح) بتفاصيل تنفيذ محددة.
19. داخل البناء، قم فقط بالعمل المطلوب لوضع الجسم في الحالة الصحيحة. كلما أمكن، تجنب استدعاء أساليب أخرى، حيث قد يتم تجاوز هذه الأساليب أو إلغاؤها من قبل الآخرين، مما يؤدي إلى نتائج غير متوقعة أثناء عملية الإنشاء (انظر الفصل 7 للحصول على التفاصيل).
20. لا ينبغي للأشياء أن تحتوي على بعض البيانات فحسب؛ بل ينبغي أيضًا أن يكون سلوكها محددًا جيدًا.
21. عند إنشاء فصل دراسي جديد بناءً على فصل موجود، يرجى أولاً تحديد "جديد" أو "إنشاء". يجب أن تؤخذ هذه المشكلة في الاعتبار فقط إذا كانت متطلبات التصميم الخاصة بك يجب أن تكون موروثة. إذا تم استخدام الميراث حيث يُسمح بإنشاء جديد، يصبح التصميم بأكمله معقدًا بشكل غير ضروري.
22. استخدام الوراثة وتغطية الطريقة للتعبير عن الفرق بين السلوكيات، واستخدام الحقول للتعبير عن الفرق بين الحالات. أحد الأمثلة المتطرفة للغاية هو تمثيل الألوان من خلال الوراثة من فئات مختلفة، وهو ما يجب تجنبه بالتأكيد: استخدم حقل "اللون" مباشرة.
23. لتجنب حدوث مشكلات عند البرمجة، يرجى التأكد من أن كل اسم يتوافق مع فصل واحد فقط أينما يشير مسار الفصل الخاص بك. وإلا، فقد يقوم المترجم أولاً بالعثور على فئة أخرى بنفس الاسم والإبلاغ عن رسالة خطأ. إذا كنت تشك في أنك واجهت مشكلة في مسار الفصل الدراسي، فيرجى محاولة البحث عن ملف .class يحمل نفس الاسم عند كل نقطة بداية لمسار الفصل الدراسي.
24. عند استخدام "محولات" الأحداث في Java 1.1 AWT، فمن السهل مواجهة فخ. إذا تم تجاوز أسلوب محول ولم تكن طريقة التهجئة محددة بشكل خاص، فستكون النتيجة النهائية هي إضافة طريقة جديدة بدلاً من تجاوز الطريقة الحالية. ومع ذلك، نظرًا لأن هذا قانوني تمامًا، فلن تتلقى أي رسائل خطأ من المترجم أو نظام وقت التشغيل، ولكن التعليمات البرمجية الخاصة بك سوف تتصرف بشكل غير صحيح.
25. استخدم حلول تصميم معقولة للتخلص من "الوظائف الزائفة". أي، إذا كنت تحتاج فقط إلى إنشاء كائن واحد من الفئة، فلا تقصر نفسك على التطبيق مقدمًا وأضف تعليقًا "أنشئ واحدًا منهم فقط". يرجى النظر في تغليفه في نموذج "تابع فقط". إذا كان لديك الكثير من التعليمات البرمجية المتناثرة في البرنامج الرئيسي الذي يتم استخدامه لإنشاء كائناتك الخاصة، ففكر في اعتماد حل إبداعي لتغليف هذا الرمز.
26. كن حذرًا من "الشلل الناتج عن التحليل". تذكر، مهما كان الأمر، فأنت بحاجة إلى فهم حالة المشروع بأكمله مقدمًا ثم فحص التفاصيل. نظرًا لأنه لديك فهم للوضع العام، يمكنك التعرف بسرعة على بعض العوامل غير المعروفة ومنع نفسك من الوقوع في "المنطق الميت" عند فحص التفاصيل.
27. كن حذرًا من "التحسين المبكر". اجعله يعمل أولاً، وفكر في زيادة السرعة لاحقًا، ولكن قم بتحسينه فقط إذا كان عليك ذلك وإذا ثبت أن هناك اختناقًا في الأداء في جزء ما من التعليمات البرمجية. ما لم تستخدم أدوات متخصصة لتحليل الاختناقات، فمن المحتمل أنك تضيع وقتك. التكلفة الضمنية لتحسينات الأداء هي أن التعليمات البرمجية الخاصة بك تصبح أكثر صعوبة في الفهم ويصعب صيانتها.
28. تذكر أنك تقضي وقتًا أطول في قراءة التعليمات البرمجية مقارنة بكتابتها. يؤدي التصميم الواضح إلى برنامج سهل الفهم، ولكن التعليقات والتفسيرات الدقيقة وبعض الأمثلة غالبًا ما تكون لا تقدر بثمن. إنها مهمة جدًا لك ولأولئك الذين يتابعونك. إذا كنت لا تزال تشك في ذلك، فما عليك إلا أن تتخيل إحباطك أثناء محاولتك العثور على معلومات مفيدة في وثائق Java عبر الإنترنت، وقد تقتنع بذلك.
29. إذا كنت تعتقد أنك قمت بتحليل أو تصميم أو تنفيذ جيد، يرجى تغيير منظور تفكيرك قليلاً. حاول دعوة بعض الغرباء، وليس بالضرورة خبراء، ولكن أشخاصًا من أجزاء أخرى من الشركة. اطلب منهم أن ينظروا إلى عملك بعيون جديدة تمامًا ويروا ما إذا كان بإمكانهم اكتشاف المشكلات التي كنت أعمى عنها. من خلال اعتماد هذه الطريقة، يمكننا غالبًا تحديد بعض المشكلات الرئيسية في المرحلة الأكثر ملاءمة للتعديل، وتجنب هدر المال والطاقة الناتج عن حل المشكلات بعد إصدار المنتج.
30. التصميم الجيد يمكن أن يحقق أكبر العوائد. باختصار، غالبًا ما يستغرق الأمر وقتًا طويلاً للعثور على الحل الأنسب لمشكلة معينة. ولكن بمجرد العثور على الطريقة الصحيحة، سيكون عملك المستقبلي أسهل بكثير، ولن تضطر إلى تحمل ساعات أو أيام أو أشهر من النضال المؤلم. إن عملنا الجاد سيجلب أعظم المكافآت (حتى التي لا تقدر بثمن). ولأنني بذلت الكثير من الجهد في ذلك، فقد حصلت أخيرًا على خطة تصميم ممتازة، كما أن لذة النجاح مثيرة أيضًا. قاوم إغراء التسرع في إنجاز العمل، والذي غالبًا ما لا يستحق كل هذا الجهد.