ปัญหาการตั้งชื่อ: ควรเปลี่ยนชื่อ“ ISomething” เป็น“ Something” หรือไม่ [ปิด]

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

สมมติว่า:

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

ยกตัวอย่างเช่นสองคนนี้ควรตั้งชื่ออะไร ParserและConcreteParser? ParserและParserImplementation?

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

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

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

อินเตอร์เฟสเป็นแนวคิดเชิงตรรกะที่สำคัญดังนั้นอินเตอร์เฟสควรมีชื่อสามัญ ดังนั้นฉันควรจะมี

interface Something
class DefaultSomething : Something
class MockSomething : Something

กว่า

interface ISomething
class Something : ISomething
class MockSomething : ISomething

หลังมีหลาย isues:

1. บางสิ่งเป็นเพียงการใช้งาน ISomething เพียงอย่างเดียว แต่เป็นสิ่งที่มีชื่อสามัญราวกับว่ามันเป็นอะไรที่พิเศษ
2. MockSomething ดูเหมือนมาจาก Something แต่ได้ใช้ ISomething บางทีมันอาจจะชื่อ MockISomething แต่ฉันไม่เคยเห็นแบบนี้มาก่อน
3. การปรับโครงสร้างทำได้ยากขึ้น ถ้า Something เป็นคลาสตอนนี้และคุณจะพบในภายหลังว่าคุณต้องแนะนำอินเทอร์เฟซนั้นอินเตอร์เฟสนั้นควรตั้งชื่อให้เหมือนกันเพราะมันควรจะโปร่งใสกับลูกค้าไม่ว่าจะเป็นคลาสคอนกรีตคลาสนามธรรมหรืออินเตอร์เฟส . ไม่มีอะไรแตก

นี่ไม่ใช่แค่การตั้งชื่อแบบแผน C # ไม่รองรับการสืบทอดหลายแบบดังนั้นการใช้สัญลักษณ์ฮังการีแบบดั้งเดิมนั้นมีประโยชน์เล็กน้อยแม้ว่าคุณจะได้รับมรดกจากคลาสฐานและใช้อินเตอร์เฟสอย่างน้อยหนึ่งอินเตอร์เฟส ดังนั้นนี่ ...

class Foo : BarB, IBarA
{
    // Better...
}

... ชอบสิ่งนี้มากกว่า ...

class Foo : BarB, BarA
{
    // Dafuq?
}

IMO

ไม่ไม่ไม่.

ระเบียบการตั้งชื่อไม่ใช่หน้าที่ของลุงบ็อบแฟนคลับของคุณ พวกเขาไม่ใช่ฟังก์ชั่นของภาษา c # หรืออย่างอื่น

มันเป็นฟังก์ชั่นของฐานรหัสของคุณ ร้านค้าของคุณมีขอบเขตน้อยกว่ามาก กล่าวอีกนัยหนึ่งแรกในฐานรหัสกำหนดมาตรฐาน

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

เมื่ออ่านฐานรหัสใหม่ถ้าฉันไม่เห็นIคำนำหน้าฉันไม่เป็นไรไม่ว่าจะเป็นภาษาใดก็ตาม ถ้าฉันเห็นอินเทอร์เฟซทุกตัวฉันก็สบายดี ถ้าบางครั้งฉันเห็นใครบางคนกำลังจะจ่าย

หากคุณพบว่าตัวเองอยู่ในบริบทของการตั้งค่าแบบอย่างนี้สำหรับฐานรหัสของคุณฉันขอให้คุณพิจารณาสิ่งนี้:

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

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

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

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

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

มีความแตกต่างเล็กน้อยระหว่าง Java และ C # ที่เกี่ยวข้องที่นี่ ใน Java สมาชิกทุกคนจะเป็นเสมือนโดยค่าเริ่มต้น ใน C # สมาชิกทุกคนจะถูกปิดผนึกตามค่าเริ่มต้น - ยกเว้นสมาชิกส่วนต่อประสาน

สมมติฐานที่มีอิทธิพลต่อแนวทางนี้ - ใน Java ทุกประเภทสาธารณะควรได้รับการพิจารณาว่าไม่เป็นไปตามหลักการทดแทนของ Liskov [1] หากคุณมีเพียงหนึ่งในการดำเนินงานที่คุณจะชื่อชั้นParser; หากคุณพบว่าคุณต้องการการนำไปใช้งานที่หลากหลายคุณเพียงแค่เปลี่ยนคลาสเป็นอินเทอร์เฟซที่มีชื่อเดียวกัน

ใน C # สมมติฐานหลักคือเมื่อคุณได้รับคลาส (ชื่อไม่ได้ขึ้นต้นด้วยI) นั่นคือคลาสที่คุณต้องการ โปรดทราบว่านี่ไม่มีความถูกต้อง 100% - ตัวอย่างเคาน์เตอร์ทั่วไปจะเป็นคลาสเช่นStream(ซึ่งจริงๆแล้วควรเป็นอินเทอร์เฟซหรืออินเทอร์เฟซสองสามอย่าง) และทุกคนมีแนวทางและภูมิหลังจากภาษาอื่น ๆ นอกจากนี้ยังมีข้อยกเว้นอื่น ๆ เช่นBaseคำต่อท้ายที่ใช้กันอย่างแพร่หลายเพื่อแสดงคลาสนามธรรม - เช่นเดียวกับอินเทอร์เฟซคุณรู้ว่าประเภทนั้นควรเป็น polymorphic

นอกจากนี้ยังมีคุณสมบัติการใช้งานที่ดีในการทิ้งชื่อที่ไม่ใช่ I-prefixed ไว้สำหรับฟังก์ชั่นที่เกี่ยวข้องกับส่วนต่อประสานนั้นโดยไม่ต้องหันกลับไปใช้ส่วนต่อประสานกับคลาสนามธรรม (ซึ่งอาจเจ็บเนื่องจากไม่มีคลาสหลายสืบทอดใน C #) สิ่งนี้ได้รับความนิยมจาก LINQ ซึ่งใช้IEnumerable<T>เป็นอินเตอร์เฟสและEnumerableเป็นที่เก็บของวิธีการที่ใช้กับอินเตอร์เฟสนั้น สิ่งนี้ไม่จำเป็นใน Java ซึ่งอินเตอร์เฟสสามารถมีวิธีการใช้งานได้เช่นกัน

ในท้ายที่สุดIคำนำหน้าใช้กันอย่างแพร่หลายในโลก C # และโดยการขยายโลก. NET (เนื่องจากรหัส. NET ส่วนใหญ่เขียนด้วยภาษา C # จึงเหมาะสมที่จะปฏิบัติตามแนวทาง C # สำหรับอินเทอร์เฟซสาธารณะส่วนใหญ่) ซึ่งหมายความว่าคุณจะทำงานกับไลบรารีและรหัสที่เป็นไปตามสัญกรณ์นี้อย่างแน่นอนและมันก็เหมาะสมที่จะนำธรรมเนียมปฏิบัติมาใช้เพื่อป้องกันความสับสนที่ไม่จำเป็น - การที่ไม่ใช้คำนำหน้าจะทำให้รหัสของคุณดีขึ้น :)

ฉันคิดว่าการให้เหตุผลของลุงบ็อบเป็นเช่นนี้:

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

หากคุณใช้สิ่งนี้กับIParserอินเทอร์เฟซตัวอย่างคุณจะเห็นได้อย่างชัดเจนว่าสิ่งที่เป็นนามธรรมนั้นอยู่ในอาณาเขต "ไร้ความหมาย" ไม่ว่าจะมีอะไรบางอย่างที่เฉพาะเจาะจงเกี่ยวกับการดำเนินงานที่เป็นรูปธรรมของตัวแยกวิเคราะห์ (เช่นJsonParser, XmlParser, ... ) หรือคุณก็ควรจะใช้ในชั้นเรียน ไม่มีสิ่งเช่น "การใช้งานเริ่มต้น" (แม้ว่าในบางสภาพแวดล้อมการทำเช่นนี้จะสมเหตุสมผล - โดยเฉพาะอย่างยิ่ง COM) ไม่ว่าจะมีการใช้งานที่เฉพาะเจาะจงหรือคุณต้องการระดับนามธรรมหรือวิธีการขยายสำหรับ "ค่าเริ่มต้น" อย่างไรก็ตามใน C # ยกเว้นว่า codebase ของคุณละเว้นI-prefix ไว้ให้เก็บไว้ เพียงจดบันทึกทุกครั้งที่คุณเห็นรหัสเช่นclass Something: ISomething- หมายความว่าบางคนไม่เก่งในการติดตาม YAGNI และสร้าง abstractions ที่สมเหตุสมผล

[1] - ในทางเทคนิคแล้วนี่ไม่ได้กล่าวถึงเฉพาะในกระดาษของ Liskov แต่เป็นหนึ่งในรากฐานของกระดาษ OOP ดั้งเดิมและในการอ่านของฉันใน Liskov เธอไม่ได้ท้าทายสิ่งนี้ ในการตีความที่เข้มงวดน้อยกว่า (ภาษาที่ใช้โดยภาษา OOP ส่วนใหญ่) นี่หมายความว่ารหัสใด ๆ ที่ใช้ประเภทสาธารณะที่มีไว้สำหรับการทดแทน

ยกตัวอย่างเช่นสองคนนี้ควรตั้งชื่ออะไร Parser และ ConcreteParser? Parser และ Parser ใช้งานอย่างไร

ในโลกอุดมคติคุณไม่ควรเติมชื่อของคุณด้วยชื่อย่อ ("I ... ") แต่ให้ชื่อแสดงแนวคิด

ฉันอ่านที่ใดที่หนึ่ง (และไม่สามารถหาแหล่งที่มาได้) ความเห็นที่ว่าการประชุม ISomething นี้นำคุณไปสู่การกำหนดแนวคิด "IDollar" เมื่อคุณต้องการคลาส "Dollar" แต่การแก้ปัญหาที่ถูกต้องจะเป็นแนวคิดที่เรียกว่า "สกุลเงิน"

กล่าวอีกนัยหนึ่งอนุสัญญาฉบับนี้ให้ความสะดวกในการตั้งชื่อเรื่องต่าง ๆ และความผิดพลาดอย่างง่าย

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

การประชุม ISomething แนะนำชื่อ cruft / bad ที่กล่าวว่า cruft ไม่ใช่ cruft จริง *) เว้นแต่อนุสัญญาและแนวทางปฏิบัติที่ใช้ในการเขียนรหัสจะไม่เกิดขึ้นจริงอีกต่อไป หากการประชุมบอกว่า "ใช้ ISomething" ก็จะเป็นการดีที่สุดที่จะใช้เพื่อให้สอดคล้อง (และทำงานได้ดีขึ้น) กับผู้พัฒนารายอื่น

*) ฉันสามารถออกไปพูดแบบนี้เพราะ "cruft" ไม่ใช่แนวคิดที่แน่นอน :)

ดังที่คำตอบอื่น ๆ กล่าวถึงการใส่คำนำหน้าชื่ออินเตอร์เฟสของคุณด้วยIเป็นส่วนหนึ่งของแนวทางการเข้ารหัสสำหรับ. NET Framework เนื่องจากคลาสที่เป็นรูปธรรมมีการโต้ตอบกันบ่อยกว่าอินเทอร์เฟซทั่วไปใน C # และ VB.NET พวกเขาเป็นคลาสแรกในรูปแบบการตั้งชื่อและดังนั้นจึงควรมีชื่อที่ง่ายที่สุด - ดังนั้นIParserสำหรับอินเทอร์เฟซและParserการใช้งานเริ่มต้น

แต่ในกรณีของ Java และภาษาที่คล้ายคลึงกันซึ่งเป็นที่ต้องการอินเตอร์เฟสแทนที่จะเป็นคลาสที่เป็นรูปธรรมลุงลุงบ๊อบก็Iควรที่จะลบออกและ Interface ควรมีชื่อที่ง่ายที่สุดParserเช่นอินเทอร์เฟซ parser ของคุณ แต่แทนที่จะเป็นชื่อตามบทบาทParserDefaultคลาสควรมีชื่อที่อธิบายถึงวิธีการใช้งาน parser :

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

นี่คือตัวอย่างเช่นวิธีการSet<T>, HashSet<T>และTreeSet<T>มีการตั้งชื่อ

คุณถูกต้องแล้วที่ I = ระเบียบการใช้อินเทอร์เฟซนี้ทำลายกฎ (ใหม่)

ในสมัยก่อนคุณจะต้องเติมทุกอย่างด้วยประเภท intCounter boolFlag เป็นต้น

หากคุณต้องการตั้งชื่อสิ่งที่ไม่มีคำนำหน้า แต่หลีกเลี่ยง 'ConcreteParser' คุณสามารถใช้เนมสเปซ

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}