เหตุใด C # ไม่อนุญาตให้ใช้วิธีการแบบคงที่เพื่อใช้ส่วนต่อประสาน

เหตุใด C # จึงออกแบบวิธีนี้

ตามที่ฉันเข้าใจอินเทอร์เฟซจะอธิบายพฤติกรรมเท่านั้นและมีจุดประสงค์ในการอธิบายข้อผูกพันตามสัญญาสำหรับคลาสที่ใช้อินเทอร์เฟซที่มีการใช้งานพฤติกรรมบางอย่าง

หากคลาสต้องการใช้พฤติกรรมนั้นในวิธีการแชร์ทำไมถึงไม่ควรใช้

นี่คือตัวอย่างของสิ่งที่ฉันมีอยู่ในใจ:

// These items will be displayed in a list on the screen.
public interface IListItem {
  string ScreenName();
  ...
}

public class Animal: IListItem {
    // All animals will be called "Animal".
    public static string ScreenName() {
        return "Animal";
    }
....
}

public class Person: IListItem {

    private string name;

    // All persons will be called by their individual names.
    public string ScreenName() {
        return name;
    }

    ....

 }

สมมติว่าคุณถามว่าทำไมคุณไม่ทำเช่นนี้:

public interface IFoo {
    void Bar();
}

public class Foo: IFoo {
    public static void Bar() {}
}

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

public class Animal: IListItem {
    /* Can be tough to come up with a different, yet meaningful name!
     * A different casing convention, like Java has, would help here.
     */
    public const string AnimalScreenName = "Animal";
    public string ScreenName(){ return AnimalScreenName; }
}

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

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

ด้วยเหตุผลทางการเมืองฉันจะพูดถึง Eric Lippert (ผู้ซึ่งเป็นผู้รวบรวมเรียบเรียงและจบปริญญาตรีคณิตศาสตร์วิทยาศาสตร์คอมพิวเตอร์และคณิตศาสตร์ประยุกต์จาก University of Waterloo (ที่มา: LinkedIn ):

... หลักการออกแบบหลักของวิธีการคงที่, หลักการที่ให้พวกเขาชื่อ ... [คือ] ... มันสามารถกำหนดได้อย่างแน่นอนในเวลารวบรวม, วิธีการใดจะเรียกว่า นั่นคือวิธีการนี้สามารถแก้ไขได้โดยการวิเคราะห์โค้ดแบบคงที่เท่านั้น

โปรดทราบว่า Lippert ออกจากห้องสำหรับวิธีการพิมพ์ที่เรียกว่า:

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

แต่ยังไม่มั่นใจในประโยชน์ของมัน

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

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

ตัวอย่างเช่น:

Repository GetRepository<T>()
{
  //need to call T.IsQueryable, but can't!!!
  //need to call T.RowCount
  //need to call T.DoSomeStaticMath(int param)
}

...
var r = GetRepository<Customer>()

น่าเสียดายที่ฉันสามารถหาทางเลือก "น่าเกลียด" ได้เท่านั้น:

• ใช้การสะท้อนที่ น่าเกลียดและเอาชนะแนวคิดของอินเทอร์เฟซและความหลากหลาย

• สร้างคลาสโรงงานแยกต่างหากอย่างสมบูรณ์

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

• อินสแตนซ์แล้วเรียกวิธีการอินเทอร์เฟซที่ต้องการ

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

ตัวอย่าง:

public class Customer 
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  void SomeOtherMethod() 
  { 
    //do work...
  }
}

เพื่อใช้อินสแตนซ์สำหรับการแก้ปัญหาส่วนต่อประสานแบบคงที่เราจำเป็นต้องทำสิ่งต่อไปนี้:

public class Customer: IDoSomeStaticMath
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  //dummy instance
  public Customer() { IsDummy = true; }

  int DoSomeStaticMath(int a) { }

  void SomeOtherMethod() 
  { 
    if(!IsDummy) 
    {
      //do work...
    }
  }
}

เห็นได้ชัดว่าน่าเกลียดและไม่จำเป็นต้องทำให้โค้ดซับซ้อนสำหรับวิธีอื่น ๆ ทั้งหมด เห็นได้ชัดว่าไม่ใช่ทางออกที่สง่างามเช่นกัน!

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

string DoSomething <T> () โดยที่ T: ISomeFunction
{
  if (T.someFunction ())
    ...
}

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

1. สร้างคลาสทั่วไปแบบสแตติกซึ่งพารามิเตอร์ประเภทจะเป็นประเภทที่คุณจะส่งไปยัง DoSomething ข้างต้น แต่ละรูปแบบของคลาสนี้จะมีสมาชิกแบบสแตติกหนึ่งรายการหรือมากกว่าที่เกี่ยวข้องกับประเภทนั้น ข้อมูลนี้สามารถระบุได้ด้วยการให้แต่ละคลาสที่สนใจเรียกรูทีน "register information" หรือโดยใช้ Reflection เพื่อรับข้อมูลเมื่อตัวสร้างสแตติกของคลาสที่เปลี่ยนแปลงนั้นทำงานอยู่ ฉันเชื่อว่าวิธีการหลังถูกใช้โดยสิ่งต่าง ๆ เช่น Comparer <T> .Default ()
2. สำหรับแต่ละคลาสที่น่าสนใจให้กำหนดคลาสหรือโครงสร้างที่ใช้ IGetWhethingClassInfo <T> และสร้างข้อ จำกัด "ใหม่" ชั้นจะไม่ประกอบด้วยเขตข้อมูลใด ๆ จริง ๆ แต่จะมีคุณสมบัติแบบคงที่ซึ่งคืนค่าเขตข้อมูลแบบคงที่ด้วยข้อมูลชนิด ส่งประเภทของคลาสหรือโครงสร้างนั้นไปยังชุดคำสั่งทั่วไปที่มีปัญหาซึ่งจะสามารถสร้างอินสแตนซ์และใช้เพื่อรับข้อมูลเกี่ยวกับคลาสอื่น หากคุณใช้คลาสเพื่อจุดประสงค์นี้คุณควรกำหนดคลาสแบบคงที่ตามที่ระบุไว้ด้านบนเพื่อหลีกเลี่ยงการสร้างอินสแตนซ์ตัวอธิบายวัตถุใหม่ทุกครั้ง หากคุณใช้ struct ค่าใช้จ่ายการเริ่มต้นควรเป็นศูนย์ แต่ทุกประเภทโครงสร้างที่แตกต่างกันจะต้องมีการขยายชุดคำสั่ง DoSomething

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

สายตาสั้นฉันเดา

เมื่อได้รับการออกแบบเริ่มต้นอินเทอร์เฟซตั้งใจให้ใช้กับอินสแตนซ์ของคลาสเท่านั้น

IMyInterface val = GetObjectImplementingIMyInterface();
val.SomeThingDefinedinInterface();

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

(ตอบกลับความคิดเห็น :) ฉันเชื่อว่าการเปลี่ยนแปลงตอนนี้จะต้องมีการเปลี่ยนแปลง CLR ซึ่งจะนำไปสู่ความไม่ลงรอยกันกับชุดประกอบที่มีอยู่

อินเทอร์เฟซระบุลักษณะการทำงานของวัตถุ

วิธีการคงที่ไม่ได้ระบุพฤติกรรมของวัตถุ แต่พฤติกรรมที่มีผลต่อวัตถุในบางวิธี

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

ข้อโต้แย้งข้างต้นทั้งหมดดูเหมือนจะพลาดจุดนี้เกี่ยวกับสัญญา

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

คุณจะเรียกมันว่าอย่างไร ??

public interface MyInterface { void MyMethod(); }
public class MyClass: MyInterface
{
    public static void MyMethod() { //Do Something; }
}

 // inside of some other class ...  
 // How would you call the method on the interface ???
    MyClass.MyMethod();  // this calls the method normally 
                         // not through the interface...

    // This next fails you can't cast a classname to a different type... 
    // Only instances can be Cast to a different type...
    MyInterface myItf = MyClass as MyInterface;  

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

T SumElements<T>(T initVal, T[] values)
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

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

สิ่งที่ C # ต้องการคือประเภทข้อ จำกัด ที่แท้จริงอินเทอร์เฟซทั้งหมดก็จะเป็นข้อ จำกัด แต่ไม่ใช่ข้อ จำกัด ทั้งหมดที่จะเป็นอินเทอร์เฟซจากนั้นคุณสามารถทำสิ่งนี้ได้:

constraint CHasPlusEquals
{
    static CHasPlusEquals operator + (CHasPlusEquals a, CHasPlusEquals b);
}

T SumElements<T>(T initVal, T[] values) where T : CHasPlusEquals
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

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

เนื่องจากอินเทอร์เฟซอยู่ในโครงสร้างการสืบทอดและวิธีการแบบคงที่ไม่สืบทอดดี

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

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

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

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

เพื่อยกตัวอย่างที่ฉันขาดการนำวิธีการอินเตอร์เฟสไปใช้หรือสิ่งที่ Mark Brackett แนะนำให้ใช้เป็น "วิธีการพิมพ์ที่เรียกว่า":

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

interface IDataRow {
  string GetDataSTructre();  // How to read data from the DB
  void Read(IDBDataRow);     // How to populate this datarow from DB data
}

public class DataTable<T> : List<T> where T : IDataRow {

  public string GetDataStructure()
    // Desired: Static or Type method:
    // return (T.GetDataStructure());
    // Required: Instantiate a new class:
    return (new T().GetDataStructure());
  }

}

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

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

การเชื่อมต่อเป็นชุดนามธรรมของฟังก์ชั่นที่มีอยู่ที่กำหนดไว้

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

ถ้าเมธอดถูกกำหนดเป็นสแตติกคลาสที่ใช้อินเตอร์เฟสจะไม่ถูกห่อหุ้มเท่าที่ควร การห่อหุ้มเป็นสิ่งที่ดีในการมุ่งเน้นในการออกแบบเชิงวัตถุ (ฉันจะไม่เข้าไปหาสาเหตุคุณสามารถอ่านได้ที่นี่: http://en.wikipedia.org/wiki/Object-oriented ) ด้วยเหตุผลนี้จึงไม่อนุญาตให้ใช้วิธีการคงที่ในส่วนต่อประสาน

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

ฉันมีคลาสของชั้นธุรกิจแบบคงที่ที่ใช้วิธีการ CRUD เช่น "สร้าง", "อ่าน", "อัปเดต", "ลบ" สำหรับแต่ละประเภทเอนทิตีเช่น "ผู้ใช้", "ทีม" ฯลฯ จากนั้นฉันสร้างฐาน ควบคุมที่มีคุณสมบัตินามธรรมสำหรับชั้นธุรกิจที่ใช้วิธีการ CRUD สิ่งนี้ทำให้ฉันสามารถดำเนินการ "สร้าง", "อ่าน", "อัปเดต", "ลบ" โดยอัตโนมัติจากคลาสฐาน ฉันต้องใช้ซิงเกิลตันเนื่องจากข้อ จำกัด คงที่

คนส่วนใหญ่ดูเหมือนจะลืมว่าใน OOP Classes เป็นวัตถุด้วยและพวกเขาก็มีข้อความซึ่งด้วยเหตุผลบางอย่าง c # เรียกว่า "วิธีการคงที่" ความจริงที่ว่ามีความแตกต่างระหว่างวัตถุอินสแตนซ์และวัตถุคลาสแสดงข้อบกพร่องหรือข้อบกพร่องในภาษาเท่านั้น Optimist เกี่ยวกับ c # แม้ว่า ...

ตกลงที่นี่เป็นตัวอย่างของความต้องการ 'วิธีการพิมพ์' ฉันกำลังสร้างหนึ่งในชุดของชั้นเรียนตาม XML แหล่งที่มาบางส่วน ดังนั้นฉันมี

  static public bool IsHandled(XElement xml)

ฟังก์ชั่นซึ่งเรียกว่าเปิดในแต่ละชั้นเรียน

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

มันเป็นการดีที่จะเพิ่มไปยังอินเทอร์เฟซเพื่อบังคับให้ตัวเรียกคลาสใช้งาน นี่จะไม่ทำให้เกิดค่าใช้จ่ายที่สำคัญ - มันเป็นเพียงการตรวจสอบรวบรวม / ลิงค์เวลาและไม่ส่งผลกระทบต่อ vtable

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

ดังนั้นมันจึงเป็นคุณสมบัติที่อาจเกิดขึ้นได้เล็กน้อยซึ่งความสมดุลนั้นน่าจะดีที่สุด

ความจริงที่ว่าคลาสแบบสแตติกถูกนำมาใช้ใน C # โดย Microsoft การสร้างอินสแตนซ์พิเศษของคลาสที่มีองค์ประกอบแบบสแตติกนั้นเป็นเพียงความผิดปกติของวิธีการใช้งานสแตติก มันไม่ได้เป็นประเด็นทางทฤษฎี

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

นี่คือตัวอย่างที่ชัดเจนของการที่สามารถใช้อินเตอร์เฟสกับคลาสสแตติกจะมีประโยชน์มาก:

public interface ICrudModel<T, Tk>
{
    Boolean Create(T obj);
    T Retrieve(Tk key);
    Boolean Update(T obj);
    Boolean Delete(T obj);
}

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

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

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

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

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

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

public interface IZeroWrapper<TNumber> {
  TNumber Zero {get;}
}

public class DoubleWrapper: IZeroWrapper<double> {
  public double Zero { get { return 0; } }
}

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

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

แนวคิดไม่มีเหตุผลว่าทำไมอินเตอร์เฟสไม่สามารถกำหนดสัญญาที่มีวิธีการแบบคงที่ได้

สำหรับการใช้งานภาษา C # ในปัจจุบันข้อ จำกัด นั้นเกิดจากค่าเผื่อการสืบทอดของคลาสฐานและอินเตอร์เฟส ถ้า "คลาส SomeBaseClass" ใช้ "อินเตอร์เฟส ISomeInterface" และ "คลาส SomeDerivedClass: SomeBaseClass, ISomeInterface" ยังใช้อินเทอร์เฟซวิธีคงที่ในการใช้วิธีการอินเทอร์เฟซจะล้มเหลวเนื่องจากวิธีการแบบคงที่ไม่สามารถมีลายเซ็นเดียวกัน อยู่ในคลาสฐานเพื่อใช้อินเตอร์เฟส)

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

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

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