Namı değer Solid Principles yani Solid prensipleri konusuna değinmenin vakti geldi. Çünki o kadar büyümüşki anayasal düzen haline gelmiş. Neyse direkt çullanmadan bazı bilgiler vermekte fayda var. Bazı bloglarda ballandıra ballandıra anlatmışlar. Halbuki senelerdir biz iyi yazılımcıların uyguladığı prensipler, adını başka bişi koymuş bu amca millet tapıyor.
2000 Yıllarında Robert Cecil Martin adındaki çok değerli amcamız kod karmaşıklığına, tekrar eden kodlara ve bir yazılımın kişiden bağımsız ilerlemesine yönelik bir takım çalışmalara imza atıyor. Bu çalışmalardan nesne yönelimli programlama için 5 temel prensip ortaya çıkıyor.
Bu prensipler Solid in her bir harfine tekabül ediyor;
İlkokulda şiir yazar baş harflerini sevdiğimiz kızın ismini denk getirmeye çalışırdık ya hah o işte, amcamız çocukluğunu yaşıyamamış belliki, ölmüş adamın arkasından laf söyledik ama neyse…
Bazı bloglarda parantez içine almışlar baş harfleri görmeyen olur diye nerden copy paste’se artık
- Single Responsibility
- Open/Close
- Liskov’s Substitution
- Interface Segregation
- Dependency Inversion
Bak noldu baş harflerini birleştirince solid çıkıyormuş, mülakatta soruyorlar bunu unutmayın, ayrı ayrı açıklayacam size hepsini. Bilemezseniz bilgin yetersiz derler aman deyim, benim gibi sabırlı biri değilseniz kafa göz girersiniz.
Genel dikkat edin diğer bloglardaki allayıp pullayıp kafanızı karıştırmayacam, yok efenim şöyleymiş böylemiş…
Single Responsibility (Tek Sorumluluk)
Yazdığınız her bir Class’ın yani türkçesiyle sınıfın tek bir işlevi amacı olacak, tek bir işi yapacak.
Yani mail göndermek istiyorsun, onun için bir class oluştur ve o sadece o işi yapsın, içine LogYaz() diye bir fonksiyon daha ekleme diyor.
Tanıdık geldimi ? Genelde belirli bir süre yazılımla uğraşıp saha görmüş yazılımcılar zaten her iş için bir sınıf oluştururki karışmasın mevzu diye, bizim Robert amca bunu bilmezler diye tescillemiş.
Muhittin: Abi bu mail class’ın boyutu büyüdü çok hata veriyor, belleği şişiriyor
Ethem: Lan olum Mail class’ından cari hesap loglarını veritabanına yazıyorsun, aç ayrı bir class onları al taşı oraya
Muhittin: Tamam niye bağıryon abi
Open / Close (Açık / Kapalı)
Yazdığın class yada yazılımda bulunan varlıkların geliştirmeye açık, değiştirmeye kapalı olmasıdır.
Yani bir class yazdınız mail almak için, bu class içinde Pop3 ve IMAP desteği koyacaksınız, gidip kodun içine if koyup eğer gelen parametre pop3 ise şunları yap, eğer imap ise şunları yap demeyin diyor, üçüncü bir yöntem çıkarsa POP3 veya IMAP dışında kodun içine girip bir if daha yazmayın. Abstract veya Interface kullanarak bir ana mail alma classınız olsun, mesela alma yöntemleri içinde bir interface oluşturun, sonra bu interface’den pop3 ve imap class larını türetin ve ana clasınızla kullanın, plaza diliyle implemente edin.
Diyelimki başka bir yöntem daha çıktı, XML mail getting diye, diğer kodlara veya ana koda ellemeden sağa sola if yazmadan alma yöntemleri interface’ini baz alarak yazacağınız yeni bir classla işi çözebilirsiniz.
Liskov’s Substitution (Liskov’un Değişikliği)
Burda bir bilgi eklememde fayda var, Liskov bir teyzemizin soyismi. Barbara Liskov bağlantısından inceleyebilirsiniz. Martinle bir çay içmişliği varki solide dahil olmuş.
Alt sınıflardan oluşan nesnelerin üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermelidir.
Yani; türetilen sınıflar, türeyen sınıfların tüm özelliklerini kullanmak zorundadır. Aslında Open/Close (Açık Kapalı) prensibine dayanır. Classlar yer değiştirdiğinde hata almamanız gerekir. Atıyorum ogrenci diye ana class tanımladınız, bu classtan stajgoren veya stajgormeyen diye iki ayrı class türettiniz, staj gören öğrencide stajbilgigetir() fonksiyonu var diğerinde yok, classlar yer değiştirdiğinde stajbilgigetir çağırılırsa hata almaman gerekiyor. Üst class’ında alt class’ında aynı özellikleri taşıması gerekiyor, yoksa Barbara teyzeyi üzersin.
Interface Segregation (Arayüz Ayrımı)
Nesneler yani bizim classlarımız, ihtiyaç duymadıkları metodların bulundukları interfacelere bağlı olmaya zorlanmamalıdır.
Yani demeden interface i bilmeyenler için basit bir anlatayım, birden fazla class oluşturacaz ve bu oluşturacağımız classlardaki fonksiyonlar aynı olsun istiyoruz ki eğer oluşturulmazsa hata dönsün, mutlaka oluşturmak zorunda kalalım. Şimdi bir tablet class’ımız var bu class için bir interface oluşturduk, içindede WifiBaglan(), 3gBaglan() methodlarını tanımladık. Yani her tablet class ını oluştururken hem wifi hemde 3g için fonksiyon yazmamız lazım yazmazsak patlar. Amcada diyorki tablette 3g olmayabilir, o nedenle Interface class ını ikiye ayır wifi ve 3g olarak, tablette ne lazımsa onu implemente et, gereksiz yere 3g olmayan tablet için 3g fonksiyonu oluşturulmasın diyor.
Dependency Inversion (Bağımlılık Değişimi)
Yüksek seviye modüller, düşük seviye modüllere bağlı olmamalı. Her ikisi de soyut (abstract) kavramlara bağlı olmalı. Soyut kavramlar detaylara bağlı olmamalı. Detaylar soyut kavramlara bağlı olmalı.
Yani oku diye bir class oluşturduğunuz diyelim, oluşturduğunuz class ın altında romanoku ve hikayeoku diye alt classlar var, bunları oku klasından çıkartıp standart bir interface’e implemente ettiğinizde olayı ters çevirmiş oluyorsunuz. Oku class’ına standart interface den oluşturulan okuma classlarından hangisini gönderirsen gönder çalışmış olacak bağımlılığı kaldırmış olacaksın, illa hikaye veya roman okumak zorunda kalmayacak yerine Tommiks okuyadabilir.
Sonuç olarak şunu söylemeden edemeyeceğim, bu tarz prensipler koca koca projelerin çok değerli CTO larının kendi başlarına prensip oluşturma yeteneklerinin ve güdülerinin olmamasından ve yazılımcıları yönlendirememesinden kaynaklı çıkmış prensiplerdir. Yararı varmıdır elbette vardır adamlar 2000 yılında kafa patlatmış işte, ama korkulacak bir durum yoktur, bu prensipleri mulakatlarda sormanında bir anlamı yoktur. Bunun yerine şunu nasıl yaparsın diye sorsan prensipleri karıştırmadan adam zaten sana güzel bir çatı oluşturur. Gerektiğinde solid’den de alıntı yap, dökümanını hazırla, çözümünü üret senden sonraki yazılımcıda mutlu olur.
Ayrıca yazılım özgürlüktür, sürekli değişkenlik gösterir, belli prensiplere çakılı kalmak gelişmeyi ve yeni teknolojik altyapıların çıkmasına engel olacak yazılımcıları söyleneni yazan köle işçilere dönüştürerek gerçek üretkenliğin ve hayalgücünün önüne geçecektir.
Bunuda demezsem çatlarım, başta bende oturup bir prensip yazacam demiştim ama solid yazmışlarda nolmuş, millet bişi sanıyor, zamanında Yer çekimi prensiplerini yazmışlar sayesinde anca uçaklar uçuyor, bize bir prensip yazan olmamış biz yerden 50 cm gene yükselemiyoruz, rahat bıraksalar çoktan göğe yükselmiştik, yükselen yükseliyor…
Bu yazı 4113 kez görüntülendi.