Sen “Loosely Coupled” iken Yazılımın Neden Olmasın?
Eğitmenlik/danışmanlık zamanlarımda edindiğim en büyük tecrübe, ihtiyaç sahibi olmaksızın edinimlerin teori bulutlarından pratik topraklarına inemeyeceği gerçeğiydi.
O zamanlardan bugünlere gelirken de bu fikrimde hiç bir gerileme olmadı, hatta gelişip olgunlaşmaya tüm hızıyla devam ediyor. Kasım’16 tarihinde yazdığım Yaşayan Bir Organizma:Yazılım başlıklı yazımda da aslında bu fikrin izleri yer yer kendini gösteriyor.
Yazılım denilen olgu, aslında insanın ta kendisi.
Bir fikir olarak doğuyor. Zaman içerisinde ihtiyaçları ortaya çıkıyor. Bu ihtiyaçlar için bir takım dış nesneler yazılımın kendisine entegre oluyor. Sonrasında zaman geçiyor, bu ihtiyaçlar gerçekliği karşıla(ya)mıyor ve ihtiyaçlar yerini yenilerine bırakıyor.
İnsanın gelişme sürecinin tanımı değil mi aslında bu? Doğuyoruz, beslenme gibi bir temel ihtiyaç bizimle birlikte ortaya çıkıyor. Küçük küçük parçalarla beslenen bedenimiz büyürken, bir süre sonra bunlar yetersiz kalıyor ve besin değeri daha yüksek gıdalara yerini bırakıyor. Bir başka örnek, küçük halkaları birbirine geçirerek eğlenebiliyorken, bu gerçeklik eğlence ihtiyacımızı artık karşılamaz hale geldiğinde yerini daha büyük, interaktif nesnelere bırakıyor.
Bu ihtiyaçlar doğrultusunda keşfettiğimiz gerçeklikleri yer değiştirebilmek için ekstra bir efor sarf etmiyoruz. Öyle mükemmel kodlanmış bir yazılımız ki, T anında bedenimizdeki/ruhumuzdaki X bir noktayı zorla — insan müdahalesine gerek kalmadan belki de — değiştirmek zorunda olmadan, yumuşak bir geçişle bunun üstesinden gelebiliyoruz!
O halde insan “Loosely Coupled” bir varlıktır…
Yukarıdaki tanımı yapmanın çok da yanlış olmadığını düşünüyorum. Çok net değil mi sizce de: Bağlılıklarımız gevşek.
İhtiyaçlarımız soyut kavramlarla tanımlı. “Besin”. Anne sütü de bir besin, 1.5 porsiyon Urfa Kebap’da. Her ikisi de ihtiyaçlarımızı — bulunduğumuz şartlar içerisinde — karşılayabiliyor. Yazılım metodolojisi ile aktarmak istersem;
Insan denilen class, construction aşamasında IBesin adı verilen interface’e ihtiyaç duyuyor. Bu interface “TemelBesinOgeleriniSagla()” adlı bir fonksiyonaliteye sahip ve bu interface’in implement edildiği herhangi bir class, bu fonksiyonu sahip olduğu özelliklerle zenginleştiriyor. En nihayetinde Insan, bu fonksiyonu çağırıp ihtiyaçlarını karşılayabiliyor.
…Peki insan tarafından geliştirilen yazılım neden “Loosely Coupled” olmasın?
Doğalımız bu kavram üzerine kuruluyken, kendi ürettiğimiz yazılımlarda neden bu kavramı es geçelim ki?
Bir uygulama geliştiriyoruz, bugün MSSQL kullanıyor, belki yarın PostgreSQL kullanacağız?
Uygulamamız bugün loglarını veritabanına yazıyor, belki yarın Queue’ya yazmamız gerekecek, kim bilir?
O halde uygulamamızı MSSQL ve log veritabanına sıkı sıkıya bağlı olarak geliştirmemiz ne kadar doğru olacaktır? Düşünsenize DNA’nızda eğlenmek için kodlanmış tek özellik tahta oyuncaklar. 35 yaşındasınız ve PlayStation ile eğlenemiyorsunuz çünkü sıkı sıkıya oluşturulmuş bağımlılığınızı çeviremiyorsunuz. Çevirmeye çalıştığınızda ise karşınıza çıkan sorun şu: Beslenmek için kullandığınız tekniklerinizi de değiştirmek zorundasınız. Ben düşünürken ürkmedim desem yalan olur.
Basit bir örnekle konuyu toparlayalım
Bu aralar e-kitap olayına feci sarmış durumdayım. Hangi cihazı almalıyım, hangi formatlar o cihazda destekleniyor, bir formattan diğerine çeviri nasıl yapılır? (Konudan bağımsız, bu konuda tecrübeli dostların yardımına muhtacım :)
Ancak ben doğduğumda e-kitap diye bir şey yoktu. Basılı yayınlar, karşılaştığımız ilk kitaplar. Dolayısıyla “Okuma” soyut kavramını karşılayan sınıf benim için “PrintedBook”
Ben de bir kitap kurduyum elbette:
Ben üretiliyorken bir “PrintedBook” kopyasına ihtiyacım var. Her ortamda da basılı kitabın mottosunu haykırmaya bayılıyorum!
Sonrasında e-kitap denilen kavram ortaya çıkıyor:
E-kitap olayı da benim çok hoşuma gidiyor ve fikrimi bu yönde değiştiriyorum. Bu durumda gidip construction aşamasında (BookWorm.cs:5–8) bağımlılığımı değiştirmem gerekiyor. E peki yeni bir kitap türü çıksa, ben her defasında gidip temel kodlamamı mı değiştireceğim? Üstelik benim eylemim, keyif aldığım şeyin mottosunu haykırmak. E her ikisinin de “Motto” denilen özelliği var. Sadece söylediğim sözü değiştirmek için bu kadar temel bir değişiklik çok sağlıklı durmuyor.
O halde şöyle desem doğru olacaktır: Benim üretimim aşamasında ihtiyacım olan şey “Motto” özelliğine sahip bir kitap türü (nesnenin kendisi değil, özelliği).
Bu sahip olmaya söz vermiş herhangi bir nesne benim üretimim esnasında kullanılabilir:
4. ve 5. satırlara dikkat ederseniz artık nesnenin kendisine değil, sözleşmesine ihtiyaç duyuyorum. Böylece bu sözleşmeye imza atmış herhangi bir nesne benim “Motto” denilen özelliğe erişmeme olanak sağlayacaktır. Ana programı çalıştırırken, istediğim bir nesneyi (IBook interface’ini örnek almış) parametre olarak kullanabiliyorum:
NOT: IBook interface’i EBook ve PrintedBook sınıflarına implement edilmelidir!
Sonuç
“Loosely Coupled” kavramının sözlük anlamına yazı boyunca özellikle değinmedim. Aslında yazının amacı da tam da bu. Herhangi bir sözlük anlamına ihtiyaç duymaksızın, bir kavramı temelden anlamak. Tabii ki sözlük anlamları ve teorik açıklamalar çok önemli. Ama başta da söylediğim gibi: Önce ihtiyaç.
Gerçek yazılım senaryoları ile ilgili internet ortamında onlarca makale ve kod örneği (İngilizce/Türkçe) bulabilirsiniz, hepsi de birbirinden değerli. Ayrıca geliştirdiğiniz uygulamalarda Dependency Injection, IOC gibi kavramlarla karşılaştıysanız ya da herhangi bir yerde duyduysanız aslında bu yazının tamamına günlük hayatınızın bir noktasında denk gelmişsiniz demektir.
Bu satırlara kadar zaman ayırdığınız için teşekkür ediyorum. Bir sonraki yazıda görüşene dek, hayattaki tüm bağımlılıklarınız her an değiştirilebilir olsun (sosyal mesaj da içerdi bu sanırım :)
