คุณไม่จำเป็นต้องปฏิบัติตามหลักการเหล่านี้อย่างเคร่งครัด และไม่มีบทลงโทษทางศาสนาสำหรับการละเมิดหลักการเหล่านี้ แต่คุณควรคิดว่าหลักการเหล่านี้เป็นเสียงระฆังปลุก หากหนึ่งในนั้นถูกละเมิด ระฆังสัญญาณเตือนภัยจะดังขึ้น ----- Arthur J.Riel
(1) ข้อมูลทั้งหมดควรถูกซ่อนไว้ในคลาสที่ข้อมูลนั้นตั้งอยู่
(2) ผู้ใช้ของคลาสจะต้องพึ่งพาอินเทอร์เฟซที่ใช้ร่วมกันของคลาส แต่คลาสไม่สามารถพึ่งพาผู้ใช้ได้
(3) ย่อข้อความในโปรโตคอลคลาสให้เล็กสุด
(4) ใช้อินเทอร์เฟซสาธารณะขั้นพื้นฐานที่สุดที่ทุกคลาสเข้าใจ [เช่น การดำเนินการคัดลอก (สำเนาลึกและสำเนาตื้น) การพิจารณาความเท่าเทียมกัน เนื้อหาเอาต์พุตที่ถูกต้อง การแยกวิเคราะห์จากคำอธิบาย ASCII ฯลฯ ]
(5) อย่าใส่รายละเอียดการใช้งาน (เช่น ฟังก์ชั่นส่วนตัวที่วางโค้ดที่ใช้ร่วมกัน) ลงในอินเทอร์เฟซสาธารณะของคลาส
ถ้าสองวิธีในคลาสมีโค้ดที่เหมือนกัน คุณสามารถสร้างฟังก์ชันส่วนตัวที่ป้องกันโค้ดทั่วไปนั้นได้
(6) ห้ามรบกวนอินเทอร์เฟซสาธารณะของชั้นเรียนด้วยสิ่งที่ผู้ใช้ไม่สามารถใช้หรือไม่สนใจ
(7) ควรมีการเชื่อมต่อระหว่างคลาสเป็นศูนย์ หรือเฉพาะความสัมพันธ์แบบเชื่อมต่อที่ได้รับเท่านั้น นั่นคือคลาสหนึ่งไม่มีส่วนเกี่ยวข้องกับคลาสอื่น หรือใช้เฉพาะการดำเนินการในอินเทอร์เฟซสาธารณะของคลาสอื่นเท่านั้น
(8) คลาสควรเป็นตัวแทนเพียงนามธรรมเดียวเท่านั้น
คลาสทั้งหมดในแพ็คเกจควรปิดร่วมกันสำหรับการเปลี่ยนแปลงคุณสมบัติประเภทเดียวกัน หากการเปลี่ยนแปลงส่งผลกระทบต่อแพ็คเกจ มันจะส่งผลกระทบต่อคลาสทั้งหมดในแพ็คเกจ แต่จะไม่ส่งผลกระทบใด ๆ กับแพ็คเกจอื่น ๆ
(9) รวมศูนย์ข้อมูลและพฤติกรรมที่เกี่ยวข้อง
ผู้ออกแบบควรตระหนักถึงวัตถุที่ได้รับข้อมูลจากวัตถุอื่นผ่านการดำเนินการเช่นรับ พฤติกรรมประเภทนี้บอกเป็นนัยว่ามีการละเมิดหลักการเชิงประจักษ์นี้
(10) ใส่ข้อมูลที่ไม่เกี่ยวข้องลงในหมวดหมู่อื่น (นั่นคือ พฤติกรรมการไม่สื่อสารกัน)
สร้างการพึ่งพาต่อความมั่นคง
(11) ตรวจสอบให้แน่ใจว่าแนวคิดเชิงนามธรรมที่คุณสร้างแบบจำลองนั้นเป็นคลาส ไม่ใช่แค่บทบาทของวัตถุเท่านั้น
(12) กระจายการทำงานของระบบให้สม่ำเสมอที่สุดเท่าที่จะเป็นไปได้ในทิศทางแนวนอน กล่าวคือ ตามการออกแบบ คลาสระดับบนสุดควรใช้การทำงานร่วมกันอย่างเท่าเทียมกัน
(13) อย่าสร้างคลาส/อ็อบเจ็กต์ที่มีอำนาจทุกอย่างในระบบของคุณ ควรระมัดระวังเป็นพิเศษกับคลาสที่มีชื่อว่า Driver, Manager, System และ Susystem
วางแผนอินเทอร์เฟซแทนที่จะใช้อินเทอร์เฟซ
(14) ระวังคลาสที่กำหนดวิธีการเข้าถึงจำนวนมากในอินเทอร์เฟซสาธารณะ วิธีการเข้าถึงจำนวนมากหมายความว่าข้อมูลและพฤติกรรมที่เกี่ยวข้องไม่ได้ถูกจัดเก็บไว้ที่ส่วนกลาง
(15) ระวังชั้นเรียนที่มีพฤติกรรมมากเกินไปและไม่สื่อสารกัน
อาการอีกอย่างหนึ่งของปัญหานี้คือการสร้างฟังก์ชัน get และ set จำนวนมากในอินเทอร์เฟซสาธารณะของคลาสในแอปพลิเคชันของคุณ
(16) ในแอปพลิเคชันที่ประกอบด้วยโมเดลเชิงวัตถุที่มีการโต้ตอบกับอินเทอร์เฟซผู้ใช้ โมเดลไม่ควรขึ้นอยู่กับอินเทอร์เฟซ แต่อินเทอร์เฟซควรขึ้นอยู่กับโมเดล
(17) สร้างแบบจำลองตามโลกแห่งความเป็นจริงให้มากที่สุดเท่าที่จะเป็นไปได้ (เรามักจะละเมิดหลักการนี้เพื่อให้สอดคล้องกับหลักการของการกระจายฟังก์ชันของระบบ หลีกเลี่ยงหลักการคลาสอเนกประสงค์ และวางข้อมูลและพฤติกรรมที่เกี่ยวข้องจากส่วนกลาง)
(18) ลบคลาสที่ไม่จำเป็นออกจากการออกแบบของคุณ
โดยทั่วไป เราจะดาวน์เกรดคลาสนี้เป็นพร็อพเพอร์ตี้
(19) ลบคลาสที่อยู่นอกระบบ
ลักษณะของคลาสภายนอกระบบคือ ในแง่นามธรรม คลาสจะส่งข้อความไปยังโดเมนระบบเท่านั้น แต่ไม่ยอมรับข้อความจากคลาสอื่นในโดเมนระบบ
(20) อย่าเปลี่ยนการปฏิบัติการให้เป็นคลาส ตั้งคำถามกับชั้นเรียนที่มีชื่อเป็นคำกริยาหรือมาจากคำกริยา โดยเฉพาะชั้นเรียนที่มีการกระทำที่มีความหมายเพียงการกระทำเดียว พิจารณาว่าควรย้ายพฤติกรรมที่มีความหมายนั้นไปยังชั้นเรียนที่มีอยู่แล้วหรือที่ยังไม่ถูกค้นพบ
(21) เรามักจะแนะนำคลาสพร็อกซีเมื่อสร้างแบบจำลองการวิเคราะห์ของแอปพลิเคชัน ในระหว่างขั้นตอนการออกแบบ เรามักจะพบว่าตัวแทนจำนวนมากไม่มีประโยชน์และควรลบออก
(22) ลดจำนวนผู้ทำงานร่วมกันในชั้นเรียนให้เหลือน้อยที่สุด
จำนวนคลาสอื่นที่ใช้โดยคลาสควรเก็บไว้ให้น้อยที่สุด
(23) ลดจำนวนข้อความที่ส่งระหว่างคลาสและผู้ทำงานร่วมกันให้เหลือน้อยที่สุด
(24) ลดจำนวนการทำงานร่วมกันระหว่างคลาสและผู้ทำงานร่วมกันให้เหลือน้อยที่สุด นั่นคือ: ลดจำนวนข้อความที่แตกต่างกันที่ส่งผ่านระหว่างคลาสและผู้ทำงานร่วมกัน
(25) ลดการกระจายออกจากคลาสให้เหลือน้อยที่สุด นั่นคือ ลดผลคูณของจำนวนข้อความที่กำหนดโดยคลาสและจำนวนข้อความที่ส่ง
(26) ถ้าคลาสมีวัตถุของคลาสอื่น คลาสที่มีอยู่ควรส่งข้อความไปยังวัตถุที่มีอยู่ นั่นคือ: ความสัมพันธ์แบบรวมหมายถึงความสัมพันธ์การใช้งานเสมอ
(27) วิธีการส่วนใหญ่ที่กำหนดไว้ในคลาสควรใช้สมาชิกข้อมูลส่วนใหญ่เป็นส่วนใหญ่
(28) จำนวนอ็อบเจ็กต์ที่มีอยู่ในคลาสไม่ควรเกินความจุของหน่วยความจำระยะสั้นของผู้พัฒนา ตัวเลขนี้มักจะเป็น 6
เมื่อคลาสมีสมาชิกข้อมูลมากกว่า 6 ตัว คุณสามารถแบ่งสมาชิกข้อมูลที่เกี่ยวข้องเชิงตรรกะออกเป็นกลุ่มได้ จากนั้นใช้คลาสที่มีใหม่เพื่อเก็บสมาชิกกลุ่มนี้
(29) ปล่อยให้ฟังก์ชันของระบบกระจายในแนวตั้งในระบบการสืบทอดที่แคบและลึก
(30) เมื่อนำข้อจำกัดทางความหมายไปใช้ วิธีที่ดีที่สุดคือนำไปปฏิบัติตามคำจำกัดความของคลาส สิ่งนี้มักจะนำไปสู่การโอเวอร์โฟลว์ของคลาส ซึ่งในกรณีนี้ข้อจำกัดควรถูกนำไปใช้ในพฤติกรรมของคลาส ซึ่งโดยปกติแล้วไม่จำเป็นใน Constructor
(31) เมื่อนำข้อจำกัดทางความหมายไปใช้ในตัวสร้างของคลาส ให้วางการทดสอบข้อจำกัดในระดับการรวมที่ลึกที่สุดที่อนุญาตโดยโดเมนของตัวสร้าง
(32) หากข้อมูลเชิงความหมายที่ข้อจำกัดอาศัยการเปลี่ยนแปลงบ่อยครั้ง วิธีที่ดีที่สุดคือวางไว้ในออบเจ็กต์บุคคลที่สามแบบรวมศูนย์
(33) ถ้าข้อมูลเชิงความหมายซึ่งข้อจำกัดพึ่งพาแทบจะไม่เปลี่ยนแปลง ข้อมูลนั้นจะถูกกระจายให้ดีที่สุดระหว่างคลาสที่เกี่ยวข้องกับข้อจำกัด
(34) ชั้นเรียนต้องรู้ว่ามีอะไรอยู่ แต่ไม่สามารถรู้ได้ว่าใครบรรจุอยู่
(35) วัตถุที่มีขอบเขตตามตัวอักษร (นั่นคือ อยู่ในคลาสเดียวกัน) ไม่ควรมีความสัมพันธ์การใช้งานระหว่างกัน
(36) การสืบทอดควรใช้เพื่อจำลองลำดับชั้นความเชี่ยวชาญเท่านั้น
(37) คลาสที่ได้รับมาจะต้องรู้เกี่ยวกับคลาสพื้นฐาน และคลาสพื้นฐานไม่ควรรู้ข้อมูลใด ๆ เกี่ยวกับคลาสที่ได้รับมา
(38) ข้อมูลทั้งหมดในคลาสพื้นฐานควรเป็นแบบส่วนตัว อย่าใช้ข้อมูลที่ได้รับการป้องกัน
ผู้ออกแบบคลาสไม่ควรวางสิ่งต่าง ๆ ไว้ในส่วนต่อประสานสาธารณะที่ผู้ใช้คลาสไม่ต้องการ
(39) ตามทฤษฎีแล้ว ลำดับชั้นการสืบทอดควรจะลึกยิ่งขึ้น ยิ่งลึกยิ่งดี
(40) ในทางปฏิบัติ ความลึกของลำดับชั้นการสืบทอดไม่ควรเกินความจุหน่วยความจำระยะสั้นของคนทั่วไป ค่าความลึกที่ยอมรับกันอย่างแพร่หลายคือ 6
(41) คลาสนามธรรมทั้งหมดควรเป็นคลาสพื้นฐาน
(42) คลาสพื้นฐานทั้งหมดควรเป็นคลาสนามธรรม
(43) ใส่ข้อมูล พฤติกรรม และ/หรือความเหมือนกันของอินเทอร์เฟซให้สูงที่สุดเท่าที่จะเป็นไปได้ในลำดับชั้นการสืบทอด
(44) หากคลาสตั้งแต่สองคลาสขึ้นไปใช้ข้อมูลร่วมกัน (แต่ไม่มีพฤติกรรมร่วมกัน) ข้อมูลทั่วไปควรถูกวางไว้ในคลาสที่รวมอยู่ในแต่ละคลาสที่ใช้ข้อมูลนี้ร่วมกัน
(45) ถ้าตั้งแต่สองคลาสขึ้นไปมีข้อมูลและพฤติกรรมร่วมกัน (นั่นคือ วิธีการ) แต่ละคลาสเหล่านี้ควรสืบทอดจากคลาสพื้นฐานทั่วไปที่แสดงถึงข้อมูลและวิธีการเหล่านี้
(46) หากคลาสตั้งแต่สองคลาสขึ้นไปใช้อินเทอร์เฟซร่วมกัน (อ้างอิงถึงข้อความ ไม่ใช่วิธีการ) คลาสเหล่านั้นควรสืบทอดจากคลาสพื้นฐานทั่วไปก็ต่อเมื่อจำเป็นต้องใช้แบบโพลีมอร์ฟิก
(47) การวิเคราะห์การแสดงประเภทวัตถุเป็นกรณีๆ ไปมักผิด ในกรณีดังกล่าวส่วนใหญ่ นักออกแบบควรใช้ความหลากหลาย
(48) การวิเคราะห์การแสดงค่าแอตทริบิวต์เป็นกรณีไปมักจะผิด คลาสควรแยกออกเป็นลำดับชั้นการสืบทอด โดยแต่ละค่าแอตทริบิวต์จะถูกแปลงเป็นคลาสที่ได้รับ
(49) อย่าสร้างแบบจำลองความหมายแบบไดนามิกของคลาสผ่านความสัมพันธ์แบบสืบทอด การพยายามสร้างโมเดลซีแมนทิกส์แบบไดนามิกด้วยความสัมพันธ์เชิงความหมายแบบคงที่ส่งผลให้เกิดการสลับประเภทที่รันไทม์
(50) อย่าเปลี่ยนวัตถุคลาสเป็นคลาสที่ได้รับ ระวังคลาสที่ได้รับที่มีอินสแตนซ์เดียวเท่านั้น
(51) หากคุณคิดว่าจำเป็นต้องสร้างคลาสใหม่ขณะรันไทม์ ให้ย้อนกลับไปและตระหนักว่าคุณกำลังสร้างวัตถุ ตอนนี้ สรุปวัตถุเหล่านี้ให้เป็นคลาส
(52) การใช้เมธอดว่าง (นั่นคือเมธอดที่ไม่ทำอะไรเลย) ในคลาสที่ได้รับมาเพื่อแทนที่เมธอดในคลาสฐานนั้นผิดกฎหมาย
(53) อย่าสับสนการรวมทางเลือกเข้ากับความจำเป็นในการรับมรดก การสร้างโมเดลการรวมทางเลือกเป็นการสืบทอดจะนำไปสู่การเพิ่มจำนวนคลาส
(54) เมื่อสร้างลำดับชั้นการสืบทอด พยายามสร้างเฟรมเวิร์กที่นำมาใช้ซ้ำได้ แทนที่จะสร้างส่วนประกอบที่นำมาใช้ซ้ำได้
(55) หากคุณใช้การสืบทอดหลายรายการในการออกแบบของคุณ ถือว่าคุณทำผิดพลาด หากคุณไม่ได้ทำผิดพลาดคุณต้องพยายามพิสูจน์
(56) เมื่อใดก็ตามที่มีการใช้การสืบทอดในการออกแบบเชิงวัตถุ ให้ถามตัวเองด้วยคำถามสองข้อ: (1) คลาสที่ได้รับมานั้นเป็นประเภทพิเศษของสิ่งที่สืบทอดมาหรือไม่? (2) คลาสฐานเป็นส่วนหนึ่งของคลาสที่ได้รับหรือไม่
(57) หากคุณพบการสืบทอดหลายรายการในการออกแบบเชิงวัตถุ ตรวจสอบให้แน่ใจว่าไม่มีคลาสพื้นฐานใดที่เป็นคลาสที่ได้รับมาจากคลาสฐานอื่น
(58) ในการออกแบบเชิงวัตถุ หากคุณต้องการเลือกระหว่างการรวมและการเชื่อมโยง โปรดเลือกการรวม
(59) อย่าใช้ข้อมูลทั่วโลกหรือฟังก์ชั่นทั่วโลกสำหรับการบัญชีวัตถุของชั้นเรียน ควรใช้ตัวแปรคลาสหรือวิธีการเรียน
(60) นักออกแบบเชิงวัตถุไม่ควรปล่อยให้หลักการออกแบบทางกายภาพมาบ่อนทำลายการออกแบบเชิงตรรกะของพวกเขา อย่างไรก็ตาม เรามักจะใช้เกณฑ์การออกแบบทางกายภาพในการตัดสินใจเกี่ยวกับการออกแบบเชิงตรรกะ
(61) อย่าข้ามอินเทอร์เฟซสาธารณะเพื่อแก้ไขสถานะของวัตถุ