C# Gevşek Bağlantı için Arayüzler — Tim Corey’nin Ders 16’dan Açıklama

Formları Bağlama Kolay — Doğru Bir Şekilde Bağlamak Değil

1:18'de Tim, Create Prize ve Create Team UI öğelerini bağlamaya başlar. Bu adımın, başka bir formu çağırmanın zor olmadığı için değil, genellikle insanların verileri geri doğru şekilde almanın da hata yapmasıyla korkutucu gelebileceğini hemen fark eder.

Tim, başka bir form açmanın bir zorluk olmadığını açıklar — bu kısım kolaydır. Zorluk, bir formun başka bir forma uzun vadeli tasarım sorunları yaratmadan nasıl geri bildirim yapacağıdır. Bu, bağımlılıkların yerine sözleşmelerin tanımlanması fikrinin önem kazanmaya başladığı noktadır.

Sıkı Bağlamanın Cazibesi

1:34 civarında Tim, yaygın bir hatayı açıkça belirtir: Create Tournament formunu Create Prize formuna doğrudan bağlamak. Bu yaklaşımda, bir sınıf tam olarak hangi diğer sınıfa konuştuğunu bilir.

Tim, bunun sıkı bağlama oluşturduğunu ve formların doğrudan birbirine bağımlı hale geldiğini açıklar. Bir form değişirse, diğeri etkilenir. Programın başka bir bölümü daha sonra aynı işlevselliği isterse, yeniden kullanılamaz.

Bunun derlenip çalışabileceğini ama özellikle daha büyük sistemlerde veya profesyonel ortamlarda uzun vadeli bir tasarım seçimi olmadığını vurgular.

Kod Yazmadan Önce Adımları Düşünme

2:02'de Tim duraksayıp adımları yazmıyor, doğrudan koda geçmiyor. Şunları listeler:

1. Create Prize formunu çağır

2. Bir PrizeModel geri al

3. Seçilen ödüller listesine ekle

Tim, öncelikle adımları yazmanın mantık hatalarından kaçınmaya yardımcı olduğunu ve kodun amacını netleştirdiğini açıklar. Bu yapılandırılmış düşünce, arayüzler tanıtıldığında özellikle önem kazanmaktadır, çünkü arayüzler ne olması gerektiğini değil, nasıl yapılacağını tanımlar.

Referans Türleri ve Neden Dönüş Değerlerine Her Zaman İhtiyaç Duyulmadıkları

4:56 civarında Tim, modellerin taşınırken önemli bir detayı açıklar. İzleyicilere nesnelerin kopyalarını değil, adreslerini dolaştırdıklarını hatırlatır.

Ödül veri bağlantısı aracılığıyla kaydedildiğinde, model zaten ID'si ile doludur. Tim, modelin yeniden döndürülmesinin genellikle gereksiz olduğunu çünkü örneğin zaten değiştirildiğini belirtir.

Bu, arayüzlerin verileri körü körüne taşımak için değil, tamamlama ve sorumluluğu sinyal vermek için var olduklarını pekiştirir.

Önce Modeli Geçirmenin Kötü Bir Fikir Olduğu

6:42'de Tim, aynı örneği iki formun paylaşması için PrizeModel'i formun yapılandırıcısına geçirme fikrini tartışır.

Gerçek bir kullanım örneğinde neden başarısız olduğunu açıklar: Kullanıcı formu iptal ederse, listenizde boş veya geçersiz bir ödülle kalırsınız. Tim, iki sınıfın örnek verileri paylaşabileceği için paylaşmaları gerektiği anlamına gelmediğini gösterir.

Bu an, arayüzlerin davranışı tanımladığını, veri depolamasını değil pekiştirir.

Çağıran Formu Direkt Geçmek Daha da Kötü

7:46 civarında Tim, başka bir yaygın yaklaşımı ele alır: Create Tournament Form'un tamamını Create Prize Form'a geçirmek ve SavePrize gibi bir genel yöntem çağırmak.

Tim bunun daha da kötü olduğunu açıklar:

• Ödül formu şimdi kendisini çağıran sınıfı tam olarak bilir

• Ödül formunu başka bir ilgisiz sınıf yeniden kullanamaz

• Sınıf tek bir kullanım durumu ile kısıtlanır

Bunun kaçınmaya çalıştığımız sıkı bağlama olduğunu açıkça isimlendirir.

Arayüzleri Sözleşmeler Olarak Tanıtma

9:01'de Tim çözümü, bir arayüzü tanıtır.

interface anahtar kelimesini kullanarak yeni bir arayüz oluşturur ve adını IPrizeRequester koyar. Tim izleyicilere bir arayüzün:

• Bir sınıf olmadığını

• Somut yöntemler içermediğini

• Bir sözleşme tanımlamak için var olduğunu hatırlatır.

Arayüz, tek bir yöntem içerir:

• PrizeComplete(ÖdülModeli model)

Tim, bu yöntemin nasıl gerçekleştiğini değil, ne olması gerektiğini tanımladığını açıklar.

Ara Yüz Üyeleri ve Sorumlulukları

09:40'ta Tim, bu arayüzü uygulayan kişinin bu yöntemi desteklemeyi kabul ettiğini açıklar. Arayüz, varsayılan olarak genel üyelere sahiptir ve örnek veri bildirmez.

Tim'in, ara yüzlerin depolama değil, yetenek tanımladığını açıkladığı yer burasıdır. Yöntem çağrıldığında, hangi işlemin yapılacağına uygulayan sınıf karar verir.

Bir Sınıf Yerine Arayüz Türü Geçirme

10:19'da Tim, somut bir form yerine bir IPrizeRequester kabul edecek şekilde Create Prize Form yapıcısını değiştirir.

Bunun anlamını şöyle açıklar:

Birisi formu arayacak

Form bunun kim olduğunu bilmiyor

Tek gereklilik, çağıranın arabirimi uygulamasıdır.

Bu, pratikte gevşek bağlamadır. Ödül formu, belirli bir sınıfa değil bir arayüz türüne bağlıdır.

Arayüz Örneğini Daha Sonra Kullanmak İçin Saklama

11:06'da, Tim arayüz örneğini sınıf düzeyinde saklıyor. Konstrüktör parametrelerinin saklanmadığı sürece sadece konstrüktör içinde var olduğunu açıklar.

Bu, ödül formunun daha sonra buton tıklama olayının içinden PrizeComplete'i çağırmasına olanak tanır.

Uygulayan Sınıfı Geri Çağırma

11:49'da Tim, önemli anı gösteriyor:

callingForm.PrizeComplete(model);

Ödül formunun artık arayüzü uygulayan kişiye geri döndüğünü ve şöyle dediğini açıklıyor:

"Tamamladım ve işte tamamlanan model."

Bu çağrıdan sonra form kapanır. Bu, ödülün yalnızca oluşturma işlemi başarılı olduğunda ekleneceğini garanti eder.

Turnuva Formunda Arayüzü Uygulama

13:29'da, Tim Turnuva Oluşturma Formu'na geçer ve arayüzü uygular.

Bu anahtar kelimeyi 13:58'de açıklıyor ve onu mevcut örnek — bellekteki gerçek nesne — olarak tanımlıyor. Bu şekilde, form adresini devrediyor, ancak yalnızca arayüz sözleşmesi aracılığıyla.

Birden Fazla Arayüz, Tek Sınıf

18:41'de Tim, ikinci bir arayüz olan ITeamRequester'ı tanıtıyor.

Bir sınıfın yalnızca bir temel sınıftan (Form gibi) miras alabileceğini, ancak birden fazla arayüzü uygulayabileceğini açıklar. Bu, bir sınıfın birden fazla kalıtım olmadan birden fazla ilişkisiz davranışı desteklemesine olanak tanır.

Tim, arayüzlerin kod getirmediğini — yalnızca gerekli yöntemleri tanımladığını vurgular.

Kalıplar, Tutarlılık ve Hata Tespiti

Yaklaşık 42:08'de, Tim kalıpların neden önemli olduğunu düşünerek yansıtıyor. Aynı arayüze dayalı yapının tekrarlanması, eksik adımları belirgin hale getirir ve hata ayıklamayı kolaylaştırır.

Tim, her şeyi aklında tutmaya çalışmak yerine, tutarlı kalıplar kullanarak ve her şeyi yazıya dökerek çalışmayı teşvik eder. Ona göre, iyi tasarım mükemmellikle ilgili değil — netlik, yapı ve gelecekteki değişiklikleri kolaylaştırmakla ilgilidir.

Sonuç

16. Derste, Tim Corey arayüzlerin nasıl gevşek bağlılık sağladığını göstermek için gerçek bir WinForms kullanım senaryosu kullanıyor. Soyut örneklere güvenmek yerine, arayüzlerin nasıl işlediğini gösteriyor:

Sözleşmeleri tanımlayın

• Sınıfları birbirinden ayır

• Tek bir sınıfta birden fazla arayüzü destekleyin

• Sıkı bağlanmayı önleyin

• Uzun vadeli esnekliği artırın

Dersin sonunda, uygulama sadece çalışmakla kalmaz — büyümeyi, yeniden kullanılabilirliği ve açıklığı destekleyen bir yapıya sahiptir. Tim'in yaklaşımı, arayüzleri gerçek dünya C# geliştirmesinde pratik, amaçlı ve gerekli hissettirir.

Bu arayüz ve gevşek bağlama kavramlarının eksiksiz ve uçtan uca uygulaması için, tüm adımların çalışan bir C# uygulaması içinde uygulandığı, test edildiği ve rafine edildiği tam 16. Ders videosunu izleyin.