การตั้งชื่อคลาส - วิธีหลีกเลี่ยงการเรียกทุกอย่างว่า“ <WhatEver> Manager” ได้อย่างไร [ปิด]

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

ตัวอย่างเช่นหากแอปพลิเคชันของฉัน (เป็นแอปทางธุรกิจทั่วไป) ที่จัดการผู้ใช้ บริษัท และที่อยู่ที่ฉันมีคลาสUsera Companyและa Addressโดเมนและอาจเป็นที่ไหนสักแห่งUserManagera CompanyManagerและa AddressManagerจะปรากฏขึ้นเพื่อจัดการกับสิ่งเหล่านั้น

ดังนั้นคุณสามารถบอกบรรดาสิ่งUserManager, CompanyManagerและAddressManagerทำอย่างไร ไม่เพราะผู้จัดการเป็นคำทั่วไปที่เหมาะกับทุกสิ่งที่คุณสามารถทำได้กับวัตถุโดเมนของคุณ

บทความที่ฉันอ่านแนะนำโดยใช้ชื่อเฉพาะมาก ถ้ามันเป็นแอพพลิเคชั่น C ++ และUserManagerงานของมันถูกจัดสรรและปลดปล่อยผู้ใช้จากฮีปมันจะไม่จัดการผู้ใช้ แต่ปกป้องการเกิดและความตาย อืมเราอาจเรียกมันUserShepherdว่า

หรืออาจจะUserManagerเป็นหน้าที่ของการตรวจสอบข้อมูลของวัตถุผู้ใช้แต่ละคนและลงนามในข้อมูลการเข้ารหัส UserRecordsClerkแล้วเราต้องการมี

ตอนนี้ความคิดนี้ติดอยู่กับฉันฉันพยายามที่จะใช้มัน และพบว่าความคิดที่เรียบง่ายนี้ยากอย่างน่าอัศจรรย์

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

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

• โรงงาน - สร้างวัตถุอื่น ๆ (การตั้งชื่อที่นำมาจากรูปแบบการออกแบบ)
• Shepherd - คนเลี้ยงแกะจัดการกับอายุของวัตถุการสร้างและการปิด
• ซิงโครไนซ์ - คัดลอกข้อมูลระหว่างวัตถุสองชิ้นขึ้นไป (หรือลำดับชั้นวัตถุ)

• Nanny - ช่วยให้วัตถุเข้าถึงสภาวะ "ใช้งานได้" หลังการสร้างตัวอย่างเช่นโดยการเดินสายไปยังวัตถุอื่น

• ฯลฯ

ดังนั้นคุณจะจัดการกับปัญหานั้นได้อย่างไร คุณมีคำศัพท์ที่ตายตัวคุณสร้างชื่อใหม่ได้ทันทีหรือคุณคิดว่าการตั้งชื่อไม่สำคัญหรือผิด

PS: ฉันสนใจในการเชื่อมโยงไปยังบทความและบล็อกที่พูดถึงปัญหา เป็นการเริ่มต้นที่นี่เป็นบทความต้นฉบับที่ทำให้ฉันนึกถึง: การตั้งชื่อ Java Classes ที่ไม่มี 'Manager'

อัปเดต: สรุปคำตอบ

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

• พยายามอย่าสร้างคำอุปมาอุปมัยใหม่ (พี่เลี้ยง)
• ดูที่กรอบอื่น ๆ ทำ

บทความ / หนังสือเพิ่มเติมในหัวข้อนี้:

• คุณคิดว่าชื่ออะไรที่คุณกำลังต่อเติม / ต่อท้ายชั้นเรียนเป็นประจำ
• วิธีที่ดีที่สุดในการตั้งชื่อคลาสคืออะไร
• หนังสือ: รูปแบบการออกแบบ: องค์ประกอบของซอฟต์แวร์เชิงวัตถุที่ใช้ซ้ำได้ (ปกแข็ง)
• หนังสือ: รูปแบบของสถาปัตยกรรมแอปพลิเคชันองค์กร (ปกแข็ง)
• Book: Implementation Patterns (หนังสือปกอ่อน)

และรายการปัจจุบันของคำนำหน้าชื่อ / คำต่อท้ายที่ฉันรวบรวม (ส่วนตัว) จากคำตอบ:

• ผู้ประสาน
• ผู้ก่อสร้าง
• นักเขียน
• ผู้อ่าน
• ผู้ดำเนินการ
• ภาชนะ
• มาตรการ
• เป้า
• แปลง
• ตัวควบคุม
• ดู
• โรงงาน
• เอกลักษณ์
• ถัง

และเคล็ดลับที่ดีสำหรับถนน:

อย่าตั้งชื่ออัมพาต ใช่ชื่อมีความสำคัญมาก แต่ไม่สำคัญพอที่จะเสียเวลาเป็นจำนวนมาก หากคุณไม่สามารถคิดชื่อที่ดีภายใน 10 นาทีให้ไปต่อ

ฉันถามคำถามที่คล้ายกันแต่ถ้าเป็นไปได้ฉันพยายามที่จะคัดลอกชื่อที่มีอยู่แล้วใน. NET Framework และฉันมองหาแนวคิดในJavaและAndroid frameworks

ดูเหมือนว่าHelper, ManagerและUtilเป็นคำนามที่หลีกเลี่ยงไม่ได้คุณแนบในการประสานงานการเรียนที่มีรัฐไม่มีและโดยทั่วไปจะมีขั้นตอนและแบบคงที่ Coordinatorทางเลือกคือ

คุณสามารถได้รับ prosey สีม่วงโดยเฉพาะอย่างยิ่งที่มีชื่อและไปสำหรับสิ่งที่ต้องการMinder, Overseer, Supervisor, AdministratorและMasterแต่ที่ผมบอกว่าผมชอบทำให้มันเช่นชื่อกรอบที่คุณใช้ในการ

คำต่อท้ายทั่วไปอื่น ๆ (ถ้านั่นคือคำที่ถูกต้อง) คุณยังพบใน. NET Framework คือ:

• Builder
• Writer
• Reader
• Handler
• Container

คุณสามารถดูที่source-code-wordle.deฉันได้วิเคราะห์ส่วนต่อท้ายที่ใช้บ่อยที่สุดของชื่อคลาสของ. NET Framework และไลบรารี่อื่น ๆ

20 อันดับแรกคือ:

• คุณลักษณะ
• ชนิด
• ผู้ช่วย
• ชุด
• แปลง
• ผู้ดำเนินการ
• ข้อมูล
• ผู้ให้บริการ
• ข้อยกเว้น
• บริการ
• ธาตุ
• ผู้จัดการ
• ปม
• ตัวเลือก
• โรงงาน
• บริบท
• สิ่งของ
• นักออกแบบ
• ฐาน
• บรรณาธิการ

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

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

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

เราสามารถทำได้โดยไม่ต้องใด ๆxxxFactory, xxxManagerหรือxxxRepositoryการเรียนถ้าเราสร้างแบบจำลองโลกแห่งความจริงอย่างถูกต้อง:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)

ดูเหมือนความลาดชันของสิ่งที่จะถูกโพสต์ใน thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages" เป็นต้น

ฉันคิดว่ามันถูกต้องว่าคลาส monolithic Manager หนึ่งตัวนั้นไม่ดีนัก แต่การใช้ 'Manager' นั้นไม่เลวเลย แทนที่จะเป็น UserManager เราอาจแยกย่อยเป็น UserAccountManager, UserProfileManager, UserSecurityManager เป็นต้น

'ผู้จัดการ' เป็นคำที่ดีเพราะมันแสดงให้เห็นอย่างชัดเจนว่าชั้นเรียนไม่ได้หมายถึง 'สิ่ง' ในโลกแห่งความเป็นจริง 'AccountsClerk' - ฉันจะบอกได้อย่างไรว่าเป็นชั้นเรียนที่จัดการข้อมูลผู้ใช้หรือแสดงถึงคนที่เป็นพนักงานบัญชีสำหรับงานของพวกเขา

เนื่องจากคุณสนใจบทความในด้านนี้คุณอาจสนใจบทความความคิดเห็นของ Steve Yegge "การดำเนินการในราชอาณาจักรคำนาม":

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

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

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

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

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

au fait ที่มีรูปแบบตามที่กำหนดโดย (พูด) หนังสือ GOFและการตั้งชื่อวัตถุหลังจากสิ่งเหล่านี้ทำให้ฉันอยู่ในชั้นเรียนการตั้งชื่อจัดระเบียบพวกเขาและสื่อสารเจตนา คนส่วนใหญ่จะเข้าใจคำศัพท์นี้ (หรืออย่างน้อยก็เป็นส่วนสำคัญของมัน)

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

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

ตัวฉันเองใช้รูปแบบซุ้มมาก (อย่างน้อยฉันคิดว่านั่นคือสิ่งที่เรียกว่า) ฉันสามารถมีUserคลาสที่อธิบายผู้ใช้เพียงคนเดียวและUsersคลาสที่ติดตาม "กลุ่มผู้ใช้" ของฉัน ฉันไม่เรียกชั้นเรียนUserManagerเพราะฉันไม่ชอบผู้จัดการในชีวิตจริงและฉันไม่ต้องการให้พวกเขานึกถึง :) การใช้รูปแบบพหูพจน์ช่วยให้ฉันเข้าใจสิ่งที่ชั้นเรียนทำ

เฉพาะ C # ฉันพบ"แนวทางการออกแบบกรอบ: อนุสัญญาสำนวนและรูปแบบสำหรับ. NET Library ที่นำกลับมาใช้ใหม่"เพื่อให้ได้ข้อมูลที่ดีเกี่ยวกับตรรกะของการตั้งชื่อ

เท่าที่พบคำที่เฉพาะเจาะจงเหล่านั้นแม้ว่าฉันมักจะใช้อรรถาภิธานและข้ามคำที่เกี่ยวข้องเพื่อพยายามค้นหาคำที่ดี ฉันพยายามที่จะไม่ใช้เวลากับมันมากแม้ว่าเมื่อฉันผ่านการพัฒนาฉันก็จะมีชื่อที่ดีขึ้นหรือบางครั้งก็รู้ว่าSuchAndSuchManagerควรจะแบ่งออกเป็นหลายคลาสและจากนั้นชื่อของคลาสที่เลิกใช้แล้วจะกลายเป็นปัญหา .

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

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

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

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

ดูหนังสือเช่นรูปแบบการออกแบบเพื่อดูข้อมูลมันเป็นหนังสือที่ยอดเยี่ยมและอาจช่วยให้คุณเข้าใจได้ว่าคุณต้องการให้โค้ดของคุณอยู่ตรงไหน - ถ้าคุณยังไม่ได้ใช้มัน! ; o)

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