ในฐานะนักพัฒนา C ++ ฉันค่อนข้างคุ้นเคยกับไฟล์ส่วนหัว C ++ และพบว่ามีประโยชน์ในการมี "เอกสาร" ที่ถูกบังคับภายในโค้ด ฉันมักจะมีช่วงเวลาที่ไม่ดีเมื่อฉันต้องอ่านรหัส C # เพราะ: ฉันไม่มีแผนที่ทางจิตของชั้นเรียนที่ฉันทำงานด้วย

สมมติว่าในฐานะวิศวกรซอฟต์แวร์ฉันกำลังออกแบบกรอบงานของโปรแกรม มันจะบ้าเกินกว่าที่จะนิยามว่าทุกคลาสเป็นคลาสที่ไม่มีการใช้งานแบบนามธรรมคล้ายกับสิ่งที่เราจะทำกับส่วนหัวของ C ++ และให้นักพัฒนาใช้มันได้หรือไม่

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

เหตุผลที่ทำใน C ++ นั้นเกี่ยวข้องกับการทำให้คอมไพเลอร์เร็วขึ้นและง่ายต่อการนำไปใช้ นี่ไม่ใช่การออกแบบเพื่อให้การเขียนโปรแกรมง่ายขึ้น

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

ไม่แนะนำให้พยายามทำซ้ำข้อ จำกัด ฮาร์ดแวร์เก่าในสภาพแวดล้อมการพัฒนาที่ทันสมัย!

การกำหนดอินเทอร์เฟซหรือคลาสนามธรรมสำหรับทุกชั้นจะลดประสิทธิภาพการทำงานของคุณ อะไรที่คุณจะได้ทำกับเวลานั้น ? นอกจากนี้ผู้พัฒนารายอื่นจะไม่ปฏิบัติตามอนุสัญญานี้

ในความเป็นจริงผู้พัฒนารายอื่นอาจลบคลาสนามธรรมของคุณ หากฉันพบอินเทอร์เฟซในรหัสที่ตรงกับเกณฑ์ทั้งสองนี้ฉันจะลบออกและปรับโครงสร้างใหม่จากโค้ด:1. Does not conform to the interface segregation principle 2. Only has one class that inherits from it

อีกอย่างคือมีเครื่องมือที่มาพร้อมกับ Visual Studio ที่ทำในสิ่งที่คุณตั้งใจจะทำให้สำเร็จโดยอัตโนมัติ:

1. Class View
2. Object Browser
3. ในSolution Explorerคุณสามารถคลิกที่รูปสามเหลี่ยมเพื่อใช้จ่ายเรียนเพื่อดูฟังก์ชั่นพารามิเตอร์และประเภทผลตอบแทน
4. มีเมนูแบบเลื่อนลงสามเมนูด้านล่างแท็บไฟล์หนึ่งรายการที่เหมาะสมที่สุดจะแสดงสมาชิกทั้งหมดของคลาสปัจจุบัน

ลองหนึ่งวิธีข้างต้นก่อนที่จะอุทิศเวลาในการเรพลิเคตไฟล์ส่วนหัว C ++ ใน C #

นอกจากนี้ยังมีเหตุผลทางเทคนิคที่จะไม่ทำเช่นนี้ ... มันจะทำให้ไบนารีสุดท้ายของคุณใหญ่กว่าที่ควรจะเป็น ฉันจะทำซ้ำความคิดเห็นนี้โดย Mark Benningfield:

การประกาศในไฟล์ส่วนหัว C ++ ไม่ได้จบลงด้วยการเป็นส่วนหนึ่งของไบนารีที่สร้างขึ้น พวกเขามีไว้สำหรับคอมไพเลอร์และลิงเกอร์ คลาส C # นามธรรมเหล่านี้จะเป็นส่วนหนึ่งของรหัสที่สร้างขึ้นเพื่อประโยชน์ใด ๆ

ในทางเทคนิคแล้วการกล่าวถึงโดย Robert Harvey ในทางเทคนิคความใกล้เคียงที่สุดของส่วนหัวใน C # จะเป็นอินเทอร์เฟซไม่ใช่คลาสนามธรรม

ก่อนอื่นให้ทำความเข้าใจว่าคลาสนามธรรมล้วน ๆ เป็นเพียงส่วนต่อประสานที่ไม่สามารถรับมรดกได้หลายอย่าง

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

อินเทอร์เฟซไม่ควรถูกคิดว่าเป็นการกล่าวซ้ำอย่างเป็นทางการว่าอะไรก็ตามที่ชั้นเรียนทำได้ ควรถือว่าอินเตอร์เฟสเป็นสัญญาที่กำหนดโดยใช้รหัสลูกค้าที่มีรายละเอียดตามความต้องการ

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

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

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

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

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

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

ดังนั้นโปรดอย่าเขียน abstractions เพียงเพื่อช่วยให้เราอ่านรหัส เรามีเครื่องมือสำหรับสิ่งนั้น ใช้ abstractions เพื่อแยกสิ่งที่ต้องการแยกออก

ใช่มันจะแย่มากเพราะ (1) มันแนะนำโค้ดที่ไม่จำเป็น (2) มันจะทำให้ผู้อ่านสับสน

หากคุณต้องการโปรแกรมใน C # คุณควรจะคุ้นเคยกับการอ่าน C # รหัสที่เขียนโดยคนอื่นจะไม่เป็นไปตามรูปแบบนี้อยู่ดี

การทดสอบหน่วย

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

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

ตัวอย่าง: ที่ที่คุณอาจเขียนไฟล์ส่วนหัว myclass.h เช่นนี้:

class MyClass
{
public:
  void foo();
};

แต่ใน c # เขียนการทดสอบแบบนี้:

[TestClass]
public class MyClassTests
{
    [TestMethod]
    public void MyClass_should_have_method_Foo()
    {
        //Arrange
        var myClass = new MyClass();
        //Act
        myClass.Foo();
        //Verify
        Assert.Inconclusive("TODO: Write a more detailed test");
    }
}

การทดสอบที่ง่ายมากนี้สื่อถึงข้อมูลเดียวกันกับไฟล์ส่วนหัว (เราควรจะมีคลาสชื่อ "MyClass" ที่มีฟังก์ชั่นแบบไม่มีพารามิเตอร์ "Foo") ในขณะที่ไฟล์ส่วนหัวมีขนาดกะทัดรัดมากขึ้นการทดสอบจะมีข้อมูลมากขึ้น

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