Neden bir programcı uygulamayı arayüzden ayırmak ister?

Köprü tasarım modeli, uygulamayı bir programın arayüzünden ayırır.

Bu neden avantajlıdır?

Uygulamayı arabirimden bağımsız olarak değiştirmenizi sağlar. Bu değişen gereksinimlerle başa çıkmanıza yardımcı olur.

Klasik örnek, bir arabirim altındaki depolama uygulamasını, sistemin geri kalanını değiştirmek zorunda kalmadan daha büyük, daha iyi, daha hızlı, daha küçük veya başka bir şeyle değiştirmektir.

Daniel'in cevabına ek olarak, arayüzü uygulamadan polimorfizm gibi kavramlarla ayırmak, benzer şeyleri farklı şekillerde yapan aynı arayüzün çeşitli uygulamalarını oluşturmanıza izin verir.

Örneğin, birçok dilde standart kütüphanede bir yerde bir akış kavramı bulunur . Akış, seri erişim için verileri tutan bir şeydir. İki temel işlemi vardır: Okuma (akıştan sonraki X bayt sayısını yükleme) ve Yazma (akışa X sayıda bayt veri ekleme) ve bazen üçüncüsü Ara (akışın "geçerli konumunu" sıfırlama) yeni bir konuma).

Bu yeterince basit bir kavram, ancak onunla yapabileceğiniz her şeyi düşünün. En belirgin olanı diskteki dosyalarla etkileşim kurmaktır. Bir dosya akışı, bir dosyadan veri okumanıza veya ona yazmanıza izin verir. Peki ya bunun yerine bir ağ bağlantısı üzerinden veri göndermek isteseydiniz?

Doğrudan uygulamalara güveniyorsanız, aynı verileri bir dosyaya kaydetmek veya ağ üzerinden göndermek için tamamen farklı iki rutin yazmanız gerekir. Ancak bir akış arayüzünüz varsa , veriyi gitmesi gereken yere göndermenin belirli ayrıntılarını kapsayan iki farklı uygulama ( FileStreamve NetworkStream) oluşturabilirsiniz ve daha sonra yalnızca bir kez dosya kaydetmeyle ilgili kodu yazmanız gerekir . Aniden sizin SaveToFileve SendOverNetworkrutinleriniz çok daha basit: sadece uygun türde bir akış oluşturdular ve SaveDatabir akış arayüzünü kabul eden rutine aktarıyorlar - gerçekleştirebildiği sürece hangi türün bakımına gerek yok Yazma işlemi - ve verileri akışa kaydeder.

Bu, veri biçiminiz değişirse, bunu birden çok farklı yerde değiştirmeniz gerekmediği anlamına gelir. Veri kaydetme kodunuzu bir akış alan bir yordamda merkezileştirirseniz, güncellenmesi gereken tek yer budur, bu nedenle ikisini de değiştirmeniz gerektiğinde yanlışlıkla bir yeri değiştirerek bir hatayı yanlışlıkla tanıtamazsınız. Bu nedenle arayüzleri uygulamalardan ayırmak ve polimorfizm kullanmak, okunması ve anlaşılması daha kolay olan ve hatalara sahip olma olasılığının daha düşük olduğu kodu oluşturur.

Burada birbirleriyle ilişkili olsalar da, gerçekten çok farklı iki sorunuz var.

Daha genel soru, başlıkta sorulan soru, arayüzü neden genel olarak uygulamadan ayırmak istiyorsunuz? İkinci soru, köprü modelinin neden yararlı olduğudur. İlişkilendirilmişlerdir, çünkü köprü deseni, arabirimi uygulamadan ayırmanın belirli bir başka yoludur ve bazı başka sonuçları da vardır.

Genel soru her programcının anlaması için hayati bir şeydir. Bir programdaki değişikliklerin her yerde yayılmasını önleyen şey budur. İnsanların bunu kullanmadan programlayabildiğini hayal edemiyorum.

Bir programlama dilinde basit bir toplama ifadesi yazdığınızda, bu zaten bir soyutlamadır (matris veya benzeri bir şey eklemek için operatör aşırı yüklemesi kullanmasa bile), sonunda yürütülmeden önce oldukça fazla başka koddan geçer bilgisayarınızdaki bir devrede. Arabirimden ("3 + 5" diyelim) uygulamadan (bir grup makine kodu) ayrılma olmasaydı, uygulama her değiştiğinde (bir bilgisayarda çalıştırmak istediğiniz gibi) kodunuzu değiştirmeniz gerekir. yeni işlemci).

Basit bir CRUD uygulamasında bile, her yöntem imzası, geniş anlamda, uygulamanın arabirimidir.

Tüm bu soyutlama türleri aynı temel hedefe sahiptir - çağıran kodun, uygulayıcıya gerektiği kadar bilgi veren en soyut şekilde niyetini ifade etmesini sağlayın. Bu, aralarında mümkün olan en az bağlantıyı sağlar ve kodun mümkün olduğunca değiştirilmesi gerektiğinde dalgalanma etkisini sınırlar.

Kulağa basit geliyor, ancak pratikte karmaşıklaşıyor.

Köprü deseni, belirli uygulama parçalarını arayüzlere ayırmanın spesifik bir yoludur. Desenin sınıf diyagramı açıklamadan daha bilgilendiricidir. Bu, bir köprüden ziyade takılabilir modüllere sahip olmanın bir yolu gibidir, ancak köprüye adını verdiler, çünkü genellikle modüllerin arabirimden önce oluşturulduğu yerlerde kullanılır. Yani benzer mevcut uygulamalar için ortak bir arayüz oluşturmak fark "köprüler" tür ve herhangi bir uygulama ile çalışmak için kod sağlar.

Yani, bir kelime işlemciye bir eklenti yazmak istediğinizi, ancak birden çok kelime işlemcide çalışmasını istediğinizi varsayalım. İhtiyacınız olan kelime işlemci tabanlı işlevselliği özetleyen (ve bunları değiştiremeyeceğiniz için her kelime işlemci tarafından uygulanması gereken) bir arayüz ve desteklemek istediğiniz her kelime işlemci için bu arayüzün bir uygulayıcısı oluşturabilirsiniz. Daha sonra uygulamanız bu arayüzü arayabilir ve her bir kelime işlemcisinin ayrıntıları hakkında endişelenmeyebilir.

Aslında bundan biraz daha ayrıntılı, çünkü her sınıf gerçekten bir sınıf hiyerarşisi olabilir (bu yüzden, sadece soyut bir kelime işlemci değil, her biri için somut uygulamalara sahip soyut bir Belge, soyut TextSelection, vb.), Ancak aynı fikir.

Bu bir cephe gibidir, ancak bu durumda soyutlama katmanı, aynı arabirimi birden çok altta yatan sisteme sağlamaya odaklanmıştır.

Somut uygulayıcı yöntemlere veya kuruculara aktarılacağı ve çağrılan asıl uygulamayı belirleyeceğinden, Kontrolün Ters Çevirilmesi ile ilgilidir.