C # Neden Statik Yöntemlerin Arabirim Uygulamasına İzin Vermiyor?

C # neden bu şekilde tasarlandı?

Anladığım kadarıyla, bir arayüz sadece davranışı tanımlar ve belirli davranışın uygulandığı arayüzü uygulayan sınıflar için sözleşmeye bağlı bir yükümlülüğü tanımlamak amacına hizmet eder.

Sınıflar bu davranışı paylaşılan bir yöntemle uygulamak istiyorsa neden olmasın?

Aklımda ne var bir örnek:

// 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;
    }

    ....

 }

Bunu neden yapamayacağınızı sorduğunuzda:

public interface IFoo {
    void Bar();
}

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

Bu anlamsal olarak benim için bir anlam ifade etmiyor. Bir arabirimde belirtilen yöntemler, bir nesne ile etkileşim için sözleşmeyi belirtmek için orada olmalıdır. Statik yöntemler bir nesneyle etkileşime girmenize izin vermez - kendinizi uygulamanızın statik hale getirilebileceği konumda bulursanız, bu yöntemin gerçekten arayüzde olup olmadığını kendinize sormanız gerekebilir.

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; }
}

Daha karmaşık bir durum için, her zaman başka bir statik yöntem bildirebilir ve buna yetki verebilirsiniz. Bir örnek bulmaya çalışırken, hem statik hem de örnek bağlamda önemsiz olmayan bir şey yapmanın herhangi bir nedenini düşünemedim, bu yüzden size bir FooBar blob'u yedekleyeceğim ve bunun bir göstergesi olarak alacağım iyi bir fikir değil.

Benim (basitleştirilmiş) teknik nedenim statik yöntemlerin vtable'da olmaması ve çağrı sitesinin derleme zamanında seçilmesidir. Geçersiz kılma veya sanal statik üyeleriniz olamaz. Daha fazla ayrıntı için, hiçbiri olmadığım bir CS grad veya derleyici kazanmasına ihtiyacınız olacak.

Siyasi sebepten dolayı, Eric Lippert'i (derleyici kazanır ve Waterloo Üniversitesi'nden Matematik, Bilgisayar bilimi ve Uygulamalı Matematik Lisansı (kaynak: LinkedIn ):

... statik yöntemlerin temel tasarım ilkesi, onlara isimlerini veren ilke ... Yani, yöntem yalnızca kodun statik analizi ile çözülebilir.

Lippert'in sözde tip yöntemine yer bıraktığını unutmayın:

Yani, bir türle ilişkili (statik gibi), boş olmayan bir "bu" bağımsız değişkeni almayan (bir örnek veya sanaldan farklı olarak), ancak çağrılan yöntemin oluşturulmuş T türüne ( derleme zamanında belirlenebilir olması gereken bir statikten farklı olarak).

ancak henüz yararlı olduğuna ikna olmamıştır.

Buradaki cevapların çoğu bütün noktayı kaçırıyor gibi görünüyor. Polimorfizm sadece örnekler arasında değil, aynı zamanda türler arasında da kullanılabilir. Jenerik kullandığımızda buna sıklıkla ihtiyaç duyulur.

Diyelim ki genel yöntemde type parametresi var ve onunla bazı işlemler yapmalıyız. Anlaşmak istemiyoruz çünkü kurucuların farkında değiliz.

Örneğin:

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>()

Ne yazık ki, sadece "çirkin" alternatiflerle gelebilirim:

• Yansıma çirkin kullanın ve arayüzler ve polimorfizm fikrini yener.

• Tamamen ayrı fabrika sınıfı oluşturun

  Bu, kodun karmaşıklığını büyük ölçüde artırabilir. Örneğin, etki alanı nesnelerini modellemeye çalışıyorsak, her nesnenin başka bir depo sınıfına ihtiyacı olacaktır.

• İstenen arabirim yöntemini başlatın ve çağırın

  Genel parametre olarak kullanılan sınıfların kaynağını kontrol etsek bile bunu uygulamak zor olabilir. Bunun nedeni, örneğin, örneklerin yalnızca iyi bilinen "DB'ye bağlı" durumda olması gerektiğidir.

Misal:

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

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

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

statik arayüz problemini çözmek için anlık kullanımı kullanmak için aşağıdakileri yapmamız gerekir:

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...
    }
  }
}

Bu açıkça çirkin ve aynı zamanda gereksiz tüm diğer yöntemler için kodu karmaşık. Açıkçası, zarif bir çözüm de değil!

Bunun eski bir soru olduğunu biliyorum, ama ilginç. Örnek iyi değil. Bir kullanım durumu gösterdiyseniz çok daha açık olacağını düşünüyorum:

string DoSomething <T> () burada T: ISomeFunction
{
  eğer (T.someFunction ())
    ...
}

Yalnızca bir arabirimi uygulamak için statik yöntemlere sahip olmak, istediğiniz şeyi elde edemezdi; bir arayüzün parçası olarak statik üyelerin olması gerekirdi . Bunun için birçok kullanım örneği hayal edebiliyorum, özellikle de bir şeyler yaratma söz konusu olduğunda. Yardımcı olabilecek iki yaklaşım önerebilirim:

1. Type parametresi yukarıdaki DoSomething'e geçireceğiniz tür olacak statik bir genel sınıf oluşturun. Bu sınıfın her varyasyonu, bu türle ilgili şeyler tutan bir veya daha fazla statik üyeye sahip olacaktır. Bu bilgiler, her bir ilgi sınıfının bir "kayıt bilgileri" yordamı çağırmasını sağlayarak veya sınıf varyasyonunun statik yapıcısı çalıştırıldığında bilgileri almak için Yansıma kullanarak sağlanabilir. İkinci yaklaşımın Karşılaştırıcı <T> .Default () gibi şeyler tarafından kullanıldığına inanıyorum.
2. İlgilenilen her sınıf T için, IGetWhateverClassInfo <T> uygulayan ve "yeni" bir kısıtlamayı karşılayan bir sınıf veya yapı tanımlayın. Sınıf aslında herhangi bir alan içermez, ancak tür bilgisiyle statik bir alan döndüren bir statik özelliğe sahiptir. Söz konusu sınıfın veya yapının türünü, bir örnek oluşturabilecek ve diğer sınıf hakkında bilgi almak için kullanabilecek söz konusu genel rutine aktarın. Bu amaçla bir sınıf kullanırsanız, her seferinde yeni bir tanımlayıcı nesne örneği oluşturmak zorunda kalmamak için muhtemelen yukarıda belirtildiği gibi statik bir genel sınıf tanımlamanız gerekir. Bir yapı kullanırsanız, örnekleme maliyeti sıfır olmalıdır, ancak her farklı yapı türü DoSomething yordamının farklı bir şekilde genişletilmesini gerektirir.

Bu yaklaşımların hiçbiri gerçekten çekici değil. Öte yandan, CLR'de bu tür bir işlevselliği temiz bir şekilde sağlamak için var olan mekanizmalar varsa, .net'in parametreli "yeni" kısıtlamalar belirtmesine izin vereceğini beklerdim (çünkü bir sınıfın belirli bir imzası olan bir kurucuya sahip olup olmadığını bilmek belirli bir imzayla statik bir yönteme sahip olup olmadığını bilmekte güçlükle karşılaştırılabilir olması).

Kısa görüşlülük, sanırım.

Başlangıçta tasarlandığında, arayüzlerin sadece sınıf örnekleri ile kullanılması amaçlanmıştır.

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

Sadece arayüzlerin tanıtımı ile oldu, çünkü jenerikler için kısıtlamalar bir arayüze statik bir yöntem ekleyerek pratik bir kullanıma sahipti.

(yoruma cevap) :) Şimdi değiştirmenin CLR'de mevcut meclislerle uyumsuzluğa yol açacak bir değişiklik gerektirdiğine inanıyorum.

Arabirimler bir nesnenin davranışını belirtir.

Statik yöntemler bir nesnenin davranışını değil, bir nesneyi bir şekilde etkileyen davranışı belirtir.

Arayüzler "sözleşmeleri" temsil ettiği ölçüde, statik sınıfların arayüzleri uygulaması sessiz görünüyor.

Yukarıdaki argümanların hepsi sözleşmelerle ilgili bu noktayı kaçırıyor gibi görünüyor.

Bir arabirimin amacı, polimorfizme izin vermek olduğundan, tanımlanmış arabirimi uygulamak için tanımlanmış herhangi bir sayıda tanımlanmış sınıfın bir örneğini iletebilmesidir ... polimorfik çağrınızda kodun bulabileceğini garanti eder aradığınız yöntem. arayüzü uygulamak için statik bir yönteme izin vermek hiç mantıklı değil,

Nasıl denir?

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;  

Jenerik olmayan bağlamlarda kullanılan statik yöntemlerle ilgili olarak, arayüzlerde bunlara izin vermenin pek mantıklı olmadığını kabul ediyorum, çünkü yine de arayüze bir referansınız olsaydı onları arayamazsınız. Bununla birlikte, polimorfik bağlamda değil, jenerik bir arayüzde arayüzler kullanılarak oluşturulan dil tasarımında temel bir delik vardır. Bu durumda arayüz hiç bir arayüz değil, bir kısıtlamadır. C # bir arayüz dışında bir kısıtlama kavramına sahip olmadığından, önemli işlevsellikten yoksundur. Konuşma konusu olan mesele:

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

Burada bir polimorfizm yoktur, jenerik nesnenin gerçek türünü kullanır ve + = operatörünü çağırır, ancak bu başarısız olur, çünkü bu operatörün var olduğundan emin olamaz. Basit çözüm, kısıtlamada belirtmektir; basit çözüm imkansızdır çünkü operatörler statiktir ve statik yöntemler bir arayüzde olamaz ve (burada sorun) kısıtlamalar arayüz olarak gösterilir.

C # gereken gerçek bir kısıtlama türüdür, tüm arayüzler de kısıtlamalar olacaktır, ancak tüm kısıtlamalar arayüzler olmayacaktır, o zaman bunu yapabilirsiniz:

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;
    }
}

Uygulanacak tüm sayısal türler için bir IAritmetik yapma hakkında çok fazla konuşma yapıldı, ancak verimlilikle ilgili endişeler var, çünkü bir kısıtlama polimorfik bir yapı değil, CArithmetic bir kısıtlama yapmak bu sorunu çözecektir.

Çünkü arayüzler kalıtım yapısındadır ve statik yöntemler iyi miras almaz.

İstediğiniz şey, hem Tür hem de o türün herhangi bir örneği aracılığıyla statik bir yöntemin çağrılmasına izin verir. Bu en azından arzu edilen bir özellik olmayan belirsizliğe yol açacaktır.

Bunun önemli olup olmadığı, hangisinin en iyi uygulama olduğu ve bunu bir şekilde yapan performans sorunlarının olup olmadığı konusunda sonsuz tartışmalar olacaktır. Sadece desteklemeyerek C # bizi endişelenmekten kurtarır.

Ayrıca, bu arzuya uyan bir compilier'ın örnek ve statik yöntemler arasında daha katı bir ayrımla gelebilecek bazı optimizasyonları kaybetmesi muhtemeldir.

Bir sınıfın statik yöntemlerini ve statik olmayan yöntemlerini farklı arabirimler olarak düşünebilirsiniz. Çağrıldığında, statik yöntemler tekli statik sınıf nesnesine, statik olmayan yöntemler ise ele aldığınız sınıf örneğine çözümlenir. Bu nedenle, bir arabirimde statik ve statik olmayan yöntemler kullanırsanız, gerçekten bir uyumlu şeye erişmek için arabirimlerin kullanılmasını istediğimizde etkili bir şekilde iki arabirim bildirirsiniz.

Arabirim yöntemlerinin statik uygulamasını ya da Mark Brackett'in "sözde tür yöntemi" olarak ne tanıttığını eksik bir örnek vermek için:

Bir veritabanı deposundan okurken, herhangi bir yapının tablosundan okumayı işleyen genel bir DataTable sınıfımız vardır. Tüm tabloya özgü bilgiler, DB'den bir satır için de verileri tutan ve bir IDataRow arabirimi uygulaması gereken tablo başına bir sınıfa konur. IDataRow, veritabanından okunacak tablonun yapısının bir açıklamasıdır. DataTable, DB'den okumadan önce IDataRow veri yapısını istemelidir. Şu anda şöyle görünüyor:

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, her tablonun okuması için yalnızca bir kez gereklidir, bir örnek daha başlatmak için ek yük en az düzeydedir. Ancak, bu durumda burada iyi olurdu.

Bilginize: Arayüz için uzantı yöntemleri oluşturarak, istediğiniz şeye benzer bir davranış elde edebilirsiniz. Genişletme yöntemi paylaşılan, geçersiz kılınamayan statik bir davranış olacaktır. Ancak, ne yazık ki, bu statik yöntem sözleşmenin bir parçası olmayacaktır.

Arayüzler, tanımlanmış mevcut işlevselliğin soyut kümeleridir.

Bu arabirimdeki bir yöntemin statik olarak davranıp davranmayacağı, arabirimin arkasında gizlenmesi gereken bir uygulama ayrıntısıdır . Bir arabirim yöntemini statik olarak tanımlamak yanlış olur çünkü yöntemi gereksiz yere belirli bir şekilde uygulamaya zorlarsınız.

Yöntemler statik olarak tanımlandıysa, arabirimi uygulayan sınıf olabildiğince kapsüllenmez. Kapsülleme nesne yönelimli tasarım için çabalamak için iyi bir şeydir (nedenine girmeyeceğim, bunu buradan okuyabilirsiniz: http://en.wikipedia.org/wiki/Object-oriented ). Bu nedenle arabirimlerde statik yöntemlere izin verilmez.

Statik sınıflar bunu yapabilir, böylece genel olarak kullanılabilirler. Bunun yerine istenen sonuçları elde etmek için bir Singleton uygulamak zorunda kaldım.

"Kullanıcı", "Takım", vb gibi her varlık türü için "Oluştur", "Oku", "Güncelle", "Sil" gibi CRUD yöntemlerini uygulayan bir grup Statik İş Katman sınıfları vardı. Sonra bir temel oluşturdum CRUD yöntemlerini uygulayan Business Layer sınıfı için soyut bir özelliğe sahip olan denetim. Bu, temel sınıftan "Oluştur", "Oku", "Güncelle", "Sil" işlemlerini otomatikleştirmemi sağladı. Statik sınırlama nedeniyle bir Singleton kullanmak zorunda kaldım.

Çoğu insan OOP Sınıfları da nesneler olduğunu unutmak gibi görünüyor, ve bu nedenle bazı nedenlerden dolayı c # "statik yöntem" olarak adlandırılan iletileri vardır. Örnek nesneler ve sınıf nesneleri arasındaki farklılıkların var olması, yalnızca dildeki kusurları veya eksiklikleri gösterir. C # hakkında iyimser ...

Tamam burada bir 'tür yöntemi' gerekli bir örnek. Bazı kaynak XML tabanlı sınıflardan birini oluşturuyorum. Yani benim

  static public bool IsHandled(XElement xml)

her sınıfı sırayla çağırır.

İşlev statik olmalıdır, aksi takdirde uygunsuz nesneler oluşturmak için zaman harcarız. @Ian Boyde'nin belirttiği gibi, bir fabrika sınıfında yapılabilir, ancak bu sadece karmaşıklık katar.

Sınıf uygulayıcılarını uygulamaya zorlamak için arayüze eklemek güzel olurdu. Bu önemli bir ek yüke neden olmaz - sadece derleme / bağlantı zamanı kontrolüdür ve vtable'ı etkilemez.

Bununla birlikte, bu oldukça küçük bir gelişme olacaktır. Yöntem statik olduğundan, ben arayan olarak, açıkça çağırmak gerekir ve bu yüzden hemen uygulanmadıysa derleme hatası almak. Arayüzde belirtilmesine izin vermek, bu hatanın geliştirme döngüsünde marjinal olarak daha erken geldiği anlamına gelir, ancak bu diğer kırık arayüz sorunlarına kıyasla önemsizdir.

Bu nedenle, dengede muhtemelen en iyi durumda olan küçük bir potansiyel özelliktir.

Statik bir sınıfın, statik elemanlarla bir sınıfın özel bir örneğini oluşturarak Microsoft tarafından C # 'da uygulanmış olması, statik işlevselliğin nasıl elde edildiğinin tuhaflığıdır. Bu teorik bir nokta değil.

Bir arabirim, sınıf arabiriminin veya onunla nasıl etkileşime girdiğinin bir tanımlayıcısı OLMALIDIR ve statik olan etkileşimleri içermelidir. Arayüzün genel tanımı (Meriam-Webster'den): farklı şeylerin buluştuğu ve birbiriyle iletişim kurduğu veya etkilediği yer veya alan. Bir sınıfın veya statik sınıfların statik bileşenlerini tamamen atladığınızda, bu kötü çocukların nasıl etkileşime girdiğinin büyük bölümlerini görmezden geliriz.

Statik sınıflarla arayüzleri kullanabilmenin oldukça yararlı olacağına dair çok açık bir örnek:

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

Şu anda, ben hiçbir şey unutmadım emin olmak için herhangi bir denetim olmadan bu yöntemleri içeren statik sınıfları yazmak. OOP'tan önceki kötü programlama günleri gibidir.

C # ve CLR, Java'nın yaptığı gibi arabirimlerdeki statik yöntemleri desteklemelidir. Statik değiştirici bir sözleşme tanımının bir parçasıdır ve özellikle davranış ve dönüş değerinin yine de çağrıdan çağrıya değişebilmesine rağmen örneğe göre değişmediği anlamına gelir.

Bununla birlikte, bir arabirimde statik bir yöntem kullanmak istediğinizde ve bunun yerine bir ek açıklama kullanmamanızı öneririz. Aradığınız işlevselliği alacaksınız.

Kısa cevap "sıfır kullanışlı olduğu için" olduğunu düşünüyorum. Bir arabirim yöntemini çağırmak için türün bir örneğine ihtiyacınız vardır. Örnek yöntemlerden istediğiniz statik yöntemleri çağırabilirsiniz.

Soru, C # başka bir anahtar kelime, tam olarak bu tür bir durum için ihtiyacı olduğunu düşünüyorum. Dönüş değeri yalnızca çağrıldığı türe bağlı olan bir yöntem istiyorsunuz. Adı geçen tür bilinmiyorsa buna "statik" diyemezsiniz. Ancak tür bir kez bilindiğinde statik hale gelir. "Çözülmemiş statik" fikirdir - henüz statik değildir, ancak alıcı tipini öğrendikten sonra, öyle olacaktır. Bu oldukça iyi bir kavram, bu yüzden programcılar bunu istiyorlar. Ancak tasarımcıların dil hakkında düşünme şekline pek uymadı.

Kullanılabilir olmadığından, aşağıda gösterilen şekilde statik olmayan yöntemleri kullanmaya başladım. Tam olarak ideal değil, ama en azından benim için değil, daha anlamlı bir yaklaşım göremiyorum.

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

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

Nesneye yönelik kavramlara göre Sınıflar tarafından uygulanan arabirim ve nesne kullanılarak bu uygulanan işleve (veya yöntemlere) erişmek için sözleşmesi vardır.

Dolayısıyla, Interface Contract yöntemlerine erişmek istiyorsanız nesne oluşturmanız gerekir. Statik yöntemlerde her zaman izin verilmez. Statik sınıflar, yöntem ve değişkenler hiçbir zaman nesneye ihtiyaç duymaz ve o alanın (veya sınıfın) nesnesi oluşturulmadan belleğe yüklenmez veya Nesne Oluşturma gerektirmediğini söyleyebilirsiniz.

kavramsal olarak , bir arabirimin statik yöntemler içeren bir sözleşme tanımlamamasının bir nedeni yoktur.

Mevcut C # dili uygulaması için kısıtlama, bir temel sınıfın ve arabirimlerin mirasının ödenmesine bağlıdır. "Class SomeBaseClass", "ISomeInterface" arabirimini ve "SomeDerivedClass sınıfı" arabirimini uygularsa, SomeBaseClass, ISomeInterface "arabirimi de uygularsa, bir arabirim yöntemini uygulamak için statik bir yöntem derleme başarısız olur çünkü statik yöntem bir örnek yöntemiyle aynı imzayı ( arayüzü uygulamak için temel sınıfta bulunmalıdır).

Statik bir sınıf işlevsel olarak bir tektona özdeştir ve daha temiz sözdizimine sahip bir tektonla aynı amaca hizmet eder. Bir singleton bir arabirim uygulayabildiğinden, statikle arabirim uygulamaları kavramsal olarak geçerlidir.

Bu nedenle, örneğin, C # ad çakışması sınırlaması ve miras boyunca aynı ada sahip statik yöntemler sınırlanır. C # 'ın statik yöntem sözleşmelerini (arayüzler) desteklemek için "yükseltilememesi" için bir neden yoktur.

Bir sınıf bir arabirim uyguladığında, arabirim üyeleri için örnek oluşturur. Statik türün bir örneği olmasa da, arabirimde statik imzalara sahip olmanın bir anlamı yoktur.