ชื่อวิธีการที่“ บวก” และ“ ลบ” เหมาะสมหรือไม่


21

Java SE 8 มาพร้อมกับกลไกใหม่สำหรับวันที่แนะนำLocalDate, LocalTimeและLocalDateTimeชั้นเรียนเพื่อเป็นตัวแทนของจังหวะเวลา เพื่อจัดการกับจังหวะดังกล่าวเป็นชุดของวิธีการที่จะได้รับ: LocalDate.plusDays(...), LocalDate.minusDays(...)และอื่น ๆ

ฉันคิดเสมอว่าวิธีปฏิบัติที่ดีคือการตั้งชื่อวิธีการหลังจากคำกริยาอธิบายถึงจุดประสงค์ของพวกเขาเช่นเดียวกับวิธีการที่เป็นจริงการดำเนินการที่จะดำเนินการสิ่งที่จะดำเนินการ เพียงแค่พูดถึงถ้าคุณพิจารณาการเรียนเหมือนStringBuilderเช่นชื่อวิธีการมีappend, insert, delete...

นี่คือเหตุผลที่ฉันก็ไม่ได้เสียงที่เหมาะสมในการตั้งชื่อวิธีการplusDaysแทนsumDays, แทนminusDays subtractDaysฉันแค่พบว่ามันน่ารำคาญมาก? คุณคิดอย่างไร?

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


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

2
การเขียนโปรแกรมไม่ใช่ "ภาษาอังกฤษ" ตัวอย่างเช่นsqrtเป็นเพียงคำที่โปรแกรมเมอร์คาดว่าจะรับรู้และรู้ คำภาษาอังกฤษคือ "สแควร์รูท" โดยวิธี แต่การตั้งชื่อสิ่งต่าง ๆ ตามสิ่งที่เป็นธรรมชาติในภาษาอังกฤษนั้นไม่ดี ใช้คำว่า "ผิดกฎหมาย" ตัวอย่างเช่นคำภาษาอังกฤษที่ดีอย่างสมบูรณ์แบบ อย่างไรก็ตามถ้ามีคนตั้งชื่อวิธีการของพวกเขาบอกว่าisIllicitฉันคิดว่าฉันต้องการที่จะฉีกดวงตาของฉันทุกครั้งที่ฉันดูวิธีการโทรนี้ มันดูน่ากลัวและต้องมีวิธีที่ดีกว่าในการแสดงความคิดเห็น
Brandin

18
sumฟังดูผิดในบริบทนี้ AddDaysฉันชอบของสุทธิ
CodesInChaos

3
@LuigiCortese ชื่อวิธีการที่ถูกเลือกให้ตรงกับคำสั่งภาษาอังกฤษทั่วไป Math.addExact(1, 2)เพราะคุณพูดว่า "เพิ่ม 1 และ 2" tomorrow.plusDays(2)เพราะคุณพูดว่า "พรุ่งนี้บวก 2 วัน" หากaddExactเป็นสมาชิกของอย่างใดก็จะได้รับInteger 1.plusExact(2)
Tavian Barnes

8
โดยส่วนตัวแล้วฉันคาดหวังว่าplusDaysจะได้วันที่ใหม่จำนวน x วันในอนาคตในขณะที่addDaysฉันอาจคาดว่าจะกลายพันธุ์วัตถุต้นฉบับ นั่นเป็นเพียงฉัน แต่ฉันไม่ใช่ทุกคนที่คุ้นเคยกับ Java
Ajedi32

คำตอบ:


52

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

นี่คือเหตุผลที่แน่นอน ลองนึกภาพคุณมี API บางอย่างสำหรับจัดการช่วงวันที่เพื่อการกำหนดตารางเวลา มันอาจแสดงวิธีการที่ให้คุณทำคำสั่งเช่น:

var workdaySchedule = initialSchedule.withoutWeekends();

สิ่งนี้อ่านคล้ายกับคำแถลงภาษาอังกฤษ: "ตารางวันทำงานเป็นตารางเริ่มต้นที่ไม่มีวันหยุดสุดสัปดาห์" มันไม่ได้หมายถึงการเปลี่ยนแปลงกำหนดการเริ่มต้นมันหมายถึงตารางการทำงานที่เป็นสิ่งใหม่ที่แตกต่างกัน

ทีนี้ลองจินตนาการว่ามันมีชื่อว่า:

var workdaySchedule = initialSchedule.removeWeekends();

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


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

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


13
ที่จริงฉันมีปัญหากับaddDaysเมื่อplusDaysวานนี้! ใน .NET ที่DateTimeชั้นมีวิธีการที่เรียกว่าaddDays, และaddMonths addYearsฉันสร้างวิธีการแยกวิเคราะห์วันที่สัมพัทธ์ (1 ปี, 2 เดือน, 3 วันที่ผ่านมา) และเรียกว่าวิธีการดังกล่าวที่คิดว่าพวกเขากำลังแก้ไขDateTimeวัตถุปัจจุบัน ทุกวันในฐานข้อมูลสิ้นสุดวันที่ 8 มิถุนายน 2558 "มันตลกดี" ฉันคิดว่า นั่นคือเมื่อผมจำได้ว่าaddDaysไม่ปรับเปลี่ยนDateTimeวัตถุก็จะส่งกลับใหม่หนึ่ง +1 จึงรอบสำหรับคำถามนี้
เกร็ก Burghardt

1
@GregBurghardt ในฐานะผู้ใช้. NET ฉันมีความคาดหวังที่ตรงกันข้าม ฉันเดาว่านี่หมายความว่า "บวก" และ "เพิ่ม" เท่านั้นที่สามารถแลกเปลี่ยนได้ไม่ใช่การจับคู่โดยตรงกับ+และ+=
Agent_L

2
@Agent_L นั่นน่าสนใจ การประชุม. NET กัน "เพิ่ม" และ "บวก" ไม่สามารถใช้แทนกันในภาษาอังกฤษ
Ben Aaronson

1
นอกจากนี้สำหรับวันที่และเวลามันเป็นเรื่องธรรมดาที่จะพูดถึง D + 1, H + 12 และอื่น ๆ เพื่ออ้างอิงเวลาที่สัมพันธ์กับแหล่งกำเนิดที่เฉพาะเจาะจง (เช่นสำหรับการบินอวกาศ T-10, T-9 ฯลฯ ) โดยทั่วไปจะอ่านว่าเป็น D-plus-1, H-plus-12, T-ลบ -10 อาจเป็นศูนย์กลางของสหรัฐอเมริกา แต่นั่นเป็นลักษณะที่ปรากฏแก่ฉัน
Kristian H


2

ใน. NET การตั้งชื่อจะแตกต่างกันแม้ว่าผลลัพธ์จะเหมือนกันทุกประการ แทน:

tomorrow = LocalDateTime.plusDays(1);

มี:

tomorrow = DateTime.Now.AddDays(1);

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


-1

นี่อาจเป็นสิ่งประดิษฐ์ของ Java ที่ใช้.Methodสำหรับวิธีการทั้งหมดทั้งที่แก้ไขวัตถุและสิ่งที่ไม่ทำ

ลองนึกภาพภาษาซึ่งยังมีobject=>methodไวยากรณ์ซึ่งจะให้methodสำเนาของวัตถุที่จะทำงานใน ตอนนี้ในภาษาดังกล่าวstartDate=>plusDays(5)ชัดเจนอย่างไม่น่าสงสัย จะใช้วันที่ดั้งเดิมและสร้างวันที่ใหม่ซึ่งเป็น 5 วันต่อมา

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.