เทคนิคการลดจำนวนอาร์กิวเมนต์ของฟังก์ชันให้น้อยที่สุด

ในรหัสที่สะอาดมันถูกเขียนขึ้นว่า "จำนวนอาร์กิวเมนต์ที่เหมาะสมที่สุดสำหรับฟังก์ชั่นเป็นศูนย์" เหตุผลที่อธิบายและเข้าใจได้ง่าย สิ่งที่ฉันตามมาคือเทคนิคในการปรับเปลี่ยนวิธีด้วยอาร์กิวเมนต์ 4 ตัวขึ้นไปเพื่อแก้ปัญหานี้

วิธีหนึ่งคือการแยกอาร์กิวเมนต์ไปยังคลาสใหม่ แต่นั่นจะนำไปสู่การระเบิดของคลาสอย่างแน่นอนหรือไม่ และคลาสเหล่านั้นมีแนวโน้มที่จะจบลงด้วยชื่อที่ละเมิดกฎการตั้งชื่อบางอย่าง (ลงท้ายด้วย "Data" หรือ "Info" ฯลฯ ) หรือไม่

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

เพียงมองหาวิธีลดอาร์กิวเมนต์ของฟังก์ชันให้เล็กที่สุดโดยยอมรับเหตุผลว่าทำไมจึงเป็นความคิดที่ดี

สิ่งที่สำคัญที่สุดที่ควรจดจำคือสิ่งเหล่านี้เป็นแนวทางไม่ใช่กฎ

มีหลายกรณีที่วิธีการนั้นจะต้องมีการโต้แย้ง ลองนึกถึง+วิธีการหาตัวเลขเช่น หรือaddวิธีการรวบรวม

ในความเป็นจริงเราอาจโต้แย้งว่าการเพิ่มสองตัวเลขนั้นขึ้นอยู่กับบริบทเช่นในℤ 3 + 3 == 6แต่ในℤ _{| 5} 3 + 3 == 2ดังนั้นผู้ดำเนินการเพิ่มเติมควรเป็นวิธีการในวัตถุบริบทที่รับสองอาร์กิวเมนต์แทน วิธีการเกี่ยวกับตัวเลขที่ใช้เวลาหนึ่งอาร์กิวเมนต์

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

ที่กล่าวว่ามีสองสามสิ่งที่สามารถทำได้เพื่อลดจำนวนอาร์กิวเมนต์สำหรับวิธีการ:

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

วิธีหนึ่งคือการแยกอาร์กิวเมนต์ไปยังคลาสใหม่ แต่นั่นจะนำไปสู่การระเบิดของคลาสอย่างแน่นอนหรือไม่

หากโมเดลโดเมนของคุณมีหลาย ๆ ประเภทรหัสของคุณก็จะจบลงด้วยวัตถุประเภทต่างๆ ไม่มีอะไรผิดปกติกับสิ่งนั้น

และคลาสเหล่านั้นมีแนวโน้มที่จะจบลงด้วยชื่อที่ละเมิดกฎการตั้งชื่อบางอย่าง (ลงท้ายด้วย "Data" หรือ "Info" ฯลฯ ) หรือไม่

หากคุณไม่สามารถหาชื่อที่เหมาะสมได้บางทีคุณอาจจัดกลุ่มข้อโต้แย้งมากเกินไปหรือน้อยเกินไป ดังนั้นคุณอาจมีเพียงบางส่วนของคลาสหรือคุณมีมากกว่าหนึ่งคลาส

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

หากคุณมีกลุ่มของวิธีการทั้งหมดที่ใช้งานบนอาร์กิวเมนต์เดียวกันและกลุ่มของวิธีการอื่นที่ไม่มีพวกเขาอาจอยู่ในชั้นเรียนที่แตกต่างกัน

สังเกตว่าฉันใช้คำว่า "อาจจะ" บ่อยแค่ไหน? นั่นเป็นสาเหตุที่เป็นแนวทางไม่ใช่กฎ บางทีวิธีการของคุณที่มี 4 พารามิเตอร์นั้นดีมาก!

โปรดทราบว่าศูนย์ข้อโต้แย้งไม่ได้บ่งบอกถึงผลข้างเคียงเพราะวัตถุของคุณเป็นข้อโต้แย้งโดยปริยาย ดูวิธีการหลายวิธีการศูนย์ arity รายการเปลี่ยนรูป Scala ของมีตัวอย่างเช่น

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

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

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

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

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

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

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

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

ไม่มีวิธีที่มหัศจรรย์: คุณต้องเชี่ยวชาญโดเมนปัญหาเพื่อค้นหาสถาปัตยกรรมที่เหมาะสม นั่นเป็นวิธีเดียวในการ refactor: การควบคุมโดเมนปัญหา มากกว่าสี่พารามิเตอร์เป็นเพียงการเดิมพันที่แน่นอนว่าสถาปัตยกรรมปัจจุบันของคุณผิดพลาดและผิด

ข้อยกเว้นเพียงอย่างเดียวคือคอมไพเลอร์ (metaprograms) และแบบจำลองโดยที่ค่า จำกัด นั้นเป็นไปตามทฤษฎี 8 แต่อาจเป็นเพียง 5 เท่านั้น