• (bkz: kutsal import aşkına ne anlatıyorsun kuzum sen)
  • (bkz: dediğini anlıyor ve yapısal olarak parçalanıyorum)

    hep bunu yapmak istemiştim. holey!
  • (bkz: unsafe code içinden canım string topla benim için)
  • nesne yonelimli programlamada nesneler arasi iliski her ne kadar duzenli gozukse de bu kosept kodun temiz ve okunabilir olmasini garanti etmez. bunun nedeni nesne yonelimli programlamanin fonksiyonel programlamaya gore daha "stateful" olmasidir.

    nesne yonelimli programlamanin kodu temiz tutan en buyuk artisi "encapsulation" dir. yani gelistirdiginiz obje bir baska objeyi kullanacak veya genisletecek ise o objenin icinde neler donuyor bilmek zorunda degildir, zaten o obje de hem kendini genisletilebilir, hem tekrar kullanilabilir hem de tamamen izole edilmis sekilde tasarlanmistir. yani bir araba nesnesi dusunun, o nesneyi kullanacak sofor arabanin yanma sisteminde ne kadar yakit, ne kadar oksijen, ne zaman atesleme yapilacak ilgilenmez. bildigi ve ilgilendisi sey gaz pedalina ne kadar basacagidir. bu yontem kodun butununu gormek yerine belli bir yere odaklanma acisindan temizlik saglar. ama bu sistemde en buyuk problem objelerin durumlarinin olmasidir. yani objeler ile ilk etkilesime girdiginizde tahmin ettiginiz durumda olmayabilir. yine araba ornegi ile devam edersek arabanin gaz pedalina bastiginizda arabanin gidiyor olmasi icin daha onceden arabanin calisiyor ve vitesinin uygun konumda olmasi gerekir. yani nesne bir durum barindirir ve o nesne ile iletisime gecmeden once nesnenin son durumunu iyi biliyor olmaniz gerekir. eger ayni nesne ile bircok baska nesne iletisime geciyor ise ya da kullandiginiz sistem asenkron tasarlandiysa nesne ile iletisime gecmeden once nesnenin son durumu her an degisebilir. yani calistirdiginiz ve uygun vitese attiginiz arabanin gazina bastiginizda gitmeyebilir cunku o arada bir baska kisi o arabayi durdurmus, ve vitesi bosa atmis olabilir. ıste tum bu nedenlerden dolayi nesne yonelimli programlamada nesnelerin son durumlarini devamli kontrol etmelisiniz, bu da kodun karmasasini arttiran bir faktor, yani nesne yonelimli programlama her zaman temiz kod yazmanin anahtari degildir. hatta arka planda ne oldu, objenin son durumu ne bilmemek de kodun okunabilirligini cok dusurebilir. bazi durumlarda temiz kod yazmak icin fonksiyonel programlama gerekebilir, cunku fonksiyonel programlamada "stateful" durumlar pek tercih edilmez, fonksiyona hep yani durumda girmek ve hep beklenen durumda cikmak ana hedeftir.

    eger yazdiginiz uygulamada zaman icinde nesnelerin degisecegini, nesneler arasi ilisikinin degisecegini dusunuyorsaniz nesne yonelimli programlama daha uygunudur ama daha cok eylemler yani aksiyonlar degisme egiliminde ise ve herhangi bir anda "state" yani durum tutmak kodun kalitesini dusurecek ise fonksiyoel programlama daha tercih edilebilir. o nedenle ornegin bankacilik uygulamalarinda nesne yonelimli programlama daha tercih sebebi iken web gelistirme icin fonksiyonel programlama daha uygun olabilir. hatta bircok durumda bir uygulamanin farkli yerlerinde farkli paradigmalar uygulamak daha mantikli olur. ozelikle database tarafina yaklasilirken nesne yonelimli programlama, ama kullanici arayuzune yaklasirken fonksionel programlama daha mantikli olabilir.

    ısin ozu, nesne yonelimli programlamayi cok seven ve gerekli bulan ve nesne yonelimli programlamanin disina pek cikamadiginiz bir dil olan java gelistirici olarak diyebilirim ki kullanilan yaklasimin kodun temizligi , spagetti olup olmamasi ile ilgisi dogrudan yoktur. cunku hicbir yaklasim kodun nasil yazildigini garanti etmez. kodun okunabililirligini arttiran en onemli sey gelistiricinin neyi yazdigini ve nasil yazacagini iyi bilmesinden gecer. bu da dogrudan yazilim gelistirme surecinde kullanilan yontemle alakalidir. temiz kod yazmak icin benim dusunceme gore; ister nesne yonelimli ister fonksiyonel yazin, en onemlisi neyi yazdiginizi cok iyi bilin, daha sonra hangi yontemi nerede kullanacaginizi cok iyi bilin. bunun yaninda nesne yonelimli bir kodu ya da fonksiiyonel kodu tdd(test driven development) gelistirme sureci ile yazin, bu size kod yazarken hep temiz kod yazmaniza yardim eden bir klavuz olacaktir. tdd demek kodunuza test yazin demek degildir, once testleri sonra kodunuzu yazin demektir, yazdiginiz testler kod yazarken size klavuz olacak demektir.
  • böyle bir şey var sanırım.

    amatör dönemlerimde bana da her oop olmayan dizilim spagetti gelirdi. bir de takıntılıyım malesef, kendi yazmadığım şeyin üzerine yama yapmaktan nefret ederdim. zamanla, işin mükemmelliği değil paramı kazanıp ne bok yerlerse yesinler noktasına geliniyor.

    gene de kendi işinizse "size göre" en anlaşılır dili edinmeye çalışın. taviz vermeyin.
  • programlama paradigmalarından habersiz, kimi zaman gördüğü her koda makarna diyen bir wepçi, kimi zaman 2 satır kod düzeltip 3 kuruş almak yerine projeyi baştan yazıp gözünü 5 haneli yeşillere dikmiş yokuşçu bir freelancer, kimi zaman çalıştığı şirkete yeni girmiş ve ondan öncekilerin üzerine basarak sıçrayabileceğini düşünen bir çömez olabilir. çalıştığı projelerde tek hedefi ay sonunu bir an önce getirmek olduğundan, ooprogramming in sadece class ve object lerden oluşmadığını öğrenecek kadar deneyim kazanmamışta olabilir. yazdığı projelerde, sınıf dışında kullandığı her if her else için de kendisine kafam girsindir.

    (bkz: kendi yazmadığı her koda spagetti diyen yazılımcı)
    (bkz: spagetti koda oop un tersi diyen yazılımcı)
  • bilmeyenler için amme hizmeti;

    oop oop (object oriented programming) / nesne yönelimli programlama
    spagetti kod (spaghetti code) ise karışık ve takibi zor bir kodlamadır, eski php ve asp'ciler iyi bilir.
hesabın var mı? giriş yap