กฎการเขียนโค้ด: จากการสร้างระบบไปจนถึงการทำงานกับวัตถุ

สวัสดีตอนบ่ายครับทุกคน วันนี้ผมอยากจะพูดคุยกับคุณเกี่ยวกับการเขียนโค้ดอย่างถูกต้อง ตอนที่ผมเริ่มเขียนโปรแกรมครั้งแรก มันยังเขียนไม่ชัดเจนว่าคุณจะเขียนแบบนี้ที่ไหนได้ และถ้าคุณเขียนแบบนี้ ฉันจะตามหาคุณ และ…. เป็นผลให้ฉันมีคำถามมากมายในหัว: จะเขียนอย่างไรให้ถูกต้อง, ควรปฏิบัติตามหลักการใดในส่วนนี้หรือส่วนนั้นของโปรแกรม ฯลฯ ไม่ใช่ทุกคนที่ต้องการดำดิ่งสู่หนังสืออย่าง Clean Code ในทันที เนื่องจากมีการเขียนไว้มากมายในนั้น แต่ในตอนแรกมีเพียงเล็กน้อยที่ชัดเจน และเมื่อคุณอ่านจบ คุณจะหมดความปรารถนาที่จะเขียนโค้ดอีกต่อไป จากที่กล่าวมาข้างต้น วันนี้ฉันต้องการให้คำแนะนำเล็กๆ น้อยๆ (ชุดคำแนะนำเล็กๆ น้อยๆ) แก่คุณในการเขียนโค้ดระดับสูงกว่า ในบทความนี้ เราจะพูดถึงกฎและแนวคิดพื้นฐานที่เกี่ยวข้องกับการสร้างระบบและการทำงานกับอินเทอร์เฟซ คลาส และอ็อบเจ็กต์ การอ่านเนื้อหานี้จะไม่ทำให้คุณเสียเวลามากนักและฉันหวังว่าจะไม่ทำให้คุณเบื่อ ฉันจะไปจากบนลงล่างนั่นคือจากโครงสร้างทั่วไปของแอปพลิเคชันไปจนถึงรายละเอียดที่เฉพาะเจาะจงมากขึ้น

ระบบ

ลักษณะ ทั่วไปที่พึงประสงค์ของระบบคือ:

• ความซับซ้อนน้อยที่สุด - ควรหลีกเลี่ยงโครงการที่ซับซ้อนเกินไป สิ่งสำคัญคือความเรียบง่ายและชัดเจน (ดีที่สุด = เรียบง่าย)
• ง่ายต่อการบำรุงรักษา - เมื่อสร้างแอปพลิเคชันคุณต้องจำไว้ว่าจะต้องได้รับการสนับสนุน (แม้ว่าจะไม่ใช่คุณก็ตาม) ดังนั้นรหัสควรมีความชัดเจนและชัดเจน
• การมีเพศสัมพันธ์ที่อ่อนแอคือจำนวนการเชื่อมต่อขั้นต่ำระหว่างส่วนต่าง ๆ ของโปรแกรม (การใช้หลักการ OOP สูงสุด)
• การนำกลับมาใช้ใหม่ได้ - การออกแบบระบบที่มีความสามารถในการนำชิ้นส่วนกลับมาใช้ใหม่ในแอปพลิเคชันอื่น
• ความสะดวกในการพกพา - ระบบจะต้องปรับให้เข้ากับสภาพแวดล้อมอื่นได้อย่างง่ายดาย
• สไตล์เดียว - การออกแบบระบบในรูปแบบเดียวในส่วนต่างๆ
• ความสามารถในการขยาย (scalability) - การปรับปรุงระบบโดยไม่รบกวนโครงสร้างพื้นฐาน (หากคุณเพิ่มหรือเปลี่ยนส่วนย่อย สิ่งนี้จะไม่ส่งผลกระทบต่อส่วนที่เหลือ)

แทบจะเป็นไปไม่ได้เลยที่จะสร้างแอปพลิเคชันที่ไม่จำเป็นต้องแก้ไขโดยไม่ต้องเพิ่มฟังก์ชันการทำงาน เราจะต้องแนะนำองค์ประกอบใหม่ ๆ อย่างต่อเนื่องเพื่อให้ผลิตผลของเราสามารถทันเวลาได้ และนี่คือจุดที่ ความสามารถในการขยายขนาดเข้ามามีบทบาท ความสามารถในการปรับขนาดคือการขยายแอปพลิเคชันเป็นหลัก เพิ่มฟังก์ชันการทำงานใหม่ การทำงานกับทรัพยากรมากขึ้น (หรืออีกนัยหนึ่งคือ มีภาระงานมากขึ้น) นั่นคือเราต้องปฏิบัติตามกฎบางอย่าง เช่น การลดการเชื่อมต่อของระบบโดยการเพิ่มโมดูลาร์ เพื่อให้ง่ายต่อการเพิ่มตรรกะใหม่

ขั้นตอนการออกแบบระบบ

1. ระบบซอฟต์แวร์ - การออกแบบแอพพลิเคชั่นในรูปแบบทั่วไป
2. การแยกออกเป็นระบบย่อย/แพ็คเกจ - การกำหนดส่วนที่แยกออกจากกันอย่างมีเหตุผล และการกำหนดกฎของการโต้ตอบระหว่างส่วนเหล่านั้น
3. การแบ่งระบบย่อยออกเป็นคลาส - การแบ่งส่วนของระบบออกเป็นคลาสและอินเทอร์เฟซเฉพาะ รวมถึงการกำหนดปฏิสัมพันธ์ระหว่างกัน
4. การแบ่งคลาสออกเป็นวิธีการถือเป็นคำจำกัดความที่สมบูรณ์ของวิธีการที่จำเป็นสำหรับคลาส โดยขึ้นอยู่กับงานของคลาสนี้ การออกแบบวิธีการ - คำจำกัดความโดยละเอียดของการทำงานของแต่ละวิธี

โดยทั่วไปแล้ว นักพัฒนาทั่วไปมีหน้าที่รับผิดชอบในการออกแบบ และสถาปนิกแอปพลิเคชันมีหน้าที่รับผิดชอบในรายการที่อธิบายไว้ข้างต้น

หลักการและแนวคิดหลักในการออกแบบระบบ

สำนวนการเริ่มต้น Lazy แอปพลิเคชันจะไม่ใช้เวลาในการสร้างวัตถุจนกว่าจะมีการใช้งาน ซึ่งจะช่วยเร่งกระบวนการเริ่มต้นและลดภาระของตัวรวบรวมขยะ แต่คุณไม่ควรไปไกลเกินไปกับสิ่งนี้ เนื่องจากอาจนำไปสู่การละเมิดความเป็นโมดูลได้ การย้ายขั้นตอนการออกแบบทั้งหมดไปยังชิ้นส่วนเฉพาะ เช่น ชิ้นส่วนหลัก หรือชั้นเรียนที่ทำงานเหมือนกับโรงงานอาจคุ้มค่า ลักษณะหนึ่งของโค้ดที่ดีคือการไม่มีโค้ดสำเร็จรูปซ้ำๆ กันบ่อยครั้ง ตามกฎแล้วโค้ดดังกล่าวจะถูกวางไว้ในคลาสที่แยกจากกันเพื่อให้สามารถเรียกได้ในเวลาที่เหมาะสม AOP แยกกัน ฉันอยากจะพูดถึง การเขียนโปรแกรม เชิงแง่มุม นี่คือการเขียนโปรแกรมโดยการแนะนำตรรกะแบบ end-to-end นั่นคือโค้ดที่ทำซ้ำจะถูกใส่ลงในคลาส - แง่มุม และถูกเรียกเมื่อถึงเงื่อนไขบางประการ เช่น เมื่อเข้าถึงวิธีการที่มีชื่อเฉพาะหรือเข้าถึงตัวแปรประเภทใดประเภทหนึ่ง บางครั้งแง่มุมต่างๆ อาจทำให้เกิดความสับสน เนื่องจากยังไม่ชัดเจนในทันทีว่าโค้ดถูกเรียกจากที่ใด แต่อย่างไรก็ตาม นี่เป็นฟังก์ชันที่มีประโยชน์มาก โดยเฉพาะอย่างยิ่ง เมื่อทำการแคชหรือบันทึก: เราจะเพิ่มฟังก์ชันการทำงานนี้โดยไม่เพิ่มตรรกะเพิ่มเติมให้กับคลาสปกติ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับ OAP ได้ ที่นี่ กฎ 4 ข้อสำหรับการออกแบบสถาปัตยกรรมที่เรียบง่ายตามแนวคิดของ Kent Beck

1. การแสดงออก - ความจำเป็นในการแสดงจุดประสงค์ที่ชัดเจนของชั้นเรียน บรรลุได้โดยการตั้งชื่อที่ถูกต้อง ขนาดเล็ก และการยึดมั่นในหลักการของความรับผิดชอบเดี่ยว (เราจะดูรายละเอียดเพิ่มเติมด้านล่าง)
2. คลาสและวิธีการขั้นต่ำ - หากต้องการแบ่งคลาสออกเป็นขนาดเล็กและเป็นทิศทางเดียวเท่าที่เป็นไปได้ คุณอาจไปไกลเกินไป (ต่อต้านรูปแบบ - shotgunning) หลักการนี้เรียกร้องให้รักษาระบบให้มีขนาดกะทัดรัดและไม่ก้าวไกลจนเกินไป สร้างคลาสสำหรับการจามทุกครั้ง
3. การขาดความซ้ำซ้อน - โค้ดพิเศษที่สร้างความสับสนเป็นสัญญาณของการออกแบบระบบที่ไม่ดี และถูกย้ายไปยังที่อื่น
4. การดำเนินการทดสอบทั้งหมด - ระบบที่ผ่านการทดสอบทั้งหมดจะถูกควบคุม เนื่องจากการเปลี่ยนแปลงใดๆ อาจนำไปสู่ความล้มเหลวของการทดสอบ ซึ่งสามารถแสดงให้เราเห็นว่าการเปลี่ยนแปลงในตรรกะภายในของวิธีการยังนำไปสู่การเปลี่ยนแปลงในพฤติกรรมที่คาดหวังด้วย .

SOLID เมื่อออกแบบระบบควรคำนึงถึงหลักการที่รู้จักกันดีของ SOLID: S - ความรับผิดชอบเดี่ยว - หลักการของความรับผิดชอบเดี่ยว; O - เปิด-ปิด - หลักการของการเปิดกว้าง/ความใกล้ชิด L - การทดแทน Liskov - หลักการทดแทนของ Barbara Liskov; I - การแยกส่วนต่อประสาน - หลักการของการแยกส่วนต่อประสาน D - การผกผันการพึ่งพา - หลักการของการผกผันการพึ่งพา เราจะไม่ยึดหลักการแต่ละข้อโดยเฉพาะ (ซึ่งอยู่นอกเหนือขอบเขตของบทความนี้เล็กน้อย แต่คุณสามารถหาข้อมูลเพิ่มเติมได้ ที่นี่

อินเตอร์เฟซ

บางทีขั้นตอนที่สำคัญที่สุดประการหนึ่งของการสร้างคลาสที่เพียงพอคือการสร้างอินเทอร์เฟซที่เพียงพอซึ่งจะแสดงนามธรรมที่ดีที่ซ่อนรายละเอียดการใช้งานของคลาส และในขณะเดียวกันก็จะแสดงกลุ่มของวิธีการที่สอดคล้องกันอย่างชัดเจน . ลองมาดูหลักการ SOLID ข้อใดข้อหนึ่งให้ละเอียดยิ่งขึ้น - การแยกส่วนต่อประสาน : ไคลเอนต์ (คลาส) ไม่ควรใช้วิธีการที่ไม่จำเป็นซึ่งพวกเขาจะไม่ใช้ นั่นคือหากเรากำลังพูดถึงการสร้างอินเทอร์เฟซด้วยจำนวนวิธีการขั้นต่ำที่มุ่งเป้าไปที่การทำงานเดียวของอินเทอร์เฟซนี้ (สำหรับฉันมันคล้ายกับความรับผิดชอบเดียว มาก ) จะดีกว่าถ้าสร้างขนาดเล็กกว่าสองสามวิธี แทนที่จะเป็นอินเทอร์เฟซที่ป่องเดียว โชคดีที่คลาสสามารถใช้อินเทอร์เฟซได้มากกว่าหนึ่งอินเทอร์เฟซ เช่นเดียวกับกรณีที่มีการสืบทอด คุณต้องจำเกี่ยวกับการตั้งชื่ออินเทอร์เฟซที่ถูกต้อง: ชื่อควรสะท้อนถึงงานของมันอย่างถูกต้องที่สุด และแน่นอนว่ายิ่งสั้นก็ยิ่งทำให้เกิดความสับสนน้อยลงเท่านั้น อยู่ที่ระดับอินเทอร์เฟซที่ความคิดเห็นสำหรับเอกสาร มักจะเขียน ซึ่งในทางกลับกันช่วยให้เราอธิบายรายละเอียดว่าวิธีการนี้ควรทำข้อโต้แย้งใดที่ใช้และจะส่งกลับอะไร

ระดับ

ลองดูที่การจัดภายในของชั้นเรียน หรือมากกว่านั้นคือมุมมองและกฎบางประการที่ควรปฏิบัติตามเมื่อสร้างคลาส โดยทั่วไปแล้ว คลาสควรเริ่มต้นด้วยรายการตัวแปรที่จัดเรียงตามลำดับเฉพาะ:

1. ค่าคงที่คงที่สาธารณะ
2. ค่าคงที่ส่วนตัวแบบคงที่
3. ตัวแปรอินสแตนซ์ส่วนตัว

ถัดไปคือตัวสร้างต่างๆ ตามลำดับจากข้อโต้แย้งน้อยลงไปสู่มากขึ้น ตามด้วยวิธีการจากการเข้าถึงแบบเปิดมากขึ้นไปยังวิธีที่ปิดมากที่สุด: ตามกฎแล้ววิธีการส่วนตัวที่ซ่อนการใช้งานฟังก์ชันบางอย่างที่เราต้องการ จำกัด จะอยู่ที่ด้านล่างสุด

ขนาดชั้นเรียน

ตอนนี้ผมอยากจะพูดถึงขนาดชั้นเรียน เรามาจำหลักการข้อหนึ่งของ SOLID - single Responsibility ความรับผิดชอบเดี่ยว - หลักการของความรับผิดชอบเดี่ยว โดยระบุว่าแต่ละวัตถุมีเป้าหมายเดียวเท่านั้น (ความรับผิดชอบ) และตรรกะของวิธีการทั้งหมดมีจุดมุ่งหมายเพื่อสร้างความมั่นใจ นั่นคือตามนี้ เราควรหลีกเลี่ยงคลาสที่มีขนาดใหญ่และป่อง (ซึ่งโดยธรรมชาติของพวกมันคือสิ่งที่ตรงกันข้าม - "วัตถุศักดิ์สิทธิ์") และถ้าเรามีวิธีการมากมายที่มีตรรกะที่หลากหลายและต่างกันในคลาส เราจำเป็นต้องคิด เกี่ยวกับการแบ่งมันออกเป็นสองส่วนเชิงตรรกะ (คลาส) สิ่งนี้จะปรับปรุงให้อ่านโค้ดได้ง่ายขึ้น เนื่องจากเราไม่ต้องการเวลามากในการทำความเข้าใจวัตถุประสงค์ของเมธอด ถ้าเรารู้จุดประสงค์โดยประมาณของคลาสที่กำหนด คุณต้องจับตาดูชื่อคลาส ด้วย เพราะควรสะท้อนถึงตรรกะที่มีอยู่ สมมติว่า ถ้าเรามีคลาสที่มีชื่อมากกว่า 20 คำ เราต้องคิดถึงการปรับโครงสร้างใหม่ ทุกชั้นเรียนที่เคารพตนเองไม่ควรมีตัวแปรภายในจำนวนมากเช่นนี้ ในความเป็นจริง แต่ละวิธีทำงานร่วมกับวิธีใดวิธีหนึ่งหรือหลายวิธี ซึ่งทำให้มีการมีเพศสัมพันธ์มากขึ้นภายในคลาส (ซึ่งเป็นสิ่งที่ควรจะเป็นอย่างแน่นอน เนื่องจากคลาสควรเป็นแบบรวมเดียว) ผลที่ตามมาคือการเพิ่มการเชื่อมโยงกันของคลาสทำให้คลาสนั้นลดลง และแน่นอนว่าจำนวนคลาสของเราเพิ่มขึ้น สิ่งนี้น่ารำคาญสำหรับบางคน พวกเขาต้องไปชั้นเรียนมากขึ้นเพื่อดูว่างานใหญ่ๆ ทำงานอย่างไร เหนือสิ่งอื่นใด แต่ละคลาสเป็นโมดูลขนาดเล็กที่ควรเชื่อมต่อกับโมดูลอื่นให้น้อยที่สุด การแยกนี้ช่วยลดจำนวนการเปลี่ยนแปลงที่เราต้องทำเมื่อเพิ่มตรรกะเพิ่มเติมให้กับคลาส

วัตถุ

การห่อหุ้ม

ก่อนอื่นเราจะพูดถึงหลักการข้อหนึ่งของ OOP - encapsulation ดังนั้น การซ่อนการนำไปใช้งานไม่ได้อยู่ที่การสร้างเลเยอร์วิธีการระหว่างตัวแปร (การจำกัดการเข้าถึงด้วยวิธีการเดียวอย่างไม่ต้องคิด เช่น getters และ setters ซึ่งไม่ดีเลย เนื่องจากจุดรวมของการห่อหุ้มหายไป) การซ่อนการเข้าถึงมีวัตถุประสงค์เพื่อสร้างนามธรรม นั่นคือ คลาสจัดเตรียมวิธีการที่เป็นรูปธรรมทั่วไปที่เราทำงานกับข้อมูลของเรา แต่ผู้ใช้ไม่จำเป็นต้องทราบอย่างชัดเจนว่าเราทำงานกับข้อมูลนี้อย่างไร มันใช้งานได้และก็ไม่เป็นไร

กฎแห่งดีมีเตอร์

คุณยังสามารถพิจารณา Law of Demeter ได้: เป็นกฎชุดเล็กๆ ที่ช่วยจัดการความซับซ้อนในระดับชั้นเรียนและวิธี สมมติว่าเรามีวัตถุCarและมีเมธอดmove(Object arg1, Object arg2)- ตามกฎของ Demeter วิธีการนี้จำกัดอยู่เพียงการโทร:

• วิธีการของวัตถุนั้นเองCar(กล่าวคือ สิ่งนี้);
• วิธีการสร้างวัตถุในmove;
• วิธีการส่งผ่านวัตถุเป็นข้อโต้แย้ง - arg1, arg2;
• วิธีการของวัตถุภายในCar(เช่นเดียวกันนี้)

กล่าวอีกนัยหนึ่งกฎของ Demeterเป็นเหมือนกฎของเด็ก - คุณ สามารถพูดคุยกับเพื่อนได้ แต่ไม่ใช่กับคนแปลกหน้า

โครงสร้างข้อมูล

โครงสร้างข้อมูลคือชุดขององค์ประกอบที่เกี่ยวข้อง เมื่อพิจารณาวัตถุเป็นโครงสร้างข้อมูล มันคือชุดขององค์ประกอบข้อมูลที่ถูกประมวลผลโดยวิธีการ ซึ่งการมีอยู่ของสิ่งนั้นโดยปริยาย นั่นคือเป็นวัตถุที่มีวัตถุประสงค์เพื่อจัดเก็บและดำเนินการ (ประมวลผล) ข้อมูลที่เก็บไว้ ความแตกต่างที่สำคัญจากวัตถุทั่วไปคือวัตถุคือชุดของวิธีการที่ทำงานบนองค์ประกอบข้อมูลที่มีการมีอยู่โดยนัย คุณเข้าใจไหม? ในวัตถุทั่วไป ลักษณะหลักคือวิธีการ และตัวแปรภายในมุ่งเป้าไปที่การทำงานที่ถูกต้อง แต่ในโครงสร้างข้อมูลกลับเป็นอีกทางหนึ่ง: วิธีการสนับสนุนและช่วยทำงานกับองค์ประกอบที่เก็บไว้ ซึ่งเป็นองค์ประกอบหลักในที่นี้ โครงสร้างข้อมูลประเภทหนึ่งคือData Transfer Object (DTO ) นี่คือคลาสที่มีตัวแปรสาธารณะและไม่มีเมธอด (หรือเฉพาะเมธอดอ่าน/เขียนเท่านั้น) ที่ส่งข้อมูลเมื่อทำงานกับฐานข้อมูล ทำงานกับการแยกวิเคราะห์ข้อความจากซ็อกเก็ต ฯลฯ โดยทั่วไปแล้ว ข้อมูลในอ็อบเจ็กต์ดังกล่าวจะไม่ถูกเก็บไว้เป็นเวลานานและเป็น แปลงเกือบจะในทันทีเป็นเอนทิตีที่แอปพลิเคชันของเราทำงาน ในทางกลับกัน เอนทิตีก็เป็นโครงสร้างข้อมูลเช่นกัน แต่จุดประสงค์คือการมีส่วนร่วมในตรรกะทางธุรกิจในระดับต่างๆ ของแอปพลิเคชัน ในขณะที่ DTO คือการถ่ายโอนข้อมูลไปยัง/จากแอปพลิเคชัน ตัวอย่างดีทีโอ:

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

ทุกอย่างดูชัดเจน แต่ที่นี่เราเรียนรู้เกี่ยวกับการมีอยู่ของลูกผสม ไฮบริดเป็นอ็อบเจ็กต์ที่มีวิธีการในการจัดการตรรกะที่สำคัญและจัดเก็บองค์ประกอบภายในและวิธีการเข้าถึง (รับ/ตั้งค่า) วัตถุดังกล่าวยุ่งเหยิงและทำให้ยากต่อการเพิ่มวิธีการใหม่ คุณไม่ควรใช้เนื่องจากยังไม่ชัดเจนว่ามีไว้เพื่ออะไร - จัดเก็บองค์ประกอบหรือดำเนินการตรรกะบางประเภท คุณสามารถอ่านเกี่ยวกับประเภทของออบเจ็กต์ที่เป็นไปได้ได้ที่ นี่

หลักการสร้างตัวแปร

ลองคิดถึงตัวแปรกันสักหน่อย หรือลองคิดดูว่าหลักการในการสร้างตัวแปรเหล่านั้นคืออะไร:

1. ตามหลักการแล้ว คุณควรประกาศและเริ่มต้นตัวแปรทันทีก่อนใช้งาน (แทนที่จะสร้างมันขึ้นมาแล้วลืมมันไป)
2. เมื่อใดก็ตามที่เป็นไปได้ ให้ประกาศตัวแปรเป็นตัวแปรสุดท้ายเพื่อป้องกันไม่ให้ค่าเปลี่ยนแปลงหลังจากการกำหนดค่าเริ่มต้น
3. อย่าลืมเกี่ยวกับตัวแปรตัวนับ (โดยปกติแล้วเราใช้พวกมันในการวนซ้ำบางประเภทforนั่นคือเราต้องไม่ลืมที่จะรีเซ็ตพวกมัน ไม่เช่นนั้นอาจทำให้ตรรกะทั้งหมดของเราเสียหายได้)
4. คุณควรพยายามเริ่มต้นตัวแปรในตัวสร้าง
5. หากมีทางเลือกระหว่างการใช้ออบเจ็กต์ที่มีหรือไม่มีการอ้างอิง ( new SomeObject()) ให้เลือกไม่มี ( ) เนื่องจากเมื่อใช้แล้วออบเจ็กต์นี้จะถูกลบออกในระหว่างการรวบรวมขยะครั้งถัดไปและจะไม่สิ้นเปลืองทรัพยากร
6. ทำให้อายุการใช้งานของตัวแปรสั้นที่สุดเท่าที่จะเป็นไปได้ (ระยะห่างระหว่างการสร้างตัวแปรและการเข้าถึงครั้งล่าสุด)
7. เริ่มต้นตัวแปรที่ใช้ในลูปทันทีก่อนลูป แทนที่จะเริ่มต้นที่จุดเริ่มต้นของวิธีการที่มีการวนซ้ำ
8. เริ่มต้นด้วยขอบเขตที่จำกัดที่สุดเสมอและขยายขอบเขตหากจำเป็นเท่านั้น (คุณควรพยายามทำให้ตัวแปรเป็นแบบโลคัลมากที่สุด)
9. ใช้แต่ละตัวแปรเพื่อจุดประสงค์เดียวเท่านั้น
10. หลีกเลี่ยงตัวแปรที่มีความหมายที่ซ่อนอยู่ (ตัวแปรถูกแยกระหว่างสองงาน ซึ่งหมายความว่าประเภทของมันไม่เหมาะสำหรับการแก้ปัญหาอย่างใดอย่างหนึ่ง)

วิธีการ

มาดูการนำตรรกะของเราไปใช้โดยตรงนั่นคือกับวิธีการต่างๆ

1. กฎข้อแรกคือความกะทัดรัด ตามหลักการแล้ว วิธีการหนึ่งไม่ควรเกิน 20 บรรทัด ดังนั้น หากวิธีสาธารณะ "ขยาย" อย่างมีนัยสำคัญ คุณต้องคิดถึงการย้ายตรรกะที่แยกออกไปเป็นวิธีการส่วนตัว

2. กฎข้อที่สองคือบล็อกในคำสั่งif, elseและwhileอื่นๆ ไม่ควรซ้อนกันอย่างมาก ซึ่งจะช่วยลดความสามารถในการอ่านโค้ดได้อย่างมาก {}ตามหลักการแล้ว การซ้อนไม่ควรเกินสองช่วงตึก

   ขอแนะนำให้สร้างโค้ดในบล็อกเหล่านี้ให้กะทัดรัดและเรียบง่าย

3. กฎข้อที่สามคือวิธีการจะต้องดำเนินการเพียงครั้งเดียวเท่านั้น นั่นคือ ถ้าวิธีการใดใช้ตรรกะที่ซับซ้อนและหลากหลาย เราจะแบ่งวิธีการนั้นออกเป็นวิธีการย่อย เป็นผลให้วิธีการนั้นจะเป็นส่วนหน้าโดยมีจุดประสงค์เพื่อเรียกการดำเนินการอื่น ๆ ทั้งหมดตามลำดับที่ถูกต้อง

   แต่จะเกิดอะไรขึ้นถ้าการดำเนินการดูเหมือนง่ายเกินไปที่จะสร้างวิธีการแยกต่างหาก? ใช่ บางครั้งอาจดูเหมือนการยิงนกกระจอกออกจากปืนใหญ่ แต่วิธีการเล็กๆ น้อยๆ ให้ประโยชน์หลายประการ:

   • อ่านโค้ดได้ง่ายขึ้น
   • วิธีการมีแนวโน้มที่จะซับซ้อนมากขึ้นในระหว่างการพัฒนา และหากวิธีการนั้นง่ายในตอนแรก การทำให้ฟังก์ชันการทำงานซับซ้อนขึ้นก็จะง่ายขึ้นเล็กน้อย
   • การซ่อนรายละเอียดการใช้งาน
   • อำนวยความสะดวกในการใช้โค้ดซ้ำ
   • ความน่าเชื่อถือของโค้ดที่สูงขึ้น

4. กฎด้านล่างคือควรอ่านโค้ดจากบนลงล่าง: ยิ่งต่ำ ยิ่งมีความลึกของตรรกะมากขึ้น และในทางกลับกัน ยิ่งสูงเท่าใด วิธีการที่เป็นนามธรรมก็จะมากขึ้นเท่านั้น ตัวอย่างเช่น คำสั่ง switch ค่อนข้างไม่กระชับและไม่เป็นที่พึงปรารถนา แต่ถ้าคุณทำไม่ได้โดยไม่ต้องใช้สวิตช์ คุณควรพยายามย้ายคำสั่งให้ต่ำที่สุดไปยังวิธีระดับต่ำสุด

5. อาร์กิวเมนต์ของวิธีการ - มีกี่ข้อในอุดมคติ? ตามหลักการแล้วไม่มีเลย)) แต่สิ่งนั้นจะเกิดขึ้นจริงหรือ? อย่างไรก็ตาม คุณควรพยายามมีให้น้อยที่สุดเท่าที่จะเป็นไปได้ เพราะยิ่งมีน้อยเท่าไร การใช้วิธีนี้ก็จะง่ายขึ้นและทดสอบได้ง่ายขึ้นด้วย หากมีข้อสงสัย ให้ลองเดาสถานการณ์ทั้งหมดสำหรับการใช้วิธีการที่มีอาร์กิวเมนต์อินพุตจำนวนมาก

6. แยกกัน ฉันต้องการเน้นวิธีการที่มีการตั้งค่าสถานะบูลีน เป็นอาร์กิวเมนต์อินพุต เนื่องจากนี่บอกเป็นนัยโดยธรรมชาติว่าวิธีนี้ใช้การดำเนินการมากกว่าหนึ่งรายการ (หากเป็นจริงแล้วหนึ่งรายการ เท็จ - อีกรายการหนึ่ง) ตามที่ฉันเขียนไว้ข้างต้น สิ่งนี้ไม่ดี และควรหลีกเลี่ยงหากเป็นไปได้

7. ถ้าเมธอดมีอาร์กิวเมนต์ขาเข้าจำนวนมาก (ค่าสูงสุดคือ 7 แต่คุณควรพิจารณาหลังจาก 2-3) คุณจะต้องจัดกลุ่มอาร์กิวเมนต์บางส่วนในออบเจ็กต์ที่แยกจากกัน

8. หากมีวิธีการที่คล้ายกันหลายวิธี (โอเวอร์โหลด)จะต้องส่งพารามิเตอร์ที่คล้ายกันในลำดับเดียวกัน ซึ่งจะเพิ่มความสามารถในการอ่านและการใช้งาน

9. เมื่อคุณส่งพารามิเตอร์ไปยังเมธอด คุณต้องแน่ใจว่าพวกมันจะถูกใช้ทั้งหมด ไม่อย่างนั้นอาร์กิวเมนต์มีไว้เพื่ออะไร? ตัดมันออกจากอินเทอร์เฟซก็แค่นั้นแหละ

10. try/catchมันไม่ได้ดูสวยงามนักโดยธรรมชาติ ดังนั้นการย้ายที่ดีคือย้ายมันไปไว้ในวิธีที่แยกจากกันระดับกลาง (วิธีจัดการกับข้อยกเว้น):

    public void exceptionHandling(SomeObject obj) {
        try {
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

ฉันพูดถึงการทำซ้ำโค้ดด้านบน แต่ฉันจะเพิ่มมันไว้ที่นี่: หากเรามีวิธีการสองสามวิธีที่มีการทำซ้ำบางส่วนของโค้ด เราจำเป็นต้องย้ายมันไปไว้ในวิธีอื่น ซึ่งจะเพิ่มความกระชับของทั้งวิธีและ ระดับ. และอย่าลืมเกี่ยวกับชื่อที่ถูกต้อง ฉันจะบอกรายละเอียดการตั้งชื่อคลาส อินเทอร์เฟซ วิธีการ และตัวแปรที่ถูกต้องให้คุณทราบในส่วนถัดไปของบทความ และนั่นคือทั้งหมดที่ฉันมีสำหรับวันนี้ กฎเกณฑ์: พลังของการตั้งชื่อที่ถูกต้อง ความคิดเห็นที่ดีและไม่ดี