From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Tue 31 May 2005 - 09:50:32 EEST
Selamlar..
Bu gibi sorunlar, yeterince tarih dersi bilmiyor oluşumuzdan
kaynaklanıyor.
Sanırım, birileri oturmuş, durun sıkı bir icat yapayım diyerek OOP ve
OOP tabanlı dilleri icat etmiş gibi bir his içindeyiz.
Devri zamanında analiz, geliştirme kodlama teknikleri ile uğraşırken
yapısal yöntemler yerine nesne kavramına yönelik eğilimlerin bu
işlevlerde daha etkili olduğu görülmüş. Sonuçta OOP paradigması ortaya
çıkmış. Ama bu paradigma sadece "CLASS/INSTANCE/INHERITANCE..."
modeliyle sınırlı değil. Analiz aşamasından başlayarak komple bir
felsefe sunuyor. Bu konu zaman içinde oturuyor ve nihayetinde OOP
kavramları ortaya çıkıyor. En nihayetinde, madem nesneler işi böyle
kolaylaştırıyor denilerek SmallTalk, C++ gibi nesneye yönelik diller
geliştiriliyor. Yani, OOP ve OOP tabanlı diller devrimsel bir değişim
değil, evrimsel bir gelişimin ürünleri.
Ama bizim gibi işe tepeden dalanlar bu yöntemleri, o dönemdeki bilgi
birikimini vs. bilmeden, balıklama OOP işi içine dalıyoruz ve sonuçta
çoğu zaman iyi kavranamamış olan OOP ile işi daha çok yüzümüze gözümüze
bulaştırıyoruz.
Bugün, sanıyorum aramızda yoktur, "Mythical Man/Month" u okumuş olan.
Bu kitap yurtdışında ders kitabı olarak okutuluyor, bazı
üniversitelerde. Mamutlarla alakalı olduğunu düşünerek hasbel kader
elime geçirip okuduğum bu kitaba şöyle bir göz gezdirseniz dahi, bilmem
kaç yıldır (İlk basım tarihi 70'ler olması lazım) sorunların nasıl
ortada olduğunu kolayca görebilirsiniz. Elbette bu sorunlara karşı
çözümlerde olacaktır, OOP'ta bunlardan birisidir. Benzer şekilde bu
işlerde kült olmuş kitapları okumak faydalı olacaktır.
Kabiliyet ve imkan uzayı olarak, ne Java, ne Python, ne C++ ne de bir
başkası OOP mantalitesini tek başına sağlayamaz. UML vs. de aynı şekilde
işin hikaye kısmıdır. OOP dizayn aşamasından kodlamaya ve teste
varıncaya kadar komple bir model sunar. Standardize edilebilir. TKY
(ISO9001 vs.) işindeki "süreç" tanımlarına uydurulabilir. Reçete gibi
formlar vs. yoluyla implement edilebilir. Hal böyle olunca verimliliği
artırır. Ama siz en alt safhadan itibaren bu mantaliteyi
kullanmıyorsanız, size sadece yük olur, çoğu zaman..
Basitçe önce söylenmesi gereken şey şudur. Standartlar, de-facto veya
ilgili kurumların koymuş olması farketmeden, hiç bir zaman sektöre
öncülük etmezler. Evinizdeki prizin deliklerinin arasının kaç mm
olacağı, kaç volt olacağı vs. bir standartta yazılıdır, ama bilinki bu
standart hemen her eve prizler döşendikten sonra ortaya çıkmıştır. En
basitinden, 56K Modem standardı olan V90, X2 ve K56flex yıllarca
ortalıkta satıldıktan sonra, K56Flex'i alıp standart yaparak ortaya
çıkmıştır. Eee, şimdi nereden çıktı bu hikaye?
Pek bilinmeyen husus, yazılım geliştirme yöntemlerinin de
standartlarının olduğudur. Sanıyorum çoğumuzun IEEE Std 730, 830 gibi
şeylerden pek haberimiz yoktur. Mesela IEEE Std 830-1984 SRS işini tarif
eder. Yani, "Software Requirements Specifications.." Hemen hepimiz bunun
işin kalbi olduğunda hem fikir oluruz sanıyorum. Ama, hiçbirimiz ne bu
standardın Annex A'sında yeralan template'leri biliriz, nede mesela
Yazılım testleri için IEEE/ANSI Std 1012'ye uyarız.
Telifli dökümanlar olduğu için yayınlama veya cut & paste imkanım yok.
Ama zamanında bu standartlar için avuç dolusu para vermiş birisi olarak
şunu söylemek isterim. Eğer bir yöntem "Resmi Standart" olmuşsa, önceden
defaten denenmiş ve de etkinliği kanıtlanmıştır. BU ve benzeri
standartlar ve analiz/dizayn hakkındaki kavramlarında öne çıkan nesne
modeli, gökten inme bir OOP paradigması değil, bu işin evrimsel gelişimi
sürecinde oluşan OOP tekniğidir.
Toparlarsak, OOP tekniği evrimsel bir gelişmedir ve hedefi daha verimli
ve etkili analiz/dizayn/test tekniklerinin geliştirilebilmesidir. Bu
sayede her zaman (yada ezici çoğunlukla çoğu zaman) yapısal programlama
paradigmasından pratik şekilde daha ucuza çıkar.
Ama siz bunu sadece bir dil özelliği olarak görürseniz, kimsenin sizin
için yapabileceği pek bir şey yoktur. Her zaman derim, fare tutmayı
öğrenmekle, QTDesigner, VB vs. Form editörüne tıklamayı öğrenmekle
programcı olunmaz..
Yanılmaya müsait olan husus, Herşeyi nesne yapmış olmakla, C++ gibi OOP
bir dil kullanmış olmakla, OOP kavramını yakalamış olmayacağınızdır. OOP
işi bir dizi maille açıklanamayacak kadar müştemilatlı bir konudur,
belki aylak kalırsak kıyısından köşesinden biraz bahsederiz..
Saygı ve sevgiler..
> Bu fikirlere paralel olarak, bir de ortada yalan yanlis bir genelleme
> bulunmakta.
> >OOP ile gerceklestirilen bir projenin , bakim ve guncellemesi yapisal
> yaklasima gore daha
> az maliyetlidir. < İsin temelinden bihaber kisileri bu kelime okadar
> cekmektedir ki.
> Ama anlasilmayan; gerek yapisal gerek oop olsun, ne kadar iyi
> dokumanlastirilsalar bile,
> analizin , yazilim sureci icerisinde degismesi halinde cikan
> maliyettir. OOP olunca bu is
> hemen biter diye bir sey olamaz, dusunulemez bile. Dev bir agacin
> yapraklarini
> budayabilir yada yeni dallar asilayabilirsiniz,oop belki bunu
> kolaylastiran olabilir, ama agacin
> kokunu kesip yeni bir kok koymaya kalkmak nedemek. İsin ozu neyazikki
> en az deger ve sure verilen analiz ve tasarimda yatiyor.
>
> Umarim bu onyargi cabuk biter, yoksa karar verenlerce planlanan vakti
> asan projeler yuzunden
> verilen sozleri sirtlayan bizler harap olmaya devam ederiz.
_______________________________________________
Linux-programlama mailing list
Linux-programlama@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama