From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Mon 20 Sep 2004 - 12:10:58 EEST
Selamlar..
Bilgisayarda olan komutlar bellidir:
Bir sayiyi digeri ile topla.
Bir sayiyi digeri ile karsilastir.
Karsilastirma sonucuna gore su koda git.
Elbette bunun yaninda, bir bellek bolgesini oku/yaz gibi komutlarda
bulunur.
Olay bundan ibarettir vede hemen her dil bunlari bir sekilde yapabilir.
Eger bir dil bunlari yapmak icin fiziksel olarak sisteme sizi ne kadar
yaklastirirsa, yani ornegin dogrudan bellek adresleri ile calismanizi
vs. saglarsa o kadar gucludur, makineye o kadar istediginizi yaptirir.
Ama o zamanda sizin referanslarinizla dilin tuttugu referanslar cakisir.
Bu durumda dil sizin icin bir seyler yapmak isterse, sizin yaptiginizla
onunki kesisebilir. Bu nedenle bazi diller yapmak istediginizi kendine
soylemenizi, sizin yerinize gerceklestirmeyi isterler. Bu sayede kendi
kurallari ile sizin cakismanizi engellemeye calisirlar. Bu durumda
makineye hukmetme kabiliyetiniz dilin makineye hukmetme kabiliyeti ile
sinirli kalir.
Programlamada gozden kacirilan husus programlanan seyin kendisidir:
Bilgisayar: CPU, RAM vs.. Nesneye yonelim, 4GL, Java vs. gibi
yaklasimlarla, bu kavram asilmaya sanal bir ortam programlanmaya
calisilmaktadir. Halbuki, durum bu kadar basit degildir:
Bir program, hangi dilde yazilmis olursa olsun, aslen bir state
machine'den ibarettir. State'ler (durumlar) arasinda gecisi saglayan
eventler vs. bulunur. Sonucta, state diyagrami cizilecek bilesenlerin
sayisi arttikca kombinasyonlar ustel olarak artmaya baslar. Bu surecin
kacinilmaz sonu kaostur ki hic istenmez.
Iste bu nedenle, belirli eventlere denk dusen belirli state'leri yerine
getiren hazir kod bloklari kullanilir: Ornegin "if, case, while" gibi
komutlar ve "printf, open.." gibi kutuphane fonksiyonlari. Bu
komut/fonksiyonlar mumkun oldugunca dar bir state diyagramina
indirgenmeye calisilir. Cunku, her uygulamanin kendi state diyagrami
vardir. Eger siz buyuk state diyagramina sahip (Cok fazla ozelligi olan)
bir komutu buraya koymaya calisirsaniz, tum kombinasyonlari ile birlikte
bu komutun oradaki statelerin tamamini karsilamasi gerekir. Oysa, gunluk
hayatta uygulamalarin durum (state) modeli olculemeyecek kadar genis bir
uzaydan kestirelemeyecek sinirlari olan bir kumeyi kapsar. Bu nedenle
statelerin atomik olmasi, cok dar ve belirli bir durum modelini
kapsamasi istenir.
Devaminda birileri cikar, o durum uzayindan bazi durumlari ele alip, bu
atomik durum bilesenlerini alir daha genis yeni bir state machine
olusturur. VB, Java vb. bu yaklasim uzerine kuruludur. Bundaki asil
onemli husus, buradaki durumlarin (state) sizin state diyagraminiza tam
uyup uymadigidir. Zamanla istekler arttikca bu bilesenlerin uzayi
genisletilmeye baslar. Termodinamik kanunlari devreye girer elbette, bu
durumda ve entropi artisi dogal bir sonuc olur. Yeni baslayan kullanici
bu genis state machine'i ele alinca (kutuphane, component vs.) o kadar
cok durumu isleyebildigini gorunce heyecanlanir. Sihirli degnek
buldugunu zanneder.
Hemen onunla kodlamaya girisir. Oysa, elindeki problemin (kodunu yazdigi
uygulama) hangi durumlari kapsadigini bile henuz gorememektedir. Onun
gozunde elindeki sihirli degnek, ADODB mesela, ado.add ile kayit
ekleyivermekte, SQL'in sihirli kelimeleriyle istedigini hemen geri
alabilmektedir. Fakat burada durum modelindeki database cursor'lerinden
haberi bile olmamaktadir. Uygulama gelismeye kullanilmaya baslar. Bir
sure sonra o gorunmeyen durumlar birer birer gerceklesmeye baslar. State
machine, bu yeni durum icin bir sonraki adimi tanimlamamistir. Dahasi
kullandigi komponentin durum modelini ve uzaydaki hangi durumlari
kapsadigini, dahasi onun oturmasi gereken durum modelini bile anlamaz.
Sonucta uygulama cuvallamaya baslar. Kacinilmaz sondur.
Iste, C burada size soyle bir imkan sunar. C, cok basit, cok yalin bir
takim komutlar sunar. Siz bu temel komutlarla gordugunuz state machine'i
bina edersiniz. Bu sayede kapali kutu olan ve state mekanizmasini
anlamadiginiz komponentlerin size uymayan taraflari ile ugrasmazsiniz.
C, sonucta daha atomik olmakla, sizin bir uygulamada cikabilecek olan
stateleri analiz etmenizi zorlamak gibi bir huyu vardir. Buda, "Ben
hangi dili kullanayim" diyen yeni programci icin en gerekli husustur. C
ile baslarsaniz, bu state analizini yapmayi daha kolay ogrenirsiniz.
Cunku, diger dillerde olan hazir state machine modelleri, birer kara
kutu gibi davranir ve sizden o detaylarin pek cogunu saklarlar. Bu
detaylar ise ilk ogrenilmesi gereken hususlardir. Ornegin ADODB, sizden
dosyanin bir handle'i oldugunu, dosyanin bir binary stream oldugunu,
dosyanin belli sayfalar halinde tutulursa daha iyi olacagini vs. saklar.
Bunlari bilmek istemeyebilirsiniz. Ama bunlar oradalar. Bunlari
kullanmaniz dogrudan veya dolayli olarak kacinilmaz.
Pek coklari, "Hic isim olmaz" kafasindan giderler. Bana ne bu kadar
atomik islerden.. Sonrasinda, mevcut komponentlerin sunmadigi uzayda
bulunan basit bir durum karsilarina cikar. Bu state'i kurmakta
zorlanirlar ve boyle bakinirlar. Halbuki, gelin, C ile baslayin. Temel
state cozumleme mekanizmalarini cozun. Tecrube saglayin. Altta olup
bitenleri bilin.. Bunlari sokunce sizi kimse alikoymaz ki hazir
kutuphaneler veya ust seviye diller kullanmaktan !
Bir diger sorunda su olmus. Neden C++ degil, neden proxy vs. yazanlar C
kullaniyor. Cevabi basit. Bir proxy gorundugunden daha karmasik bir
state modeline sahiptir. Dahasi is yuku dusunulunce, genel gecer
bilesenlerdeki fonksiyonelitenin getirecegi ek kaynak gereksinimi
gercekten ciddi bir problemdir. Bu acidan, insanlar C kullanarak tamamen
kendi durum modellerine uyan, fazlasi olmayan, durum modeli iyi
belirlenmis yeni bir kod yazarlar. C yerine mesela Python kullanirsaniz,
mesela gereksiz olan garbage collection mekanizmasi ile ugrasmaniz
gerekebilir. Dahasi bu mekanizmanin durum modelinin proxy gibi karmasik
bir yapida hangi durumlari etkileyecegini kestirmek de guc olabilir.
KISS kaidesi kisaca. Her ne kadar oradaki "Simple" kelimesini yanlis
anlamak bir tur paradigma olmus olsada..
C++ ile C arasinda performans farki vs. yoktur. En azindan bu fark ihmal
edilebilir. Ama bu tur uygulamalarda nesne modelinin verebilecegi cok
fazla sey yoktur. OOP'ta bir tur sihirli degnek, bir tur programlamayi
kolaylastirici etmen gibi gorulmektedir. Kabaca, gumus mermi: "Silver
Bullet". Oysa, "No Silver Bullet" kaidesi bunda da gecerlidir. Reuse vs.
konulari gercekten abartidir. Pek cok uygulamada duz C kodu cok daha
reusable olabilir. Pek cok uygulamada en buyuk sorun arkasi kedi onu
kopek olabilen acaip varliklarin olabilmesidir. Bunu bir "hayvan"
sinifindan inherit etmeniz imkansiz olabilir. Dahasi bundan inherit
edeceginiz nesne bir timsah olabilir ki is iyice karisir.
Kisacasi, OOP, harbiden iyidir. Kullanislidir. Cogu zaman tasarimi
kolaylastirir. Ama her zaman en iyisidir seklinde dusunmek yanlistir.
Bir ipucu olarak, consumer application'larda C++, C'Den cok daha verimli
olur: Banka, ERP, CRM, Cari vs. Ama System Level uygulamalarda C++ cok
daha zorlastirici bir sey olabilir: "Nesneler, programcinin
kafasindadir, sistemde nesne filan yoktur.." Hal boyle olunca, olmayan
nesneleri icat etmeye calismak beyhude bir yuk olacaktir..
Saygi ve sevgiler..