ทำไมการใช้ conjunctions ในเมธอดจึงตั้งชื่อแผนการประชุมที่ไม่ดี? [ปิด]

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

โครงการของเราประกอบด้วยฟังก์ชันแบ็คเอนด์ส่วนใหญ่ที่ใช้ใน PHP โดยใช้เฟรมเวิร์ก Symfony 2 ดังนั้น syntactically รหัส, การตั้งชื่อแบบแผนและโครงสร้างโครงการดูเหมือนเกือบจะเหมือนกับสิ่งที่ Java จะมีลักษณะ (Symfony 2 สนับสนุนโครงสร้างดังกล่าว) ฉันกำลังพูดถึงเรื่องนี้เพราะอนุสัญญาเฉพาะ Java ยังใช้ในกรณีของเรา (ถ้าเป็นไปได้)

เมื่อเร็ว ๆ นี้พวกเขาชี้ให้เห็นบางสิ่งบางอย่างที่ผมพบที่แปลกมาก: วิธีการทั้งหมดที่ควรจะมีในสันธานเช่นชื่อของพวกเขาgetEntityOrNull, setValueOrExceptionฯลฯ

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

สิ่งเดียวที่ฉันคิดไว้คือ:

• ข้อมูลดังกล่าวควรมีอยู่ในคำอธิบายประกอบของวิธีเช่น@returnหรือ@throws
• การใช้คำสันธาน ("และ", "หรือ" ฯลฯ ) ในชื่อวิธีมักจะแนะนำว่าหลักการความรับผิดชอบเดี่ยวไม่ได้รับการเคารพอย่างเหมาะสม

อะไรคือข้อโต้แย้งที่เป็นรูปธรรมอื่น ๆ ต่ออนุสัญญาการตั้งชื่อนี้

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

สำหรับคนหนึ่งฉันไม่ชอบการฝึกฝนที่มีวิธีต่าง ๆ มากมายในการเรียกวิธีการเดียวกันเว้นแต่ว่ามันจะทำการเปลี่ยนแปลงบางอย่างที่มีเพียงคลาสนั้นเท่านั้นที่สามารถทำได้

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

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

แม้ว่าการใช้ conjunctions มักจะบ่งบอกถึงการละเมิด SRP ในกรณีนี้มันเป็นเพียงการแสดงค่าส่งคืนของชนิดข้อมูลพีชคณิตของชายยากจนที่สามารถเป็นหนึ่งในสองค่าไม่ว่าจะnullเป็นหรือ "ความสำเร็จ" ตามตัวอักษร

พวกเขาใช้สัญกรณ์ฮังการีเพื่อชดเชยจุดอ่อนในระบบการพิมพ์นั่นคือการขาดประเภทที่ไม่เป็นโมฆะ กล่าวอีกนัยหนึ่งไม่มีวิธีที่จะระบุใน@returnคำอธิบายประกอบที่ฟังก์ชันจะไม่ส่งคืนnullและตรงกันข้ามไม่มีวิธีที่จะระบุใน@returnคำอธิบายประกอบของคุณว่าฟังก์ชันอาจส่งคืนnullได้

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

เนื่องจากข้อ จำกัด ของภาษาที่คุณใช้อยู่นั้นไม่ใช่สไตล์ที่ไม่สมเหตุสมผลทั้งหมด

ในรหัสของฉันฉันบางครั้งสร้างวิธีการจับคู่กับชื่อเช่น getEntity () และ getEntityOrNull () ชื่อทำให้พฤติกรรมที่คาดหวังชัดเจน ถ้า getEntity () ไม่พบเอนทิตีแล้วจะมีข้อผิดพลาดเกิดขึ้น getEntityOrNull () จะคืนค่า null

โดยการทำเช่นนี้รหัสโทรจะชัดเจนขึ้นเล็กน้อย หากรหัสการโทรต้องมีเอนทิตีแล้ว getEntity จะทำการหลอกลวง หากเอนทิตีเป็นประเภทของสิ่งที่เลือกได้ getEntityOrNull เป็นวิธีการเลือก

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

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

ไม่เคยเห็นเมธอด setValueOrException จริงๆ ไม่สามารถนึกถึงกรณีการใช้งานทั่วไปที่ดีสำหรับสิ่งนั้นได้

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

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

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