Loose Coupling – Gevşek Bağlılık Prensibi

· 3 dk okuma · C#.NET · Nesne Yönelimli Programlama · OOP Prensipleri

Merhaba sevgili tasarım prensiplerine meraklı dostlarım.

Bu yazımda SOLID tasarım prensiplerinin içinde olmayan fakat Enterprise tasarım prensipleri içerisinde sayabileceğimiz Loose Coupling (Gevşek Bağlantı) İlkesinden bahsedeceğim. Böylece Interface’e daha farklı bir gözle bakabilir ve ISP (Interface Segregation Principle) ile DIP (Dependency Inversion Principle) prensiplerindeki kavramlara daha net bir yaklaşım sergileyebiliriz.

Loose Coupling ilkesini anlamak için “sıkı bağlantı” nın ne olduğunu anlamak gerekiyor sanırım. Bir sistem; içerisinde bulunan mekanizmanın çalışabilmesi için belirli bir nesneye mutlaka ihtiyaç duyuyorsa, o nesneye sıkı sıkıya bağlıdır. Bir gerçek hayat örneği ile bu kavramı anlatmaya çalışalım. Eğer iş dünyası personeline “Sıkı Bağlı” olsaydı o zaman iş ilanında direk personelin adı olması gerekirdi (düşünsenize bir iş ilanında “Türkay Ürkmez aranıyor yazdığını 🙂 “)! Oysa günümüzde iş ilanlarında sadece aranan yetkinlikler (yani Interface’ler) bulunuyor. Haliyle, bu yetkinlikleri taşıyan (bu interface’i implemente eden) kişiler ilgili ilana başvurup değerlendiriliyor.

Yani, bir organizasyonda (çoğu Hollywood filminde olduğu gibi) “bu işi yalnızca bay/bayan X yapabilir” cümlesi kuruluyorsa, o organizasyon X kişiyle “sıkı bağlantı” halindedir. Oysa bu cümle, şu biçimde kurulsaydı çok daha sağlıklı olurdu; “bu işi, şöyle yetkinliğe sahip herkes yapabilir”. İşte Loose Coupling ilkesinin öncelikli görevi de sistemi bu hale getirmektir.

Tam da bu kısımda, bu kavramın yaratıcısı Karl E. Weick’den bahsetmemek olmaz. Kendisi bir “Kurumsal Psikoloji uzmanı” ve hayatı bu alanda yaptığı çalışmalarla geçmiş bir teorisyen. 1975 yılının Şubat ayında Ulusal Eğitim Enstitüsü (National Institue Of Education – NIE) konferansında, “Eğitim Kurumlarında Gevşek Bağlantı Sistemi” isimli bir sunum yapar (meraklısı buradan ulaşabilir). İşte Loose Coupling ilk kez burada bu sunumda dile getirilir.

Bu ayrıntıyı burada belirtmemin sebebi şu; bugün büyük ölçekli yazılım projelerinde, işlerimizi büyük ölçüde standartlara kavuşturan (SOLID gibi) prensiplerin temelleri aslında bunun gibi sosyolojik, psikolojik veya diğer mühendislik alanlarında atılıyor. Yaşamakta olduğumuz dünyada, her şey birbirini o kadar makro düzeyde etkiliyor ki… Tek yapmamız gereken inovasyona her zaman açık olmak ve gözlemleyebilmek.

Peki, bu ilkeyi yazılım dünyası nasıl uyguluyor? Gelin bunu da bir örnekle görelim. Senaryomuz, bir ödeme işlemi üzerine olsun.

Tight Coupling (Sıkı Bağlantı) Örneği

Örneğimizde, KrediKartı isimli bir sınıfımız olsun. Bu sınıfın örneğini (instance) kullanan bir de OdemeIslemi sınıfımız var. Kodları ise şu şekilde:

Kredi Kartı sınıfı:

100313 2004 gevekbalant1

Ödeme işlemlerini üstlenecek olan sınıf:

100313 2004 gevekbalant2

Gördüğünüz gibi OdemeIslemi sınıfım oluşturucu metodunda (constructor) bizden KrediKarti nesne örneği istiyor. Daha sonra bu nesneyi, OdemeYap() metodunda kullanıyor. Burada, projenin ilerleyen safhalarında başka ödeme seçeneklerinin de gelebileceğini düşünürseniz; mimarinin oldukça sıkıntılı olduğunu göreceksiniz. İşte, size bir “sıkı bağlantı” örneği.

Hadi şimdi gelin bu bağlantıyı gevşetelim.

Loose Coupled (Gevşek Bağlantı) Örneği

Mademki gelecekte ödeme şekli değişiklik gösterecek, o halde buna göre bir önlem almamız gerekiyor. OdemeYap() metodunun, tüm ödeme araçlarında (PayPal, Kredi Kartı, SMS) bulunmasının şart olduğunu sanırım fark etmişsinizdir. Öyleyse kolları sıvayalım ve OdemeYap metodunu içeren bir Interface oluşturalım:

100313 2004 gevekbalant3

Pekâlâ, şimdi de OdemeIslemi sınıfımı bu mimariye göre tekrar yazıyorum:

100313 2004 gevekbalant4

Dikkat ettiğiniz gibi yaptığım tek değişiklik spesifik bir sınıf örneği yerine; parametre olarak IOdemeAraci interface’ini kullandım. Böylelikle; bu interface’i implemente eden tüm sınıfları bu metoda parametre olarak atayabileceğim. Doğal olarak; ilerleyen zamanlarda gelecek her yeni ödeme biçimi için OdemeIslemi sınıfında değişiklik yapmama gerek kalmayacak.

Son olarak; bu ilişkiyi grafik ile incelersek aşağıdaki çıktıyı göreceğiz:

100313 2004 gevekbalant5

Evet dostlar… Nesne Yönelimli Tasarım konulu bir makalemizin daha sonuna gelmiş bulunmaktayız. Sağlıcakla kalın.

Yorumlar (4)

Bu yorumlar eski siteden arşivlenmiştir.

  1. Kaan ·

    Hocam , bendeki şalterler attı. Dependecy Injection ile Gevşek Bağlantı ilkesi arasındaki fark nedir ? şu anda beynimde bir karınca yuvası hissiyati ile bilgisayarın başında oturuyorum. Visual Studio da örneğinizi yazdım , daha iyi anlaşılıyor fakat sanki kod yazarken bu düğümü atmak pek kolay olmayacakmış gibi geliyor. sanki Interface'ler ve classlar arasında devamlı bir gemici düğümü atmaya benziyor… Hakikaten yordunuz beni 🙂

    1. Emre ·

      Kaan arkadasimizin sorusu benim de aklima takildi hocam bir aciklik getirir misiniz?

    2. Bora Kaşmer ·

      Selamlar,

      7 yıl sonra gelen cevap 🙂 Dependency Injection creational bir tekniktir. Amacı belirlenen Interface’in tanımlandığı class’ın istendiğinde kolaylıkla değiştirilebilmesinin sağlanmasıdır. Ama bu direk kullanım aşamasında değil, yaratılma aşamasında yapılabilmektedir. Tabii aynı işlem burada da geçerlidir ama aracın yaratılma şekli işte gerçek farkı ortaya koymaktadır. Günümüzde .Net Core 3.X ile Scoped, Transient, Singleton şeklinde farklı yaratılma şekilleri vardır. Yani Dependency Injection daha çok Loose Coupling için değil yaratılma anında biftek yerden oluşturulması için daha çok kullanılmaktadır.

      İyi çalışmalar.

  2. Emre ·

    Bu kadar sade ve anlasilir olmasi cok guzel.

    Tesekkurler,

Yeni yorumlar yakında açılacak.