4 - INTERFACE SEGREGATION PRINCIPLE

   Herkese merhaba, bir önceki yazımda Liskov's Subtitution Principle ' den bahsetmiştim. Bugün de SOLID prensiplerinden I 'ya denk gelen Interface Segregation Principle yani Arayüz Ayırım Prensibini anlatıcam. Bu prensip diğer prensiplere göre hem daha basit, hem de anlaşılması daha kolay bir prensiptir. Aslında bir önceki Liskov prensibinde kısmen de olsa anlatmıştım, çok basit manada adından da anlaşılacağı gibi özel görevler yapan classlar için interfacelerin ayrılması konusudur. 

    Interface yani Türkçe adıyla arayüzler, sizin de bildiğiniz gibi bir nevi yapılacak işlerin belirlendiği sınıflar arası anlaşma, sözleşmedir. Aslında sınıflara "REHBERLİK" etmek görevindedir, sadece yol göstermek yapılması gereken zorunlu işleri belirtmek görevi içerir. Haliyle interfaceleri miras alan sınıflar, içindeki tüm methodları implemente etmek zorundadır. Interfacelerin yapı ve görevleri bu yazının konusu değil ama kısaca bahsetmiş olduk. Şimdi konumuzla olan kısmına gelirsek, konu zaten çok basit olduğundan hiç dallanıp budaklandırmadan örneğe geçiyorum. 

    ISP kuralı derki; eğer bir sınıf için kalıtım alınan Interface YETERSİZ yada FAZLA geliyorsa o sınıfı dağıtmak yerine interface yapılarını amaca uygun ayırın. Bu tanıma göre ISP bize farklı işler yapan classlar için farklı interface yapıları kurgulamamızı tavsiye eder. Aslında bu Liskov prensibi ile doğrudan bağlantılı bir prensiptir ki zaten daha önce de belirttiğim üzere SOLID prensipleri bir bütünün parçası gibidir, birbirinden ayrılmazlar ve birine ters gelen kurgu otomatik olarak diğerine de terstir. Şimdi lafı uzatmadan hemen örneğimize geçelim. Bu arada bir önceki yazımda hemen tüm örnekler ISP uyumludur, ISP'ye birer örnektir :)

Örnek - 1 :

 Kuş familyasına ait bir tasarım çıkaralım ve aşağıdaki gibi bir tasarımın yanlış olduğunu görelim.

     Yukarıdaki tasarıma bakarsanız "IKus" interface yapısının bazı classlar için FAZLA geldiği bazıları için YETERSİZ kaldığını görebilirsiniz. Örneğin deve kuşunun göç etme ve uçma gibi 2 özelliği yoktur, aynı şekilde eğer papağan sınıfımız olsaydı "Konuşma" özelliği "IKus" interface yapısında tanımlı olmadığından bu özelliği kullanamayacaktık. Yukarıdaki kod bun sebeplerden dolayı öncelikle Liskov'a uymamaktadır, sonrasında ise ISP'ye zaten uymadığı aşikar. Şimdi kodumuzu SOLID prensiplerine göre baştan düzenlersek, aşağıdaki gibi ayrı interfaceler olacaktır.

    Bu şekilde bir tasarım SOLID prensiplerinin tamamına uymaktadır. İnterfaceleri ayırmış bulunmakla birlikte artık gereksiz özelliklerin gereksiz sınıflarda boş yere implement edilmesini önlemiş olduk. Üstelik "Göç edebilen kuş aynı zamanda uçabilen kuştur" mantığında interfaceleri birbirinden miras alarak bir nevi code review yaptık ve kodumuzu daha manalı ve kısa bir hale de getirmiş bulunduk.

   ISP'nin bize üstteki örnekten de anlaşılacağı üzere, "Nesneler, Sınıflar ihtiyaç duymadıkları özelliklerin olduğu Interface'lere bağlı kalmak zorunda bırakılmamalıdır" der. Yani bizim sınıfımız oluşturmuş olduğumuz Interface yapısının 1 özelliğini dahi kullanmıyorsa, hem Liskov hem de ISP' ye göre yanlış yoldayız demektir.

Örnek - 2 :

  Şimdiki örneğimizde de bir e-ticaret sitesini düşünelim. Sitemizde doğal olarak kullanıcılarımız olacak ve bu kullanıcıların rol görev ve yetkileri doğal olarak birbirinden farklı olması gerekiyor. Örneğin bir "Admin" grubumuz olsun ve bu gruba ait üyelerin "Ekleme,Silme,Düzeltme"  gibi işlevleri, "Base" grubumuzun da sadece "Ekleme" işlevi olsun. Oluşturulacak kullanıcıların bu gruplara atanması ve rol görev dağılımlarını gösteren tasarımı direk oluşturacak olursak aşağıdaki gibi olacaktır.(burada hatalı tasarımı vermeye gerek görmedim)

  Görüldüğü üzere A müşterisi "Admin" grubunda yer aldığından tüm özellikleri kapsıyor, B Müşterisi ise sadece ekleme işlevini yerine getirebiliyor.

   Böylelikle SOLID'in I'sına denk gelen Arayüz Ayrımı Prensibinin de sonuna gelmiş bulunuyoruz. Bu prensip Liskov prensibi ile iç içe geçen basit ama çok islevsel bir prensiptir. Konu gayet zevkli ve basit olduğundan çok rahat bir şekilde anlaşıldığını düşünüyorum. Bir sonraki yazım olan SOLID'in D'sine denk gelen DIP prensibinde görüşmek üzere..Saygılarla..

2 - OPEN/CLOSED PRINCIPLE (OCP) (Açık Kapalı Prensibi)

  Merhaba daha önceki yazımda SOLID prensiplerinden Single Responsibility Principle konusunu anlatmıştım,bu yazımda da SOLID kısaltmasındaki O 'ya denk gelen Open/Closed Principle - Açık Kapalılık Prensibine değiniyor olacağım. Konuya uzatmadan giriş yapmak gerekirse OCP bize;

"Yazılım varlıkları (Class,Modül, Fonksiyon, Method vb.) gelişime AÇIK, değişime KAPALI olamalıdır!"

diyor. Bu cümlenin orijinal hali ise Bertrand Meyer' in aşağıdaki ifadesidir.

 "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"

   Peki yazılım varlıklarının gelişime açık, değişime kapalı olması ne manaya geliyor? Bunu şu şekilde düşünebiliriz, ana görevi yüklenen class,modül,fonksiyon gibi yapıların zaman içerisinde kodsal olarak değiştirilmemesi, fakat yani eklenecek özelliklere de açık halde kalması gerektiğidir. "Hem yeni özellik ekleyip, hem de var olan yapıyı değiştirmeden bu işi nasıl yapabilirim? Sonuçta bir yerlere kod eklemek zorundayım ve yapıda mutlaka kodsal değişiklik yapmam gerekecek!" dediğinizi duyuyorum :) Anlaması da kurgulaması kadar zor bir yapıya daha hoş geldiniz diyorum. 

   OCP 'yi daha iyi anlatmak için, prensibin çıkış amacından bahsetmek gerekiyor galiba. Bu prensip kurgulanan yazılımın "Sürekli Değişime Maruz Kalacağı" düşünülerek ortaya çıkmıştır, nitekim de öyledir. Hiç bir projenin başlangıç aşamasından sonunda kadar olacak süreç belli değildir, hatta öyle projeler olur ki %50-60 oranında değişiklik dahi yapılır. Bunun bir çok sebebi vardır ve bu sebeplere burada girmek istemiyorum aksi halde yazı bitmez :) Bu kadar çok değişikliğin yapıldığı projelerde kodlar sürekli sil baştan yazılmak zorunda kalınmasın diye, varlıkların gelişime açık değişime kapalı olması gerekliliği ortaya çıkmıştır. Unutmayın ki her projede gelişim devamlı olacak, sürekli yeni istekler yeni geliştirmeler olacaktır. Tasarımları yaparken ilerde oluşabilecek yeni özellikleri de düşünerek yapmamız gerekecektir ki doğal olarak gelişime açık olsun.

Örnek - 1 :

 Şimdi e-ticaret yapan bir firmanın fatura hesaplama evresini düşünelim ve fatura dip toplam tutarının hesaplandığı tasarımı çıkaralım.

Futuraya ait toplam tutarın hesaplanmasında problem gözükmüyor. Şimdi bir de sipariş tutarının hesaplandığı ve sipariş tutarında iskonto hesabının yansımadığını düşünelim. 

   Görüldüğü üzere ana işlevi yerine getiren "TutarHesapla()" fonksiyonunu değiştirmek zorunda kaldık.Hatta ilerde farklı belge tipleri (İrsaliye, Fiş vs) geldikçe de sürekli değiştirmek zorunda kalacağımız bir yapı oldu. Bu tarz bir program bağımlılıklardan dolayı hatalıdır, eklemek istediğimiz her belge tipinde ana fonksiyonu sürekli değiştirmek zorunda kalacağımız aşikar ve bu durumda hem ileride düşeceğimiz sıkıntılar hem de çıkabilecek binbir türlü hata gözünüzün önünde canlanmıştır.

   Şimdi gelelim yapımızı OCP' ye uygun hale getirmeye.Öncelikle ana işlevi yerine getiren metodu değişime kapalı hale getirip, programı da gelişime yeni modüllerin eklenmesine açık hale getirmem gerekiyor. Ayrıca enum tipli yapıdan da sıyrılmam gerekiyor. Peki bunu nasıl yaparım derseniz, işte tam da bu noktada abstract class 'lar devreye giriyor.

     Son yapılan refactoring ile şimdi programın gelişime açık, değişime kapalı olması prensibini gerçeklemiş oldum.Artık tek yapmam gereken "Belge" sınıfından türeyen yeni bir sınıf inşa etmek olacak (gelişime açık), ayrıca "TutarHesapla()" fonksiyonunda artık hiç bir değişiklik yapmak zorunda kalmıyorum (değişime kapalı). Tüm bunlara artı olarak bir önceki yazıda anlatmış olduğum SRP 'ye de uygun olduğunu görebilirsiniz, her sınıfın kendine ait 1 işlevi ve her metodunda 1 görevi vardır. Aslında üstteki yapı Liskov Prensibine de uyuyor, fakat bir sonra ki yazımda o noktaya değineceğim için şuan girmiyorum.

Örnek - 2 :

Bir önceki örnek OCP uygulamanın en basit tekniğinden (abstract class) birisiydi. Şimdi ise biraz daha farklı olarak Interface yapısı ile programı OCP 'ye uygun hale getiririz ona bakalım.Öncelikle hatalı yapıyı kurgularsak, aşağıdaki gibi olacaktır.

Intarface kullanılmasına rağmen "TutarHesapla()" metodunda hem gereksiz yere hemde OCP'ye uymayan tarzda kodlar yazılmıştır. Bu kısım eklenen her belgede yine değiştirilmek zorunda kalacaktır. Şimdi burayı değişime kapalı hale getirip, daha genel bir yapıya aşağıdaki gibi çevirebiliriz. Dip not olarak aslında alttaki örneğin de SRP ve Liskova uyduğunu unutmayınız.

     SOLID' in  O'su olan OCP'nin olayı aslında temel olarak bu kadar. Yazılımda kodlarla oynanmadan zaten bir geliştirme olamaz, fakat amacımız temel işlevi üzerinde barındıran kodlarda değişiklik yapmadan, belli kısımlarda ekleme yaparak mümkün mertebe çok az kod yazacak şekilde istenen geliştirmeyi tamamlayabilmektir. Böylelikle bu ilkenin temel amacının minimum kod yazma olduğunu belirtebiliriz.

Bir sonraki yazım olacak olan SOLID 'in L'si Liskov Subtutition Principle 'de görüşmek üzere.

TASARIM PRENSİPLERİ (Design Principles - SOLID)

       Herkese merhaba, bugün ki ve bundan sonraki muhtemel 4 - 5 yazımda aslında yazmayı iple çektiğim ve gerek yazarken gerekse de uygularken çok zevk aldığım "Design Principles" konusuna değiniyor olacağım. Konuyu daha önce bilen, duyan herkesin "hah şimdi esas konuya geldi" dediğini duyar gibiyim. Bu yazının bugüne kadar ki olan diğer yazılarımdan en büyük farkı, daha çok mimariye/tasarıma giriyor olmasıdır. Tasarım Prensipleri altında anlatacağım konular projelerimizin mimari yapısı ile ilgili olacaktır.

         Tasarım Prensipleri fikrinin ortaya çıkış temeli "Daha İyisini Nasıl Yaparım?" düşüncesidir. Benzer şekilde bu soruyla ilişkili olarak "Daha Hızlı, Daha Kolay Bir Şekilde Nasıl Yaparım?" düşüncesi ve "En İyisini Nasıl Tasarlarım?" sorusunun karşılığı olarak ortaya çıkan kalıplardır. Hayatta her şeyin daha iyisinin zaman içerisinde gelişim sürecine bağlı olarak yapılabileceğini varsayarsak, benzer şekilde yazılan projelerin,programların da daha iyisi olabileceğini sakın unutmayın. İşte tam bu noktada "Nasıl?" sorusunu sorduğumuz her durumda dönüp "Design Principles" konularına bakabilirsiniz, bu sizin için bir anahtar niteliği taşımaktadır.

      Object Oriented Programming (OOP) ile uğraşan herkesin günümüz mimari kuralları çerçevesinde mutlaka bilmesi gereken Tasarım Prensipleri, dünyada hemen herkes tarafından kabul görmüş SOLID kısaltması ile belirtebileceğimiz 5 ana prensipten oluşmaktadır. Bu prensipler sırasıyla aşağıdaki gibidir.

1 - Single Responsibility Principle         (Tekil Somluluk Prensibi)

2 - Open/Closed Principle                      (Açık / Kapalılık Prensibi)

3 - Liskov's Subtitution Principle           (Liskovun Yer Değiştirebilme Prensibi)

4 - Interface Segregation Principle         (Interface Ayırım Prensibi)

5 - Dependency Inversion Principle       (Bağımlılığı Ters Çevirme Prensibi)

       Yukarıda saydığım prensiplerin baş harflerinden oluşan SOLID, sağlıklı mimariler oluşturup sağlam tasarımlar yapmamıza olanak sağlayan prensipler bütünüdür diyebiliriz. Bu prensipleri bilmek ve uygulamak kullandığımız programlama dillerinin (C#, Java,C++ vs) gücünün de farkına varmamızı sağlayacaktır. Şunu belirtmek isterim ki prensipleri ilk başlarda uygulamak hatta anlamak dahi zor olabilir, fakat zaman içinde pratik kazandıkça "Vaay bee böyle bir şey de mi varmış?Ben bugüne kadar ne hamallık yapmışım." diyeceksiniz, buna eminim.

       Bugüne kadar ki tecrübelerimden yola çıkarak şunu gönül rahatlığı ile söyleyebilirim ki, bu prensipleri uygulamak bazen hayat kurtarır. Özellikle çok fazla yazılımcı ile büyük bir firmada büyük projelerde çalışıyorsanız. Mesela 20 küsür yazılımcı arkadaşla aynı proje üzerinde ortak çalıştığım da oldu, tabi burada herkesin aynı bilgi beceri ve kabiliyette olmadığı aşikar. Bu tip durumda herkese belirli standartlarda kod yazdırabilmenin de tek yolu OOP-Design Principles' ten geçer. Biraz daha açmak gerekirse, hem web tabanlı uygulamaların hem android hem de ios cihazların ortak eriştiği yapıların olduğu ayrı ayrı projeler düşünün, birisinde yapılan hatalı bir kod değişikliği domino etkisi yaparak kalan projelerde yıkıma sebep olabiliyor. Bu tip durumlarda yazılan kod ya geri alınmak zorunda kalıyor, ya da sürekli hatalı yapılan işin üstüne hatalı yamalar yapılarak iş iyice içinden çıkılmaz hale gelebiliyor (olmaz demeyin kaç defa başıma geldi, oluyor). Bu sorunlar neticesinde iş dönüp dolaşıp, 5 ana prensibe uymayan hatalı mimari tasarıma dayanıyor.

       Hangi proje üzerinde çalışıyorsanız çalışın, şayet mimari tasarımı sıfırdan kurma gibi bir şansınız varsa bu tip sorunlarla karşılaşmamak adına bu 5 prensipten vazgeçmemek sizi daha sonra doğması muhtemel büyük sorunlardan koruyacaktır. Aksi halde belirli oranda oturmuş mimari yapıyı da oturup sıfırdan yazamayacağınız için, sürekli hatalı ve yeni hatalara gebe yamalar yapmak zorunda kalacaksınız ki iş iyice arap saçına dönecek. Zaman içinde projede çalışan her arkadaşın "Yeter be bıktım bu hatalardan" deyip bir bir yanınızdan istifa edip gittiğine şahit olacaksınız. Yanlış tasarlanmış sistemin içinde boğuşmak sürekli kendini tekrarlayan hataların doğmasına sebep olacaktır. Şurasını unutmayın ki bu hatalar da sizi sürekli mesaiye bırakıp, kendinize ve sevdiklerinize ayırabileceğiniz zamanı çalacak en önemlisi yaptığınız işten zevk almak yerine ızdırap çekmenize sebep olacaktır.

      Anlattıklarımı en başından beri toparlarsanız yapılan mimari hataların domino etkisini kendi hayatınızda dahi hissedeceksiniz. "Abartıyorsun" diyenleriniz vardır belki, ama inanın en ufak abartı olmadan hatta eksiği var fazlası yok diyebileceğim şekilde bizzat yaşadıklarımdan alıntı yaparak yazdım. Sonuç olarak "Sağlam, Esnek, Daha az kodla daha çok iş ve Dinamik" olarak nasıl program yazarım tasasında iseniz şayet, bu prensiplere mutlaka riayet etmenizi öneririm. Evet, bunlara uymadan kod yazılabilir mi? derseniz..Yazılır..Ama kendinizden ve ailenizden çalarak yazılır, üstelik yaptığınızdan işten zevk almadan ve her an yeni hatalar çıkacakmış tedirginliği ile yazılır..

      Bu yazım biraz daha sohbet tadında, birikmiş tecrübelerden bahsederek geçti. Önümüzde ki yazılarda bu prensipleri teker teker irdeleyip, bol örnek yapıyor olacağız. Bu konular zor evet ama bence çok zevkli, sonraki yazılarda görüşmek dileğiyle..