Arayüz (Interface) kullanımı ve Bağlaşımı kesmek (decoupling)

Arayüz (Interface) kullanımı tasarım kalıplarının(design patterns) kalbinde bulunur. Eğer şu zamana kadar tasarım kalıpları (design patterns) ile bir ilişkiniz olmadıysa arayüzlerin kullanımı sizlere fazla önemli gelememiş olabilir. Java dilinin kendi içerisinde arayüz kullanımı çok yogundur. Bunun başlıca sebeplerinden Java ‘nın alt yapısını kurulurken, Sun Microsystems mühendilerinin GOF (gang of 4) yazdığı kitaptan çok etkilenmeleri ve bunu uygulamaya sokmalarıdır. Arayüzlerin kullanımına en iyi örnek  java.sql paketinin içerisidir. Bu paket içerisinde çoğu eleman arayüzdür. Bu arayüzlerin gerçekleştirilmesi veritabanı sürücüleri yazan kişi, organizasyon veya fırmaların sorumluluğundadır. 

Arayüzlerin kullanılmasındaki başlıca sebebi bağlaşımı kesmektir (decoupling).  Bağlaşımı kesmek yazılım tasarımcılarının başlıca amacı olmalıdır. Java yı kullanmak sizi nesneye yönelik programcı yapmaz veya kalıtım (inheritance) veya polimofizm bilmek sizin tasarım kalıplarını bildiğiniz anlamına gelmez.  Bu makale size tasarım kalıplarını öğretmek değildir. Bu makalenin amacı bağlaşımı kesme konusu ile arayüzler arasındaki ilişkiyi sizlere göndermek.

Bağlaşımı kesme konusunun çıkış noktası uygulamayı parçalara ayırma ihtiyacından ileri gelmiştir. Peki uygulamayı parçalara ayırmanın faydaları nelerdir.

            1 -  Uygulamayı parçalara ayırmak bir çok kişi ve ekibi projeye dahil etmek demektir. Böylece proje süresi kısalacaktır. (Plansız programsız bir şekilde başlanırsa insan sayısının bir faydası olmaz.)

            2 -  Konusunda uzman kişiler projenin uzmanlık isteyen kısımları ile daha rahat ilgilenebilir. Örneğin iş mantığını yazan kişi ile html ve javascript uzmanı kişiler kolayca kendi uzmanlıkları olan proje kısımlarında çalışabilirler.(Gerçek hayatta bazı şartlar projenin herşeyi ile sizin ilgilenmeniz gerekebilir ama bu kovboy programcılık bu devirde artık bitmiştir.).

            3-  Bir projede ayrılan bir parça diğer başka bir projede kullanılabilir. Bu yaklaşım yeni projelerin daha kısa sürede tamamlanmalarına sebebiyet verecektir (projenin istenen sürede bitmesi herkesin amacı değil mi ?).

Peki bağlaşımı kesmek ne demektir ? Cevap : Bağlaşımı Kesmek (decoupling) parçalara ayrılan kısımların birbirleriyle nasıl bir ilişki içerisinde olmaları gerektiği ile alakalı bir konudur. Kısaca A parçası B parçasına ait bir kısmı kullanıyorsa o zaman A parçası B parçasına bağımlıdır diyebiliriz. İşte bu noktada  arayüzler (interface) devreye girer.  

Birbirine bağlı bir yapıyı kullanım diyagramı (uses diagram) ile göstermek istersek aşağıdaki şekil yeterli olacaktır.

Yukarıdaki diyagramda bir tarayıcı yapmak isteyen bir organizasyonun ortaya koyduğu yapı gözükmektedir. Bu diyagramı şunu göstermektedir : Bu tarayıcı 7 parçadan oluşur.

1. Main (ana başlangıç sınıfı)
2. Display (gösterimden sorumlu sınıf)
3. Parser (Html sayfalarını parçalayan sınıf)
4. Protocol (http, ftp gibi protoköllerin yönetildiği sınıf)
5. AST (Html lerin ağaç yapısına sokulduğu sınıf)
6. Page (Sayfa sınıfı)
7. Network (ağ bileşenleri ile ilgili sınıf)

Yukarıdaki modüllere derinlemesine girmeyeceğiz amacımız tarayıcı yapmak değil. Yukarıdaki ilişkide görüldüğü üzere Main parçası Display, Parser ve Protocol sınıfları ile sıkı sıkıya bağlıdır.  Şimdi soru şu. Eğer Display sınıfı değişirse bundan hangi parçalar etkilenir. Cevap :  Main sınıfı.

Peki Main değişti mi hangi sınıflar etkilenir ? Cevap : Parser ve Protocol sınıfları. Peki Parser ve Protocol sınıfları değiştiti mi hangi sınıflar etkilenir ? Cevap : Page ve Network ve ve ve ve ve ........

Yukarıdaki açmaz durumun adına domino taşı etkisi deniyor. Daha halk diliyle söylersek, “Ali yazar Veli bozar” semptomu. İşte bu durumlardan kaçınmak için bağlaşımı kesmek yani arayüz (interface) kullanmak gerekir.  Arayüz kullanmak ama nasıl ?  Bunun cevabını tek çırpıda vermek imkansızdır. Herşeyden önce sorunu anlamak herşeyden önce gelir. Şimdi yukarıda bahsedilen domino taşı etkisinden kurtulmanın yollarını arıyalım.

Arayüzlerin en önemli amacı bağlaşımı kesmektir.

 

 

 

 

 

 

 

 

 

 

 

Bağlaşımı kesme(decoupling)    java.util paketinin altındaki List arayüzü bunun en güzel örneklerindendir.

Yukarıdaki şekilde anlatmak isteğim olay List arayüzüne erişen değişik somut alt sınıfların olduğudur. Örneğin ArrayList somut sınıfı verileri ard arda tutarken, LinkList sınıfı bu verileri birbirine bağlar.  Fakat ben son kullanıcı bir yazılımcı olarak bu sınıfları kullanırken, bu sınıflara ait nesnelerin içerisinde nasıl veri atacağımı veya veri çekeğimi bilmem için List arayüzüne bakmamın yeterli olacağıdır. Kısacası sözlemeye (belirtim) bakıyorum çünkü ArrayList, LinkedList ve Vector sınıfları bu sözleşmeye uymaktadırlar.

Yukarıdaki kod örneğinde getTorba() yordamının (metod) ne tür bir torba nesnesi döndürdüğü benim umurumda değil çünkü benim torba değişkenimin tipi List arayüzü tipinde.

Temsili Esas Örnek

Dikkat; s şağıda anlatılacak olan örnek temsilidir.

Isındırma örneklerinden sonra esas örnek üzerine geçebiliriz. Bu örneğimizde bir e-posta istemcisinin çalışmasını taklit etmeye çalışacağız. Bu taklit etme aşamasında odaklanmamız gereken nokta  e-posta istemcisinin çalışmalarının hangi devrede olduğunu ekrana basan kısımdır (progress bar). E-posta istemcimizin ana parçaları aşağıdaki gibidir.

Üç parçadan oluşuyor.

1. Session sınıfı: Eposta sunucu ile oturumu(session) sağlayan sınıf
2. Folder sınıfı : Eposta sunucusundan alınan epostalar bu sınıf aracılığı ile disk üzerinde saklanıyor
3. Compactor sınıfı : Gelen epostaları sıkıştıran sınıf.

Yukarıdaki kullanım diyagramından anlaşılacağı üzere Session sınıfı Folder sınıfını kendi içerisinde kullanmaktadır.

Dediğimiz gibi bu taklit etme aşamasında odaklanmamız gereken nokta e-posta istemcisinin çalışmalarının hangi devrede olduğunu ekrana basan kısımdır (progress bar). İşte o kısım :

StandartOutReporter sınıfını kullanan Session ve Compactor sınıfları olsun. Bunun anlamı epostalar sunucundan alınırken ekrana bir bilgi ve bu epostalar sıkıştılırken bir bilgi basılacağı yönündedir.

Bu sayede tüm süreç bilgileri System.out.println() komutu ile konsola basılacaktır. Yani metin tabanlı bir e-posta istemcimiz olmuş oldu.

Dikkat ediniz Session ve Compactor sınıfları sıkı sıkıya StandartOutReporter sınıfına bağlıdırlar. İleride StandartOutReporter sınıfını report() yordamını  reportingAll() diye değiştirirse Session ve Compactor sınıfları bundan etkilenecektir. İşin dramatik tarafı StandartOutReporter sınıfınının geliştiricisi bunu canı ne zaman isterse yapabilir. Ortada bağlayıcı birşey henüz yok.

Yeni gereksinimler geliyor

Evet bu eposta istemcimiz müşteriler tarafından beğenildi ama daha da özellikler istiyorlar.

İşte yeni istekleri(gereksinimler) : e-posta istemcisinin çalışmalarının hangi devrede olduğunu ekrana basan kısım hep siyah ekran (console demek istiyor)  ben renkli ekranda görmek istiyorum. Yanlız siyah ekran kullanan arkadaşlarda rahatsız edilmesin.

Yapılması gereken : Bu eposta istemcisinin çalışmalarının hangi devrede olduğunu ekrana basan kısım isteğe göre siyah ekrana (console) veya renkli ekrana basabilmeli (grafik arayüzlü GUI - swing). Buyrun buradan yakın J

Arayüz (Interface) bu tür soruların cevabı olabilir.

Yukarıdaki gördünüz arayüzü bir sözleşme / belirtim olarak düşünün. Bune erişen sınıflar bu sözleşmeye / belirtimlere uymak sorundadırlar. İşte ilk erişen sınıfımız.

StandartOutReporter sınıfı anlaşılacağı üzere verileri siyah ekrana yani console basacaktır. Burada dikkat edilmesi gereken kısım StandartOutReporter sınıfı Reporter arayüzüne erişerek bir sorumluluk altına girmiştir. StandartOutReporter sınıfını yazan uygulama geliştirici artık yordam isimlerini kafasına göre değiştiremez. Şimdi diğer sınıfımıza geçelim.

JtextComponentReporter sınıfı anlaşılacağı üzere kendisine gelen verileri Swing bileşeni sayesinde renkli bir şekilde ekrana basmaktadır. Teknik detaylara sakın boğulmayın. Swing nasıl ekrana basar, nasıl olur gibi soruların şimdi zamanı değil.

Büyük resim

Yukarıdaki büyük resimdeki en can alıcı nokta Folder, Session sınıflarının direk olarak somut olan StandartOutReporter ve/veya JtextComponentReporter sınıflarına bağlı olmayıp Reporter arayüzüne bağlı olmalarıdır. Bu sayede kullanıcı çalışma anında eposta istemcisinin hereketlerini istediği ortamda bastırabilir. Daha da detaylara geçmeden önce Folder sınıfının kodlarını inceleyelim.

Folder.java

Folder sınıfının içerisinde StandartOutReporter ve/veya JtextComponentReporter sınıflarına ait en ufak bir iz bulabiliyormusunuz  ? Cevabınız hayır ise olay tamamlanmıştır. Folder sınıfı sözlemeye hedef almıştır (Report arayüzü). Bu sayede üreteceği bilgilerin nereye basılacağı pek umrunda değildir. Olaylara birde şu acıdan bakın Report arayüzü tipindeki bir değişkene kaç tip sınıf bağlanabilir ? Cevap  : 2 (StandartOutReporter veya JtextComponentReporter).

Dikkat bu Folder sınıfı geröekten gidip eposta sunucu üzerinden epostalar alip okumuyor, sadece temsili bir çalışma sergiliyor.

Bu örneğimizin anlaşılması için çalışma noktasının gösterilmesi gerekmektedir. Yani kullanıcılar bu eposta istemcisini nasıl başlatacaklar ? Sorunun cavabı Main.java içerisinde.

Main.java

Akıllara durgunluk verecek olan bu uygulamanın kilit noktalarında birisi aşağıda kodunu gördüğünüz Main.java sınıfıdır.

Kullanıcı bu uygulamayı çalıştırken uygulama dışarıdan 1 ve ya 2 yazıp; uygulamanın çalışmasını etkileyebilir. Eğer kullanıcı bu uygumalayı aşağıdaki gibi çalıştırsa   :

Sonuç aşağıdaki gibi olacaktır :

Eğer kullanıcı uygulamayı aşağıdaki gibi çalıştırırsa :

Bu sefer sonuç aşağıdaki gibi olacaktır :

Özet

Arayüzler (Interface) tasarım kalıpları (design patterns) konusunun kalbinde yer alırlar.  Uygulamalarınızın esnek ve güçlü olabilmesi için her türlü ihtimali göz önüne alarak kodlamanız gerekmektedir. Bu noktada tasarım kalıpları çok önemli olan tecrübeleri size aktarırlar. Bağlaşımı kesme tasarım kalıbı konusunun başlıca prensiplerinden bir tanesidir.  Bu makale tasarım kalıplarına basit bir giriş anlamında okuyuculara faydaları olacaktır.

Kaynaklar

1 - Head First Design Patterns. - First Edition October 2004 - O'REILLY
2 - Java ve Yazılım Tasarımı - Altuğ Bilgin ALTINTAŞ - 2005 - Papatya Yayınevi
3 - http :// courses.csail.mit.edu/6.170/old-www/2001-Fall/lectures/lecture-03.pdf

Kod

İndir

Altuğ Bilgin ALTINTAŞ-2007
altuga at kodcu.com