Joe Armstrong isimli Erlang dilinin geliştiricilerinden bir abimiz, vakti zamanında nesne yönelimli programlama modeli için bir örneklemede bulunmuş, ve demiş ki;
“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”
Basitçe çevirirsek, “nesne yönelimli programlama dillerinin sorunu; tüm örtük çevreyi beraberlerinde taşımalarıdır. Bir muz istersiniz ancak elde ettiğiniz; bir goril, elinde muz ve tüm ormandır”. Bu sözün esprili bir şekilde anlattığı olgu; OOP modelinin bilindik kurallarına ve bu modele bağlı önemli programlama kalıplarına (mesela benim için en önemlisi Open-closed Principle ) bağlı kalır, kısaca işi kuralına göre yapmaya kalkarsanız sözün belirttiği abartıda bir kodlama ile karşı karşıya kalırsınız. Bir kaç gün önce başıma gelen bir örnek ile açıklamaya çalışayım;
Benden istenen bir öğle arasını bu uğurda harcamam karşılığında, verilecek veritabanındaki kişilere verilecek olan metni eposta olarak göndermeyi sağlayacak ufak bir tool yazmamdı. Düz mantıkla 1 saat gibi bir sürede ortaya çıkabilecek bu tool u yazmam neredeyse 1 günümü aldı. Neden mi ? cevabı bu muz’u elde etmek isteyenlerin mantığında değil OOP modelinin mantığına bağlı kalmak istememdeki inadım.
Şimdi biraz olayı irdeleyelim; eposta gönderiminin amacı sınav sonucunu kazanan adaylara iletmek, şu anda veriler bir veritabanında ama peki ya yarın, diğer sınavlarda… eğer şimdi böyle olsun yarın ona göre bir modifikasyon yaparız kodda diyeceksek birinci ve bence en önemli programlama kalıbını yok sayıyorsunuz demektir. “Open for extension but closed for modification” / “Gelişmeye açık ama değişime kapalı” kalıba bağlı kalacaksak ne yapmalıyız, veri girişi için bir ortak arayüz ve genişleyebilir bir sistem tasarlamalıyız, veri alımı da bu tasarıma uygun olmalı. Mesela yarın veriler farklı veritabanı sunucusunda, veritabanı sisteminde ya da farklı bir veri kaynağında (xml, csv, xls…) olduğunda kodda değişiklik gerektirmeden basit bir ayar değişikliği ile sistemi yeni duruma entegre edebilmeliyiz. Evet henüz başındayız ama şu anda bile 1 günü geçmesi muhtemel bir kodlama var önümüzde. Devam edelim; eposta girişi, yani gönderilecek olan postanın metni, text bazlı bir giriş olacak, e yarın birisi rich text, html ya da pdf içerikle gelirse ve stillerinde korunmasını isterse. Ya da kişiye göre farklı farklı metinlerin gönderilmesini isteyen bir sistem istenirse, mesela veri kaynağından gelecek olan PUAN kolonunu eposta içeriğinde her kişiye ayrı olmak üzere “…. puan ile sınavı kazandınız” şeklinde bir gönderim istenirse? Yine OCP ye bağlı kalacağız, o zaman veri girişiyle eposta girişinin bu etkileşime açık şekilde yazılması lazım. Ekleyiniz bir kaç gün daha. Peki gönderim sistemi, direkt olarak SMTP adresi alıp mı gönderecek, yoksa yarın bu sistemde bir SMS gönderimi de isterler mi ya da epostalara bir/birkaç dosya ataçlamak istenebilir mi, gönderim tek thread üzerinden mi yapılacak yoksa thread havuzumu olacak, hepsini geçelim bu sistem bir windows forms uygulaması mı olacak yoksa bir web uygulaması mı… bu sorular ve süreler uzayıp gidiyor…
Aslında temelde anlatmak istediğim illaki bir muz için koca ormanı yazacaksınız, ama bu ormanın boyutu gereksinim analizini ne kadar iyi yaptığınızla doğrudan ilişkili. Hiç kullanılmayacak bir genişleme için ek olarak günler harcamanız tamamiyle anlamsız ve gereksizdir. O yüzden her zaman söylendiği gibi kodlama için bilgisayar başına oturmadan önce saatler/günler boyunca gereksinimi doğru tespit etmek gerekiyor. Bu analizin doğru yapılması gereksiz kodlamayı, gereksiz kodlama ile birlikte ortaya çıkacak olan gereksiz hataları engeller ve sonuçta sadece işini yapan bir program ortaya çıkar. Tersi durum içinse aşırı işine odaklanmış, sadece bir case için yazılmış kodlar/programlar mutlaka değiştirilmeye ve değiştirildikçe bozulmaya mahkumdur. Çünkü her yeni değişiklik o projeye başlarken planlanan yapının dışında kalacağında mutlaka kodun temeline yapılan bir tecavüzü zorunlu kılar. Ortaya yamalı bohça misali ne yaptığı belli olmayan günü kurtaran kodlar ortaya çıkar.
Toparlarsak; ihtiyaçların ve genişleme stratejilerinin en başta iyi planlanması ve OOP modele sadık kalınması günü kurtaracak programlardan daha fazla zaman ve imkan kullanımı doğursa da uzun vadede artılarının oldukça fazla olduğu açıktır. Aynı şekilde basit bir eposta gönderim programı yazarken oluşması imkansıza yakın durumları bile koda dahil etmek te boşa heba edilen zaman ve imkandan başka bir şey değildir.
Bahse konu işin sahibinin konuyla ilgili sözleriyle bitireyim; “…şükrücüğüm çok güzel bir kod olmuş ama sanırım küçük bir sorunu var, eposta gönderemiyor”
Post a Comment