C # 'da arayüzler nasıl kullanılmaz

Bir uygulama tasarlarken, genellikle arayüzler ve soyut sınıflar kullanmanız gerekecektir. Bu makale, "arayüz kötüye kullanımının" bazı yaygın örneklerini ve bunlardan kaçınmak için kullanabileceğimiz stratejileri tartışmaktadır. Ayrıca, "bir arayüze programlayın, bir uygulamaya değil," ilkesinin ne anlama geldiği tartışılır.

Arayüz nedir?

Öncelikle, arayüzleri ve programlamada neden gerekli olduklarını anlayalım. Arayüz kesinlikle bir sözleşmedir; herhangi bir uygulaması yoktur. Bir arabirim yalnızca üye bildirimlerini içerir. Yöntem bildirimleriniz olabilir ancak tanımlarınız olamaz. Bir arabirimde bildirilen üyeler, arabirimi genişleten veya uygulayan türlerde (sınıflar ve yapılar) uygulanmalıdır. Bir arayüz alan içeremez. Bir arayüz, veri üyelerine sahip olamadığı için serileştirilemez. Dediğim gibi, bir arayüzde sadece beyanlar olabilir, tanımları olamaz.  

Arayüzlerde değişiklik yapmaktan kaçının 

Bir arabirimi genişleten bir sınıf veya yapı, tüm üyelerini uygulamalıdır. Uygulama değişirse, kodunuz yine de çalışacaktır. Bununla birlikte, sözleşme, yani arayüz değişirse, arayüzü genişleten tüm türlerdeki uygulamaları değiştirmeniz gerekecektir. Diğer bir deyişle, arayüzde yapılacak herhangi bir değişiklik, arayüzü genişleten tüm türleri etkileyecektir. Arayüzü genişleten tipler sözleşmeye uygun olmalıdır. Bu nedenle, arayüzleri yalnızca nadiren değiştirmeniz gerektiğinde kullanın. Ayrıca, genellikle mevcut olanı değiştirmektense yeni bir arayüz oluşturmak daha iyidir. 

Bir uygulamaya değil, bir arayüze programlayın

Ara sıra "bir uygulamaya değil, bir arayüze programlayın" sözlerini duymuş olabilirsiniz. Kodunuzda arayüzler kullanıyor olabilirsiniz, ancak hala uygulamaya programlıyordunuz. Şimdi iki yaklaşım arasındaki farkı inceleyelim.

Bir arayüze programlama yaparken, somut bir uygulama yerine en genel soyutlamayı (bir arayüz veya soyut bir sınıf) kullanırsınız. Arayüzler tekdüzeliği garanti ettiğinden, bir arayüze programlama, benzer nesneleri tek tip bir şekilde işleyebileceğiniz anlamına gelir. Bunu yaparken, uygulamadan ayrışmış olursunuz - yani, uygulamalarınız değişebilir. Bu, tasarımlarınıza da esneklik katar.

Aşağıdaki kod parçacığı, bir arabirime programlamayı gösterir. Birkaç yöntemin bildirimini içeren IRepository adlı bir arabirim düşünün. ProductRepository ve CustomerRepository sınıfları, IRepository arayüzünü genişletir ve aşağıda gösterildiği gibi IRepository arayüzünde bildirilen yöntemleri uygular.

genel arabirim IR deposu

    {

        // Bazı kodlar

    }

    public class ProductRepository: IRepository

    {

        // Bazı kodlar

    }

    public class CustomerRepository: IRepository

    {

        // Bazı kodlar

    }

Aşağıdaki kod, ProductRepository'nin bir örneğini oluşturmak için kullanılabilir.

IRepository repository = new ProductRepository ();

Buradaki fikir, IRepository arayüzünü uygulayan herhangi bir sınıfı burada kullanabilmenizdir. Dolayısıyla aşağıdaki ifade de geçerlidir.

IRepository repository = new CustomerRepository ();

Bir uygulamaya programladığınızda, bu tekdüzelik kaybolur. Bunun yerine, kodunuzdaki davranışı kontrol etmek için tipik olarak "if..else" veya "switch..case" gibi bazı yapılara sahip olursunuz.

Arayüzlerin aşırı kullanımından kaçının

Her sınıfı bir arayüzle ilişkilendirmek iyi bir uygulama değildir. Arayüzlerin bu şekilde aşırı kullanımı gereksiz karmaşıklık yaratır, kod fazlalığına neden olur, YAGNI'yi ihlal eder ve kod tabanının okunabilirliğini ve sürdürülebilirliğini azaltır. Arayüzler, aynı davranışa sahip nesneleri gruplamak için kullanılır. Nesneler aynı davranışa sahip değilse, bu gruplamaya gerek yoktur. Birden fazla uygulamasına sahip olmayacağınız zaman arayüzleri kullanmak, arayüz aşırı kullanımına bir örnektir.

Sınıfın genel üyeleriyle eşleşen bir sınıf için arayüz oluşturmak oldukça yaygındır. Bunu yaparken hiçbir değer katmazsınız - gerçek bir soyutlama eklemeden sınıfın arayüzünü kopyalarsınız.

Şimdi arayüzlerin nasıl aşırı kullanıldığına dair bir örneğe bakalım. IProduct adlı aşağıdaki arabirimi düşünün.

genel arabirim IProduct

    {

        int Id {get; Ayarlamak; }

        string ÜrünAdı {get; Ayarlamak; }

        double Fiyat {get; Ayarlamak; }

        int Miktar {get; Ayarlamak; }

    }

Ürün sınıfı, IProduct arayüzünü aşağıda gösterildiği gibi genişletir.

public class Ürün: IProduct

    {

        public int Id {get; Ayarlamak; }

        public string ProductName {get; Ayarlamak; }

        halka açık çift Fiyat {get; Ayarlamak; }

        public int Miktar {get; Ayarlamak; }

    }

Açıkçası, arayüz ve uygulaması aynı olduğu için IProduct arayüzüne ihtiyacımız yok. Yedek kod gereksizdir.

Başka bir örneğe bakalım. Aşağıdaki kod parçacığı, Kaydet ve Güncelle olmak üzere iki yöntemin bildirimine sahip olan IProductManager adlı bir arabirimi gösterir.

 genel arabirim IProductManager

    {

        void Save (IProduct ürünü);

        geçersiz Güncelleme (IProduct ürünü);

    }

IProductManager arabirimi, ProductManager sınıfının genel yöntemlerinin bildirimlerini içerir. ProductManager sınıfı şu şekilde görünür.

 genel sınıf ProductManager: IProductManager

    {

        public void Save (IProduct ürünü)

        {

           // Uygulamanızı buraya yazın

        }

        public void Update (IProduct ürünü)

        {

            // Uygulamanızı buraya yazın

        }

    }

IProduct ve IProductManager arabirimleri, arabirim aşırı kullanımına örneklerdir. Bu arayüzlerin her ikisinin de tek bir uygulaması vardır ve hiçbir değer katmazlar.

Arayüzleri kullanarak kodunuzdaki gereksiz bağlantıları kaldırabilir ve kodunuzu kolayca test edilebilir hale getirebilirsiniz. Bununla birlikte, arayüzlerin aşırı kullanımından kaçınılmalıdır. Arayüzleri yalnızca birden fazla uygulaması olduğunda kullanın. Arayüzleri, oynayacak birçok rolü olan veya birden fazla sorumluluğu olan bir sınıfınız olduğunda da kullanabilirsiniz. Bu durumda, sınıfınız her rol için bir tane olmak üzere birden çok arabirim uygulayabilir.