การประกาศอินเตอร์เฟสในไฟล์เดียวกับคลาสพื้นฐานมันเป็นการปฏิบัติที่ดีหรือไม่?

เพื่อให้สามารถเปลี่ยนได้และทดสอบได้ปกติบริการที่มีตรรกะต้องมีส่วนต่อประสานเช่น

public class FooService: IFooService 
{ ... }

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

ฉันคิดว่าการเขียน IFooService ในไฟล์เดียวกับ FooService จะลดความแปลกประหลาดข้างต้น ท้ายที่สุด IFooService และ FooService มีความเกี่ยวข้องกันมาก นี่เป็นวิธีปฏิบัติที่ดีหรือไม่? มีเหตุผลที่ดีที่ IFooService จะต้องอยู่ในไฟล์ของตัวเองหรือไม่?

มันไม่จำเป็นต้องอยู่ในไฟล์ของตัวเอง แต่ทีมของคุณควรเลือกมาตรฐานและยึดมันไว้

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

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

ตาม SOLID ไม่เพียง แต่คุณควรสร้างส่วนต่อประสานและไม่เพียง แต่ควรอยู่ในไฟล์ที่แตกต่าง แต่ควรอยู่ในชุดประกอบอื่น

ทำไม? เนื่องจากการเปลี่ยนแปลงใด ๆ กับไฟล์ต้นฉบับที่คอมไพล์ในแอสเซมบลีต้องมีการคอมไพล์ใหม่ของแอสเซมบลีและการเปลี่ยนแปลงใด ๆ ในแอสเซมบลีต้อง recompilation ของแอสเซมบลีใด ๆ ดังนั้นหากเป้าหมายของคุณที่มีพื้นฐานมาจาก SOLID นั้นจะสามารถแทนที่การใช้งาน A ด้วยการนำไปใช้ B ได้ในขณะที่คลาส C ขึ้นอยู่กับส่วนต่อประสานที่ฉันไม่จำเป็นต้องทราบถึงความแตกต่าง ในมันไม่เปลี่ยนแปลงดังนั้นปกป้องประเพณี

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

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

ทำไมการมีไฟล์แยกต่างหากทำให้รู้สึกไม่สบาย? สำหรับฉันมันเป็นสิ่งที่ดีและสะอาดกว่ามาก เป็นเรื่องปกติที่จะสร้างโฟลเดอร์ย่อยชื่อ "Interfaces" และติดไฟล์ IFooServer.cs ของคุณไว้ที่นั่นหากคุณต้องการดูไฟล์น้อยลงใน Solution Explorer ของคุณ

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

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

ส่วนตัวผมชอบที่จะมีอินเตอร์เฟซและคลาสในไฟล์เดียวกันเมื่อมีเพียงคลาสเดียวที่ใช้อินเทอร์เฟซเช่นในกรณีของคุณ

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

มีหลายครั้งที่คุณต้องการให้อินเทอร์เฟซของคุณไม่เพียง แต่ในไฟล์แยกไปยังคลาส แต่ยังอยู่ในแอสเซมบลีที่แยกต่างหากทั้งหมด

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

ถ้าเป็นไปได้ยากที่จะมีการใช้งานอินเตอร์เฟสเดียว¹ครั้ง หากคุณใส่ส่วนต่อประสานสาธารณะและชั้นสาธารณะที่นำส่วนต่อประสานนั้นไปใช้ในไฟล์เดียวกันโอกาสที่ดีคือคุณไม่จำเป็นต้องมีส่วนต่อประสาน

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

โดยทั่วไปแล้วคุณควรยึดติดกับกลยุทธ์ "หนึ่งคลาสสาธารณะ / อินเทอร์เฟซที่สอดคล้องกับไฟล์เดียว": มันง่ายต่อการติดตามและทำให้ต้นกำเนิดของคุณง่ายขึ้น

อินเทอร์เฟซเป็นของลูกค้าของพวกเขาที่จะไม่ดำเนินการตามที่กำหนดไว้ในหลักการเปรียววิธีปฏิบัติและรูปแบบโดย Robert C. Martin ดังนั้นการรวมอินเทอร์เฟซและการนำไปใช้ในที่เดียวกันมันขัดกับหลักการของมัน

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

ปรับปรุง: นี่ไม่ใช่หลักการเดียวที่คล่องตัวที่นี่ Gang of Four ในรูปแบบการออกแบบย้อนกลับไปในปี '94 กำลังพูดถึงไคลเอนต์ที่ยึดมั่นกับอินเตอร์เฟสและการโปรแกรมไปยังอินเตอร์เฟส มุมมองของพวกเขาคล้ายกัน

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

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

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

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

โดยส่วนตัวถ้าฉันเจอ codebase ซึ่งใช้การประชุมหนึ่งมากกว่าอีกฉันจะไม่กังวลเกินไปทั้งสองวิธี