Adaptör Tasarım Modeli

Evlerimizden örnek verelim, hepimiz duvarlarımıza monte edilmiş elektrik prizlerini görmüşüzdür. Bu prizlerle ilgili garip bir gerçek var ki, her ülkenin kendine özgü elektrik prizi tarzı vardır. Bu nedenle akıllı telefon üreticileri, ülkeye özgü farklı tarzda şarj adaptörleri üretiyor.

Bir başka harika örnek de Apple'ın Hyperdrive'ı olabilir. Bu kadar çok cihazı tek bir USB bağlantı noktasına bağlar. Burada hyperdrive, Adaptör görevi görür.

Adaptör ayrıca sarıcı olarak da bilinir. farklı nesneler tarafından kullanılabilecek nesneleri sarmasına neden olur.

Önce UML'yi görelim.

1. Temelde client kalıbı kullanmak isteyen sınıftır. Çağıran sınıf.
2. Sadece hizmet edebileceğimiz client istekler , doğrudan bir HAS-A ilişkisine sahip olabiliriz ve onunla işimiz bitebilir. Ama sorun başka bir belirli_talep olduğunda ortaya çıkar ve diyelim ki başka bir istek tarafından hizmet verilir , bu durumda başka bir HAS-A ilişkisi kurmamız gerekir ve bu her yeni gereksinimle tekrar ortaya çıkabilir. Sorunu görüyorsunuz, her yeni istek geldiğinde bunu müşteri sınıfına eşlememiz gerekiyor, şimdi bu yaklaşımda neyin yanlış olduğunu tartışacaksınız, eğer bunu her bir istek için yaparsanız kodunuz “ Aç ” uyarınca genişletilemez. -Kapalı prensibi ” Değişikliğe Kapalıyız .Specific_request()class Adapteeclass Adaptee2

Bu kaosla başa çıkmak için, yeni bir istek kavramını soyutlayabiliriz ve soyutlamanın müşteri tarafından yapılan bir isteğin delegasyonunu ele almasına izin verebiliriz. Yukarıdaki UML'de, interface ITarget.

Hadi kodlamaya geçelim.

Örnek, Diyelim ki uygulamamız bir XML dosyasından veri okuyor ve bugünün amacına hizmet ediyor ama yarın uygulamamızın JSON'u desteklemesini istiyorsak ne olacak ? İşte o zaman Adapter tasarım modelini kullanabiliriz.

Bu problem için mimariyi tasarlayalım. Aşağıdaki şemada 2 sınıfımız var XMLAdapteeve JSONAdapteebu sınıflar, interface IEmployeeDetailshangi soyut yönteme sahip olduğunu miras alacaklar GetData(), böylece sınıflarımız kendi mantıkları için kendi uygulamalarını kullanabilirler.

XML'de sonuç istiyorsa örneği class programenjekte edebilir veya JSON'da sonuç istiyorsa örneği geçebilir .XMLAdaptee’sAdapter objectJSONAdaptee’s

Şimdi, yarın YAML için başka bir gereksinim gelirse, o zaman basitçe sınıf oluşturabilir YAMLAdapteeve kendi mantığını GetData() method.

UML'miz şöyle görünür:

Müşterimiz interface ITargettarafından çağrılacak bir tane oluşturalım.

Sonraki, class Adapter,

uygulayacak ITarget: bu sınıf ayrıca şunları da içerir interface IEmployeeDetails: bu arayüz, benzer mimariyi her iki sınıfta da tutmak için hem XML hem de JSON Adaptelerimiz tarafından uygulanacaktır, bu nedenle istemci kodumuz değişmeyecektir.

Bir oluşturalım interface IEmployeeDetails:

bir class employeeveentity:

Bir class XMLAdapteexml verilerini yüklemek için. Şimdilik kodun kendisinden veri üretebiliriz.

Sonraki, class JSONAdaptee:

Son fakat en az değil, arayanımız class program:

XML verileri için çıktı: satır numarası 15program.cs

JSON verileri için çıktı, sadece koddaki yukarıdaki satırı kaldırın. satır numarası 18program.cs

Mükemmel! Umarım bu makaleyi beğenmişsinizdir ve öğrendiklerinizi kendi uygulamalarınıza uygulamak için ilham almışsınızdır. Teşekkür ederim.

Mutlu kodlama!!

Beni Linkedin'de yakala