ทำไมโครงสร้างและคลาสแยกแนวคิดใน C #

ในขณะที่การเขียนโปรแกรมใน C # ฉันสะดุดกับการตัดสินใจออกแบบภาษาแปลก ๆ ที่ฉันไม่เข้าใจ

ดังนั้น C # (และ CLR) มีชนิดข้อมูลรวมสองประเภท: struct(ค่าประเภทเก็บไว้ในสแต็กไม่มีการสืบทอด) และclass(อ้างอิงประเภทเก็บไว้ในกองมีมรดก)

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

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

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

คำถามคือทำไมclassและstructกลายเป็นแนวคิดที่แยกต่างหากใน C # และ CLR แทนที่จะเป็นประเภทรวมหนึ่งที่มีสองตัวเลือกการจัดสรร?

เหตุผล C # (และ Java และภาษา OO อื่น ๆ ที่พัฒนาขึ้นหลังจาก C ++) ไม่ได้คัดลอกโมเดลของ C ++ ในด้านนี้เนื่องจากวิธี C ++ เป็นระเบียบที่น่ากลัว

คุณระบุประเด็นที่เกี่ยวข้องด้านบนได้อย่างถูกต้องstruct:: ประเภทค่าไม่มีการสืบทอด class: ประเภทการอ้างอิงมีการสืบทอด การสืบทอดและประเภทของค่า (หรือมากกว่านั้นโดยเฉพาะความหลากหลายและการส่งต่อค่า) ไม่ได้ผสมกัน ถ้าคุณส่งอ็อบเจกต์ประเภทDerivedไปยังเมธอดอาร์กิวเมนต์ประเภทBaseและจากนั้นเรียกใช้เมธอดเสมือนบนมันวิธีเดียวที่จะได้รับพฤติกรรมที่เหมาะสมคือเพื่อให้แน่ใจว่าสิ่งที่ผ่านไปนั้นคือการอ้างอิง

ระหว่างสิ่งนั้นกับความยุ่งเหยิงอื่น ๆ ทั้งหมดที่คุณพบใน C ++ โดยมีวัตถุที่สืบทอดได้ในรูปแบบของค่า (คัดลอกคอนสตรัคเตอร์และการแบ่งส่วนวัตถุมาเป็นใจ!) ทางออกที่ดีที่สุดคือ Just Say No.

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

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

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

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

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

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

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

ใน C ++ มันขึ้นอยู่กับโปรแกรมเมอร์ที่จะทำอย่างถูกต้อง - เมื่อเขาใช้การสืบทอดมันขึ้นอยู่กับเขาเพื่อให้แน่ใจว่า (ตัวอย่าง) ฟังก์ชันที่ทำงานกับคลาส polymorphic ในลำดับชั้นทำได้โดยใช้ตัวชี้หรืออ้างอิงถึงฐาน ชั้น

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

มาจาก"C #: ทำไมเราต้องการภาษาอื่น" - Gunnerson, Eric:

ความเรียบง่ายเป็นเป้าหมายการออกแบบที่สำคัญสำหรับ C #

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

[ ... ]

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

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

อะไรจะดีไปกว่าการแยกวัตถุที่สกปรกน่าเกลียดและไม่ดีออกไปซึ่งมีค่าความหมายภายใต้แท็กของstruct?

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

// Defined structure
struct Point : IEquatable<Point>
{
  public int X,Y;
  public Point(int x, int y) { X=x; Y=y; }
  public bool Equals(Point other) { return X==other.X && y==other.Y; }
  public bool Equals(Object other)
  { return other != null && other.GetType()==typeof(this) && Equals(Point(other)); }
  public bool ToString() { return String.Format("[{0},{1}", x, y); }
  public bool GetHashCode() { return unchecked(x+y*65531); }
}        
// Auto-generated class
class boxed_Point: IEquatable<Point>
{
  public Point value; // Fake name; C++/CLI, though not C#, allow full access
  public boxed_Point(Point v) { value=v; }
  // Members chain to each member of the original
  public bool Equals(Point other) { return value.Equals(other); }
  public bool Equals(Object other) { return value.Equals(other); }
  public String ToString() { return value.ToString(); }
  public Int32 GetHashCode() { return value.GetHashCode(); }
}

และสำหรับข้อความสั่งเช่น: Console.WriteLine ("ค่าคือ {0}", somePoint);

ที่จะแปลเป็น: boxed_Point box1 = new boxed_Point ใหม่ (somePoint); Console.WriteLine ("ค่าคือ {0}", box1);

ในทางปฏิบัติเพราะประเภทสถานที่เก็บและประเภทเช่นกองอยู่ในจักรวาลที่แยกจากกันมันไม่จำเป็นที่จะเรียกประเภทกองอินสแตนซ์ในสิ่งที่ชอบเช่นboxed_Int32; เนื่องจากระบบจะทราบว่าบริบทใดที่ต้องการอินสแตนซ์ของฮีป - ออบเจ็กต์และสิ่งใดที่จำเป็นต้องมีที่เก็บข้อมูล

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