การ จำกัด จำนวนวิธีการเรียนคืออะไร

ในหนังสือการออกแบบที่แตกต่างกันที่ฉันอ่านบางครั้งการเน้นอย่างมากถูกวางลงบนจำนวนวิธีที่ชั้นเรียนต้องมี (พิจารณาจากภาษา OO เช่น java หรือ C # เป็นต้น) บ่อยครั้งที่ตัวอย่างที่รายงานในหนังสือเหล่านี้มีความประณีตและเรียบง่าย แต่แทบจะไม่ครอบคลุมกรณีที่ "ร้ายแรง" หรือซับซ้อน
อย่างไรก็ตามช่วงนี้ดูเหมือนจะอยู่ระหว่าง 5 ถึง 8

ในโครงการฉันได้พัฒนาคลาส "Note" โดยมีคุณสมบัติเป็น attribuse: Title, Desctiption, CreateDate เป็นต้น
จากนั้นมีวิธีการพื้นฐานเช่น: getRelations (ถ้าบันทึกถูกกำหนดให้กับเอกสารต่าง ๆ ), getExpiryDate, ect

อย่างไรก็ตามการดำเนินการในการพัฒนาแอปพลิเคชันจำเป็นต้องมีฟังก์ชันการทำงานที่มากขึ้นและดังนั้นจึงมีวิธีการมากขึ้น

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

ฉันยอมรับว่ามีมากกว่า 15 วิธีจากนั้นอาจต้องมีการออกแบบใหม่เล็กน้อย
แต่แม้ในกรณีนั้นหากการลบวิธีการหรือมรดกบางอย่างไม่ใช่ตัวเลือกซึ่งจะเป็นวิธีที่เหมาะสมหรือไม่

มีวิธีการมากมายเท่าที่คุณต้องการ ฉันจะพยายามลดจำนวนวิธีสาธารณะต่อกฎ 5-8 นั้นถ้าเป็นไปได้ สุจริตคนส่วนใหญ่มีปัญหาตรงข้ามที่พวกเขามีวิธีการที่บ้าสุด ๆ ที่ต้องแตกสลายมากขึ้นไม่น้อย มันไม่สำคัญว่าคุณมีวิธีช่วยเหลือส่วนตัวมากมายแค่ไหน ในความเป็นจริงถ้าคุณอยู่ต่ำกว่า 8 วิธีใน Java คุณสามารถกดขีด จำกัด ด้วยคลาสที่มีเพียงนวกรรมิก, toString และ getter / setter สำหรับ 3 คุณสมบัติ ... ซึ่งไม่ใช่คลาสที่สมบูรณ์ บรรทัดล่างคือไม่ต้องกังวลเกี่ยวกับวิธีการเรียนของคุณ กังวลเกี่ยวกับการทำให้แน่ใจว่าชั้นเรียนของคุณไม่กังวลกับเรื่องที่ไม่เกี่ยวข้องและคุณมีอินเทอร์เฟซสาธารณะที่สมเหตุสมผลและมีวิธีการที่เข้าใจง่าย

คำตอบนั้นง่ายมากใส่ทุกอย่างในชั้นเรียนที่เป็นความรับผิดชอบ แต่ระวังเมื่อมอบหมายความรับผิดชอบ

บางครั้งชนชั้นสูงจะประกอบไปด้วยคลาสย่อยที่มีความรับผิดชอบแตกต่างกัน

โดยทั่วไปแล้วฉันพยายามแบ่งความรับผิดชอบเป็นชั้นเรียนขนาดเล็กเมื่อชั้นเรียนมีการใช้งานหรือบำรุงรักษาไม่สะดวก ฉันไม่ค่อยมีชั้นเรียนที่ยาวเกิน 500 บรรทัด คลาสที่ใหญ่ที่สุดของฉันมีตำแหน่ง 1.5k โดยประมาณ

คุณไม่สามารถระบุกฎทั่วไปเช่น "คลาสควรมีวิธีระหว่าง n และ m"

ไม่มีเหตุผล (ในการออกแบบ OO) สำหรับการมีวิธีการมากมายเท่านั้น ยังไม่เป็นความจริงที่คลาสที่มีวิธีการน้อยกว่านั้นจะแยกกันได้ดีกว่า

ดูคลาส java.lang.String ตัวอย่าง มีวิธีการมากมายเนื่องจากมีหลายสิ่งที่เราสามารถทำได้ด้วยสตริง อย่างไรก็ตามไม่ได้คู่อย่างยิ่ง

ฉันสงสัยว่าทำไมเลขอาถรรพ์อย่าง 15 สามารถแยกการออกแบบที่ดีและไม่ดี ไม่มันไม่ง่ายเลย

ใน PMD พฤติกรรมเริ่มต้นของกฎ TooManyMethodsคือการระบุและตั้งค่าสถานะคลาสด้วย 10 วิธีขึ้นไปเป็นข้อผิดพลาดที่อาจเกิดขึ้น นี่เป็นเพียงตัวเลขโดยพลการ มันเปลี่ยนแปลงได้อย่างง่ายดายในการกำหนดค่า ไม่ว่าตัวเลขนี้จะเป็นอะไรมันเป็นเพียงแค่ธงสำหรับนักพัฒนาในการดูชั้นเรียนและดูว่ามีปัญหาหรือไม่ไม่ใช่ว่ามีปัญหากับมัน

สิ่งที่เป็นรูปธรรมมากขึ้นเล็ก ๆ น้อย ๆ อาจจะเป็น7 บวก / ลบ 2 กฎ นี้ระบุว่าจิตใจมนุษย์สามารถถือและเข้าใจระหว่าง 5 และ 9 "วัตถุ" ในความทรงจำ เมื่ออ่านคลาสเฉพาะวัตถุน่าจะเป็นวิธีการและฟิลด์ที่ประกอบขึ้นเป็นคลาสนั้น อย่างไรก็ตามการเรียนมักมีมากกว่า 9 สาขาและวิธีแม้ว่าคุณจะไม่นับรวม accessors, mutators มาตรฐานและการดำเนินงานใด ๆ (เช่นtoString(), hashCode()และequals()ในชวา)

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