1. ตัวอักษรตัวแรกของชื่อชั้นเรียนควรเป็นตัวพิมพ์ใหญ่ ตัวอักษรตัวแรกของเขตข้อมูล วิธีการ และวัตถุ (หมายเลขอ้างอิง) ควรเป็นตัวพิมพ์เล็ก เช่นเดียวกับตัวระบุทั้งหมด คำทั้งหมดที่อยู่ในนั้นควรอยู่ใกล้กัน โดยให้อักษรตัวแรกของคำที่แทรกแซงขึ้นต้นด้วยตัวพิมพ์ใหญ่ ตัวอย่างเช่น:
คัดลอกรหัสดังต่อไปนี้: ThisIsAClassName
thisIsMethodOrFieldName
ถ้าอักขระตัวเริ่มต้นคงที่ปรากฏในคำจำกัดความ ให้ทำให้ตัวอักษรทั้งหมดเป็นตัวพิมพ์ใหญ่ในตัวระบุประเภทพื้นฐานขั้นสุดท้ายแบบคงที่ สิ่งนี้จะทำเครื่องหมายว่าเป็นค่าคงที่เวลาคอมไพล์
แพ็คเกจ Java เป็นกรณีพิเศษ: แพ็คเกจทั้งหมดเป็นตัวพิมพ์เล็ก แม้แต่คำกลางก็ตาม สำหรับชื่อนามสกุลโดเมน เช่น com, org, net หรือ edu ฯลฯ ทั้งหมดควรเป็นตัวพิมพ์เล็ก (นี่คือหนึ่งในความแตกต่างระหว่าง Java 1.1 และ Java 1.2)
2. เมื่อสร้างคลาสสำหรับการใช้งานทั่วไป โปรดใช้ "รูปแบบคลาสสิก" และรวมคำจำกัดความขององค์ประกอบต่อไปนี้:
คัดลอกรหัสรหัสดังต่อไปนี้:
เท่ากับ()
แฮชโค้ด()
toString()
โคลน () (ปรับใช้ Cloneable)
ใช้ Serializable
3. สำหรับแต่ละคลาสที่คุณสร้าง ให้ลองวาง main() ซึ่งมีโค้ดสำหรับทดสอบคลาสนั้น หากต้องการใช้คลาสจากโปรเจ็กต์ เราไม่จำเป็นต้องลบโค้ดทดสอบ หากมีการเปลี่ยนแปลงใดๆ ก็สามารถกลับไปทดสอบได้อย่างง่ายดาย รหัสนี้ยังทำหน้าที่เป็นตัวอย่างวิธีใช้คลาสอีกด้วย
4. วิธีการควรได้รับการออกแบบให้เป็นหน่วยการทำงานแบบย่อ ซึ่งสามารถใช้เพื่ออธิบายและดำเนินการส่วนอินเทอร์เฟซคลาสที่ไม่ต่อเนื่อง ตามหลักการแล้ว แนวทางควรกระชับและตรงประเด็น หากมีความยาวมาก ให้พิจารณาแบ่งออกเป็นชิ้นสั้นลงด้วยวิธีใดวิธีหนึ่ง การทำเช่นนี้ยังอำนวยความสะดวกในการใช้โค้ดซ้ำภายในคลาส (บางครั้งเมธอดต้องมีขนาดใหญ่มาก แต่ก็ควรทำในสิ่งเดียวกันเท่านั้น)
5. เมื่อออกแบบคลาส โปรดสวมบทบาทของไคลเอ็นต์โปรแกรมเมอร์ (วิธีการใช้คลาสควรมีความชัดเจนมาก) จากนั้น ลองสวมบทบาทของบุคคลที่จัดการโค้ด (คาดการณ์ว่าการเปลี่ยนแปลงประเภทใดมีแนวโน้มที่จะเกิดขึ้น และคิดถึงวิธีที่จะทำให้การเปลี่ยนแปลงง่ายขึ้น)
6. ทำให้ชั้นเรียนสั้นและกระชับที่สุดเท่าที่จะเป็นไปได้ และแก้ปัญหาเฉพาะปัญหาเท่านั้น ต่อไปนี้เป็นคำแนะนำสำหรับการออกแบบชั้นเรียน:
1. คำสั่งสวิตช์ที่ซับซ้อน: พิจารณาใช้กลไก "polymorphic"
2. วิธีการจำนวนมากเกี่ยวข้องกับการดำเนินการที่มีประเภทที่แตกต่างกันอย่างมาก: พิจารณาใช้หลายคลาสเพื่อนำไปใช้แยกกัน
3. ตัวแปรสมาชิกจำนวนมากมีลักษณะที่แตกต่างกันมาก: พิจารณาใช้หลายคลาส
7. ทำให้ทุกอย่างเป็น "ส่วนตัว" มากที่สุด คุณสามารถกำหนดให้ส่วนหนึ่งของไลบรารีเป็นแบบ "สาธารณะ" ได้ (เมธอด คลาส ฟิลด์ ฯลฯ) เพื่อไม่ให้ถูกนำออกไป หากคุณบังคับมันออกไป มันอาจทำลายโค้ดที่มีอยู่ของผู้อื่น บังคับให้พวกเขาเขียนใหม่และออกแบบมัน หากคุณเผยแพร่เฉพาะสิ่งที่คุณต้องเผยแพร่ คุณสามารถเปลี่ยนแปลงสิ่งอื่นได้ตามต้องการ ในสภาพแวดล้อมแบบมัลติเธรด ความเป็นส่วนตัวเป็นปัจจัยสำคัญอย่างยิ่งเท่านั้นที่สามารถป้องกันการใช้งานที่ไม่ซิงโครไนซ์ได้
8. ระวัง “อาการวัตถุยักษ์” สำหรับมือใหม่บางคนที่คุ้นเคยกับการคิดการเขียนโปรแกรมตามลำดับและยังใหม่กับสาขา OOP พวกเขามักจะชอบเขียนโปรแกรมการประมวลผลตามลำดับก่อน แล้วจึงฝังลงในวัตถุขนาดใหญ่หนึ่งหรือสองชิ้น ตามหลักการเขียนโปรแกรม อ็อบเจ็กต์ควรแสดงแนวคิดของแอปพลิเคชัน ไม่ใช่ตัวแอปพลิเคชันเอง
9. หากคุณต้องทำการเขียนโปรแกรมที่ไม่น่าดู อย่างน้อยคุณควรใส่โค้ดไว้ในชั้นเรียน
10. เมื่อใดก็ตามที่คุณพบว่าคลาสมีการบูรณาการอย่างใกล้ชิด คุณต้องพิจารณาว่าจะใช้คลาสภายในเพื่อปรับปรุงงานการเขียนโค้ดและการบำรุงรักษาหรือไม่ (ดู "การปรับปรุงโค้ดด้วยคลาสภายใน" ในบทที่ 14 ส่วนที่ 14.1.2)
11. เพิ่มความคิดเห็นอย่างระมัดระวังที่สุดเท่าที่จะเป็นไปได้ และใช้ไวยากรณ์เอกสารความคิดเห็น javadoc เพื่อสร้างเอกสารประกอบโปรแกรมของคุณเอง
12. หลีกเลี่ยงการใช้ "ตัวเลขมหัศจรรย์" ตัวเลขเหล่านี้เข้ากันได้ยากกับโค้ด หากคุณต้องการแก้ไขในอนาคต มันจะกลายเป็นฝันร้ายอย่างไม่ต้องสงสัย เพราะคุณไม่รู้ว่า "100" หมายถึง "ขนาดอาร์เรย์" หรือ "อย่างอื่นทั้งหมด" ดังนั้น เราควรสร้างค่าคงที่ ตั้งชื่อที่น่าเชื่อถือและสื่อความหมาย และใช้ตัวระบุคงที่ตลอดทั้งโปรแกรม ทำให้โปรแกรมเข้าใจและบำรุงรักษาได้ง่ายขึ้น
13. เมื่อพูดถึงตัวสร้างและข้อยกเว้น คุณมักจะต้องการโยนข้อยกเว้นใด ๆ ที่พบในตัวสร้างอีกครั้ง หากมันทำให้การสร้างวัตถุนั้นล้มเหลว วิธีนี้จะทำให้ผู้โทรไม่สุ่มสี่สุ่มห้าคิดว่าวัตถุนั้นถูกสร้างขึ้นอย่างถูกต้อง
14. หลังจากที่โปรแกรมเมอร์ไคลเอนต์ใช้อ็อบเจ็กต์เสร็จแล้ว หากคลาสของคุณต้องการงานล้างข้อมูลใดๆ ให้พิจารณาวางโค้ดล้างข้อมูลในวิธีที่กำหนดไว้อย่างดี โดยใช้ชื่อเช่น cleanup() เพื่อระบุการใช้งานของคุณอย่างชัดเจน นอกจากนี้ ยังสามารถวางธงบูลีนภายในคลาสเพื่อระบุว่าวัตถุนั้นถูกเคลียร์แล้วหรือไม่ ในเมธอด Finalize() ของคลาส ตรวจสอบให้แน่ใจว่าออบเจ็กต์ได้ถูกเคลียร์แล้ว และคลาสที่สืบทอดมาจาก RuntimeException ได้ถูกละทิ้งไปแล้ว (หากยังไม่ได้ดำเนินการ) ซึ่งบ่งชี้ถึงข้อผิดพลาดในการเขียนโปรแกรม ก่อนที่จะดำเนินการแก้ไขปัญหาเช่นนี้ ตรวจสอบให้แน่ใจว่าการสรุป () ทำงานบนระบบของคุณ (คุณอาจต้องเรียก System.runFinalizersOnExit(true) เพื่อให้แน่ใจว่าลักษณะการทำงานนี้)
15. ในขอบเขตเฉพาะ หากต้องเคลียร์ออบเจ็กต์ (ไม่ได้ประมวลผลโดยกลไกการรวบรวมขยะ) โปรดใช้วิธีต่อไปนี้: เตรียมใช้งานออบเจ็กต์ หากสำเร็จ ให้ป้อนบล็อกลองที่มีส่วนคำสั่งสุดท้ายทันทีเพื่อเริ่มงานการล้างข้อมูล .
16. หากคุณต้องการแทนที่ (ยกเลิก) ขั้นสุดท้าย () ในระหว่างกระบวนการเริ่มต้น โปรดอย่าลืมเรียก super.finalize() (หาก Object เป็นของคลาส super โดยตรงของเรา ก็ไม่จำเป็น) ในกระบวนการเอาชนะการสรุป () การเรียก super.finalize() ควรเป็นการดำเนินการสุดท้าย ไม่ใช่การดำเนินการแรก เพื่อให้แน่ใจว่าส่วนประกอบของคลาสพื้นฐานยังคงใช้ได้เมื่อจำเป็น
17. เมื่อสร้างคอลเลกชันอ็อบเจ็กต์ที่มีขนาดคงที่ ให้ถ่ายโอนไปยังอาร์เรย์ (โดยเฉพาะหากคุณวางแผนที่จะส่งคืนคอลเลกชันนี้จากวิธีการ) ด้วยวิธีนี้ เราจึงสามารถเพลิดเพลินกับประโยชน์ของการตรวจสอบประเภทอาเรย์ ณ เวลาคอมไพล์ได้ นอกจากนี้ ผู้รับอาร์เรย์อาจไม่จำเป็นต้อง "ส่ง" วัตถุลงในอาร์เรย์เพื่อใช้งาน
18. ลองใช้อินเทอร์เฟซแทนคลาสนามธรรม หากคุณรู้ว่าบางสิ่งจะเป็นคลาสพื้นฐาน ตัวเลือกแรกของคุณควรเปลี่ยนให้เป็นอินเทอร์เฟซ เฉพาะเมื่อคุณต้องใช้คำจำกัดความของเมธอดหรือตัวแปรสมาชิกเท่านั้น คุณจะต้องเปลี่ยนให้เป็นคลาสนามธรรม โดยพื้นฐานแล้วอินเทอร์เฟซจะอธิบายสิ่งที่ไคลเอ็นต์ต้องการทำ ในขณะที่คลาสนั้นมีไว้สำหรับ (หรืออนุญาต) รายละเอียดการใช้งานเฉพาะ
19. ภายในตัวสร้าง ให้ทำเฉพาะงานที่จำเป็นเพื่อทำให้วัตถุอยู่ในสถานะที่ถูกต้องเท่านั้น เมื่อเป็นไปได้ ให้หลีกเลี่ยงการเรียกวิธีการอื่น เนื่องจากวิธีการเหล่านั้นอาจถูกแทนที่หรือยกเลิกโดยผู้อื่น ทำให้เกิดผลลัพธ์ที่คาดเดาไม่ได้ในระหว่างกระบวนการสร้าง (ดูบทที่ 7 สำหรับรายละเอียด)
20. ออบเจ็กต์ไม่ควรเพียงเก็บข้อมูลบางอย่างเท่านั้น แต่ควรกำหนดพฤติกรรมของวัตถุไว้อย่างดีด้วย
21. เมื่อสร้างคลาสใหม่ตามคลาสที่มีอยู่ กรุณาเลือก "ใหม่" หรือ "สร้าง" ก่อน ปัญหานี้ควรได้รับการพิจารณาก็ต่อเมื่อต้องสืบทอดข้อกำหนดการออกแบบของคุณเอง หากใช้การสืบทอดโดยอนุญาตให้มีการสร้างใหม่ การออกแบบทั้งหมดจะซับซ้อนโดยไม่จำเป็น
22. ใช้การครอบคลุมการสืบทอดและเมธอดเพื่อแสดงความแตกต่างระหว่างพฤติกรรม และใช้ฟิลด์เพื่อแสดงความแตกต่างระหว่างสถานะ ตัวอย่างที่ร้ายแรงมากคือการแสดงสีผ่านการสืบทอดจากคลาสที่แตกต่างกัน ซึ่งควรหลีกเลี่ยงอย่างแน่นอน: ใช้ฟิลด์ "สี" โดยตรง
23. เพื่อหลีกเลี่ยงปัญหาเมื่อเขียนโปรแกรม โปรดตรวจสอบให้แน่ใจว่าแต่ละชื่อสอดคล้องกับคลาสเดียวเท่านั้นที่เส้นทางคลาสของคุณชี้ไป มิฉะนั้น คอมไพลเลอร์อาจค้นหาคลาสอื่นที่มีชื่อเดียวกันก่อนและรายงานข้อความแสดงข้อผิดพลาด หากคุณสงสัยว่าคุณประสบปัญหาเส้นทางคลาส โปรดลองค้นหาไฟล์ .class ที่มีชื่อเดียวกันที่จุดเริ่มต้นของแต่ละเส้นทางของคลาส
24. เมื่อใช้เหตุการณ์ "อะแดปเตอร์" ใน Java 1.1 AWT จะพบกับดักได้ง่ายเป็นพิเศษ หากวิธีการของอะแดปเตอร์ถูกแทนที่ และวิธีการสะกดไม่ได้เจาะจงเป็นพิเศษ ผลลัพธ์สุดท้ายคือการเพิ่มวิธีการใหม่แทนที่จะแทนที่วิธีการที่มีอยู่ อย่างไรก็ตาม เนื่องจากสิ่งนี้ถูกกฎหมายอย่างสมบูรณ์ คุณจะไม่ได้รับข้อความแสดงข้อผิดพลาดจากคอมไพเลอร์หรือระบบรันไทม์ แต่โค้ดของคุณจะทำงานไม่ถูกต้อง
25. ใช้โซลูชันการออกแบบที่สมเหตุสมผลเพื่อกำจัด "ฟังก์ชันหลอก" นั่นคือ หากคุณต้องการสร้างออบเจ็กต์ของคลาสเพียงรายการเดียว อย่าจำกัดตัวเองไว้ที่แอปพลิเคชันล่วงหน้า และเพิ่มความคิดเห็น "สร้างเพียงรายการเดียวเท่านั้น" โปรดพิจารณาสรุปให้อยู่ในรูปแบบ "ลูกคนเดียว" หากคุณมีโค้ดกระจัดกระจายจำนวนมากในโปรแกรมหลักที่ใช้ในการสร้างออบเจ็กต์ของคุณเอง ให้ลองใช้โซลูชันที่สร้างสรรค์เพื่อห่อหุ้มโค้ดนี้
26.ระวัง “อัมพาตจากการวิเคราะห์” โปรดจำไว้ว่า ไม่ว่าจะเกิดอะไรขึ้น คุณต้องเข้าใจสถานะของโครงการทั้งหมดล่วงหน้า จากนั้นจึงตรวจสอบรายละเอียด เนื่องจากคุณเข้าใจสถานการณ์โดยรวมได้ดี คุณจึงสามารถรับรู้ปัจจัยที่ไม่ทราบบางอย่างได้อย่างรวดเร็ว และป้องกันไม่ให้คุณตกอยู่ใน "ตรรกะที่ตายตัว" เมื่อตรวจสอบรายละเอียด
27. ระวัง "การเพิ่มประสิทธิภาพก่อนกำหนด" ทำให้มันรันก่อน คิดจะเร็วขึ้นในภายหลัง แต่เพิ่มประสิทธิภาพเฉพาะเมื่อจำเป็น และได้รับการพิสูจน์แล้วว่ามีปัญหาคอขวดด้านประสิทธิภาพในบางส่วนของโค้ดเท่านั้น เว้นแต่ว่าคุณใช้เครื่องมือพิเศษในการวิเคราะห์ปัญหาคอขวด คุณอาจจะเสียเวลาไปเปล่าๆ ต้นทุนโดยนัยของการปรับปรุงประสิทธิภาพคือโค้ดของคุณเข้าใจยากขึ้นและบำรุงรักษายากขึ้น
28. จำไว้ว่าคุณใช้เวลาในการอ่านโค้ดมากกว่าการเขียน การออกแบบที่ชัดเจนส่งผลให้ได้โปรแกรมที่เข้าใจง่าย แต่ความคิดเห็น คำอธิบายที่รอบคอบ และตัวอย่างบางส่วนมักจะมีคุณค่าอย่างยิ่ง พวกเขามีความสำคัญมากทั้งต่อตัวคุณเองและผู้ที่ติดตามคุณ หากคุณยังคงสงสัยในเรื่องนี้ ลองจินตนาการถึงความคับข้องใจในการพยายามค้นหาข้อมูลที่เป็นประโยชน์ในเอกสาร Java ออนไลน์ แล้วคุณอาจมั่นใจได้
29. หากคุณคิดว่าคุณได้ทำการวิเคราะห์ ออกแบบ หรือการนำไปใช้งานที่ดี โปรดเปลี่ยนมุมมองการคิดของคุณเล็กน้อย ลองเชิญบุคคลภายนอก ไม่จำเป็นต้องเป็นผู้เชี่ยวชาญ แต่เชิญบุคคลจากส่วนอื่นๆ ของบริษัท ขอให้พวกเขามองงานของคุณด้วยสายตาที่สดใส และดูว่าพวกเขาสามารถมองเห็นปัญหาที่คุณตาบอดหรือไม่ การนำวิธีนี้มาใช้ทำให้เราสามารถระบุปัญหาสำคัญบางประการในขั้นตอนที่เหมาะสมที่สุดสำหรับการปรับเปลี่ยนได้ และหลีกเลี่ยงการสูญเสียเงินและพลังงานที่เกิดจากการแก้ปัญหาหลังจากเปิดตัวผลิตภัณฑ์
30. การออกแบบที่ดีสามารถสร้างผลตอบแทนสูงสุดได้ กล่าวโดยสรุป มักจะใช้เวลานานในการค้นหาวิธีแก้ไขปัญหาที่เหมาะสมที่สุดสำหรับปัญหานั้นๆ แต่เมื่อคุณพบวิธีการที่ถูกต้องแล้ว งานในอนาคตของคุณจะง่ายขึ้นมาก และคุณไม่ต้องทนกับความยากลำบากหลายชั่วโมง วัน หรือเดือนแห่งการต่อสู้อันเจ็บปวด การทำงานหนักของเราจะนำมาซึ่งรางวัลที่ยิ่งใหญ่ที่สุด (แม้จะนับไม่ถ้วนก็ตาม) และเนื่องจากฉันใช้ความพยายามอย่างมาก ในที่สุดฉันก็ได้แผนการออกแบบที่ยอดเยี่ยม และความตื่นเต้นแห่งความสำเร็จก็น่าตื่นเต้นเช่นกัน ต่อต้านการล่อลวงให้รีบเร่งทำงานซึ่งมักไม่คุ้มกับความพยายาม