Gökçe’nin Web Güncesi (gwg)

21 Yorum - “Programlamada Geleneksel veya Nesne Tabanlı Seçim”

1. 
   1
   Taha Paksu:
   Mayıs 7th, 2008 @ 9:56 pm

   Procedural çalışan bir web sitem vardı fonksiyonların çok dağınık durduğundan ara sıra aynı fonksiyonu başka bir isimle tekrar yazdığım bile olmuş (o kadar çok fonksiyonu vardı) OOP yapıyım düzenli dursunlar bari dedim. tabi şimdi de class’ları birbirine bağladıkça sitenin performansı gitgide düştü.. bu birbirine bağlama olayı yerine harici bir include dosyasına erişim sıralarına göre include mi ettirsem hepsini diye düşündüm bu seferde hepsini yüklemek istemedim çünkü hepsine aynı anda ihtiyacım olmuyor. Kafam karıştı çalışan kodum yarım kaldı :) Ama bunu çözebilirsem daha düzenli bir şekilde kod yazabilirim artık. Anlayabileceğim bi önerisi olan?

2. 
   2
   Gökçe YALÇIN:
   Mayıs 8th, 2008 @ 11:16 am

   Sistemi ve büyüklüğünü tabii ki bilmiyorum, fakat yeterince büyükse ve daha çok uzun yıllar kullanılacak/verim alacağın bir uygulamaysa ilk yapacağım öneri, herşeyi boşverip sistemi ZF veya Agavi’de tekrar yazman. Sadece Loaderları ve MVC’leri bile işini çok kolaylaştıracaktır.

3. 
   3
   Taha Paksu:
   Mayıs 8th, 2008 @ 2:46 pm

   ZF gözümü korkutuyor + şimdilik PHP4 sistemde çalışacak bi kod kümesiyle boğuşuyorum :) Ayrıca framework değilde gerekli classları kendim yazarak sistemin yükünü biraz hafifletmek iyi olur diye düşünüyorum. caching belki işime yarar hız konusunda diye smarty’e entegre etmeye çalışıyorum şimdilik. Classları init diye bi class’ın içinde var olarak load ettiriyorum aynı CodeIgniter loader’ı gibi gerçekleştirdim. İşte açılış konusunda ob_start ob_flush gibi kodları geri çekmeyi düşünüyorum. Öyle devam ediyo işte.

4. 
   4
   Murat BEŞER:
   Mayıs 14th, 2008 @ 11:03 am

   Gökçe’ninde dediği gibi, ZF ‘nin elementleri ile birlikte bunu gerçekleştirir isen daha rahatlayacaksındır.

   Fakat tabiki performans düşüşü olacak bunuda kabullenmek zorundayız.

5. 
   5
   Ahmet Karakilcik:
   Mayıs 29th, 2008 @ 2:59 pm

   Php yi uzunca bir süredir OO ve procedural ortaya karışık şekilde kullanan bir koder olarak, ortaya karışık işlerin duruma göre pekçok ihtiyacı karşıladığını söyleyebilirim.

   Yazıda atlanılan bir konu var o da OO kodların yeniden kullanılabilirliği ve objelerin kalıtsallığı (inheritance) bazı durumlarda sistemleri ağırlaştırıyor gibi görünsede, tekrar yazma, objeleri tekrar kullanma gibi artıları ile OO kullanılabilir kullanılmalıdırda.

6. 
   6
   Gökçe YALÇIN:
   Mayıs 29th, 2008 @ 3:43 pm

   @Ahmet
   Öncelikle yanlış anlaşılmayı kesinlikle istemem. Hem OO (PHP’de PHP’nin yetersizliğinden ileri gelen OO pek sözkonusu olmasa da en azından Java’da) kullanmış biri olarak kesinlikle bir tarafa sahip değilim. Yazının amacı bilişim dünyasında herhangi bir araçta takım tutmadan, amaca göre yöntem izlemenin doğru olduğunu vurgulamaktı. Procedural ve OO ‘nun ayrı ayrı faydaları var, bu yüzden karşılaştırmalarda da bir tarafa ek yüklenmemek için özenle aynı sayıda tez ve karşı tez kullandım.

   Tabii ki yazılım performansı, her zaman birincilliği oluşturmaz. Donanımsal güç günümüzde giderek ucuzlaması karşısında, yazılım performansı maliyetteki payını insan kaynakları yani iş gücü/zaman a bıraktığı düşünülürse, bu iş gücünü etkileyecek yöntem çok büyük değer arzediyor.

   Yanlış yöntem, yazılım sektöründe boşuna emek/zaman dolayısıyla üretkenliği ve maliyeti zarara uğramak demek. İki birbirine zıt yanlış seçimi (verdiğim Drupal’i procedural yazmak ve Hello World ‘ün OOP’si) bu yüzden verdim. Yoksa ne OO’a, ne procedural’a karşı olduğum var.. Öyle yapsaydım kullanılacak koşulları bilmeden terlik ve ayakkabı arasında taraf tutmama benzerdi, komik olurdu.

   Nerede ne kullanılırın daha da detayına neredeyse sonsuz inilebilir; madem uzun soluklu, sıkça bakıma ihtiyaç duyacak bir yazılımımız olacak, o zaman OO dedik. Peki OO ise, PHP OO’da ne kadar yeterli, niye Java/JSP olmasın? Niye Event driven olmasın, mesela C#? Bu sefer yazılım geliştirme ve bakım kolaylığı bi kat daha mercek altına alınmış oluyor. Bu durumda yazılım esnekliği ve developer community (PHP) tarafına karşı düzen, stabilite karşılaştırılacak.. Sanırım bi kez daha başarıyla konu dağıttım. Neyse, fazlasını söylediysem de umarım yanlış anlaşılmamışımdır.

7. 
   7
   ikizmaz:
   Eylül 9th, 2008 @ 6:56 am

   Sözüm meclisten dışarı, OOP nin en büyük getirisinin kod tekrarını engellemek olduğunu sananlar var. Halbuki amaç kod tekrarını önlemekse hiç oop ile uğraşmak gerekmez. prosedürel olarak da bunu yapabilirsiniz. tekrar tekrar kullandığınız kodları fonksiyonlar altında toplayıp ve gerektiğinde include ile kullanarak da tekrarı engellersiniz. üstelik bunu geleneksel prosedürel yöntemlerle ve çok kolay bir şekilde yapmış olursunuz.

   çok sık söylenir, oop bir programlama yaklaşımıdır diye. ama kulaklarımız bu ifadeye çok alıştığı için, ifade ettiği anlam gerçekten bi kulaktan girer bi kulaktan çıkar. evet oop bir programlama yaklaşımıdır ve bir süreci ifade eder bana göre. oop yi doküman okumaktan öteye götürerek kullanmaya başlayıp iyice bu yaklaşımı içinize sindirdikten sonra, işin kurgulanmasından, kodlanmasına, teslimat sonrası destek-bakım-iyileştirme konularına kadar bir çok hususta ne kadar daha kolay çözüm ürettiğinizi görürsünüz.

   somutlaştırmak her zaman konuları elle tutulur ve gözle görülür hale getirir. bu da kolay anlaşılma ve somut olduğu için kolay entegrasyonu, modüleriteyi sağlar. tıpkı somut olarak gördüğümüz herşeyi daha kolay anladığımız gibi… işte oop, gerçek hayattaki bu somutlaştırmanın karşılığıdır. ve bu nedenle gökçe nin dediği gibi programlamayı çok daha çözümlenebilir ve kavranabilir yaptığı için çok önemli bir yaklaşımdır.

   ama bu yaklaşımı öğrenmek, emek ister. yani php de oop kurallarını öğrenmekten bahsetmiyorum. oop yaklaşımı ile programlamayı, dilden bağımsız birşekilde içine sindirebilmek biraz emek ister demek istiyorum. çünkü mantığı klasik spagetti kodlamadan çok farklıdır. ilk zamanlarda nerden başlayacağınızı, bir sonraki adımın ne olacağını bilemezsiniz. sudan çıkmış balık gibi olursunuz. zaten predürel yöntemle takır takır işini gören programcı için bu durumda kalmayı kabullenmek ve oop de ısrar etmek ciddi bir sabır ister. ama hakkını vererek oop ile yaptığınız ilk projenize iş bittikten sonra şöyle geriye çekilip bakınca gördüğünüz manzara karşısında mest olursunuz…

   ayrıca oop ile prosedürel kodlama öyle kesin sınırlarla birbirinden ayırmak mümkün değildir. aslına bakarsanız oop kullansanızda metodlarınızı yazarken prosedürel yazıyorsunuzdur.

   işte bu yaklaşım farkını kavramak ve hayata geçirmek (mantığını içine sindirene kadar) çok yorar programcıyı. en azından bende öyle oldu. bu nedenle de çoğu zaman kolaya kaçarak, hızlıca prosedürel yazmak tercih edilir çoğu zaman.

   ama şurası bir gerçek ki oop yi iyice kavramak ve ufak tefek işlerin dışında proje olarak ele alınabilecek her türlü işte kullanmak gerekir. projeyi tamamen oop ile yapmakta gerekmez bence. bazı noktalarda tabii ki prosedürel de kullanılabilir ama işin asıl kısmı, çatısı aslen oop üzerinde döndüğü sürece size sunduğu çok büyük olanaklar var. inanılmaz mekanizmalar sunar programcıya..

   bütün bütün bunları (php de oop kod yazmanın kurallarını öğrenmekten öteye taşıyıp) bilfiil oop kullanarak proje yapmayan birisi kafasında kolay kolay canlandıramaz. oop yi kullanmayan birisine oop nin kolaylıklarını anlatmak gerçekten çok zor…

   birde olur olmaz yerde php nin berbat oop yapısı olduğundan bahsedilir. ben buna katılmıyorum. evet bazı eksikler var ama php 5 te ki oop ile java daki oop arasında öyle inanılmaz seviye farkı yok. php 5 ile istedikten sonra hiçte öyle bahsedildiği gibi sıkıntı yaşamıyorsunuz. elbette gayet rahat ve güzel bir şekilde oop programlama yapabiliyorsunuz. bence php 6 ile birlikte, java gibi saf oop dillerden hiç fark kalmayacak. php 5 şu haliyle bile çoğu oop mekanizmalarını sunuyor. php nin oop özelliklerini eleştirenlerin oop yi hayatlarında hiç kullanmadığını ve sadece birkaç forumda okuduklarıyla fikir oluşturan kişiler olduğunu düşünüyorum. yani bir takım işgüzar insanlar…

   NOT: bunlar sadece benim fikirlerim. bu fikirler yaşadıklarımdan edindiklerim. herkesin fikirleri ve şartları farklı olabilir. gereksiz polemikler çıkabiliyor da….

8. 
   8
   Gökçe YALÇIN:
   Eylül 9th, 2008 @ 5:31 pm

   Herşeye katılıyorum, PHP’nin OOP’nin hakkını verdiği konusu dışında. PHP işine yarıyanı alan, ve web geliştirme konusuna odaklanan bir dil. Java gibi genel bir kullanıma sahip değil, dolayısıyla OO konusunda olduğu gibi aynı ligde değiller. PHP’nin kullanılabilirlik konusunda bütününe bakınca Java’nın özellikle OOP’de gerisinde olması çok normal. Java’da oyun yazılır, PHP’de temeli mainframe terminal uygulamalarına benzeyen web programlaması yapılır. Dolayısıyla zaten hedefler buna uygun değil. Bir çok programlama dili, bir çok yere tutulsa da, ağır basan ve güçlü oldukları yerler kategorize edilirken PHP’nin prosedürel bir dil olduğu söylenir.

   PHP 6 da yapılacakları dizdi ve OOP bu projenin ağır topu değil, PHP 6 şu anki haberlere göre tam bir unicode desteği ve register globals, magic quotes kaldırılması ( ki bu bir gelişmeden çok bir yanlıştan dönme ) haricinde büyük gelişmeler sunmuyor. Hedef unicode/multibyte karakterler oldu, çünkü insanlar ‘biz masaüstü uygulamalar yapmak istiyoruz’ demiyor, UTF-8′de niye strlen doğru sonuç vermiyor diyor.

   Aslında web uygulamalarında bunu tartışmak çok doğru olmayabilir, nitekim PHP’de scroll edilecek bir UI objecti yok. PHP GTK’nin var, fakat güç PHP’den değil, GTK’dan gelmekte.

   Tekrar başa dönersek, PHP’nin hedefi web uygulamaları programlamasında cevap olmak, kolay olmak ve en önemlisi hızlı yazılabilir olmak. PHP’nin web uygulaması yaparken sağladığı kadarının bize yetmesi de bunun bir sonucu. Yoksa, PHP’de try, catch, throw kullananların sayısının bir hayli az olmasının bir nedeni var. Pek ihtiyaç olmuyor, PHP’yi geliştirenler neden bu konunun üzerine gitsin? Ve üzerine gidilmeyen bir işin, neden bütünüyle bakıldığında iyi olduğunu savunalım? Dolayısıyla bu noktada kullanabileceğim tek kelime web uygulamaları için “yeterince iyi” olabiliyor.

   Aslında yazımda sizin söylediğiniz gibi insanlara doğrudan bir şey söylemektense, iki tarafın sağladığı genel fayda ve dezavantajlarını tanıtıp seçimi kendileri yapmasıydı. Yazıda getirdiği fayda maddelerinin sayılarına kadar ikisini de eşit tuttum.

   Bir de, “ufak tefek işlerin dışında OO kullanmak gerekir” demişsin, ona cevaben;
   Linux kerneline ufak bir proje diyemem, ama OO olmadığı biliniyor. Gelmiş geçmiş en iyi oyun motorlarından Quake 3 de öyle. Bunların istisna sayılıp sayılmayacağını bilmiyorum, örneğimi, istisnaların sonu olmayabileceği için, ben bütün genellemeler yanlıştırla aynı şey olan hiçbirşey istisna değildir diyerek verdim.

   Buarada yazıya eklenebilecek bir not, objectin içindekileri prosedürel yazmak bir yana, bilgisayar yapacağı işleri prosedürel hale getirir. Yani yazılan ne olursa olsun, sonuçta alt alta yapılacak işlerden oluşacak bir dizi emirden ibaret olacaktır. İnsanoğlunun doğasında seçim yapabilme isteği var. OOP vs Procedural başlığında “O mu Bu mu?” sorusu olduğundan, bu seçim şansını en iyi vurgulayan başlık olarak gördüm o kadar. Bir takım avantaj ve dezavantajlarıyla, çalıştığınız konudaki projede bu sorunun cevabıyla hareket edeceksiniz. Eğer bu soruyu sormuyorsanız, ya elinizde bildiğiniz yada öğrenmeye cüret ettiğiniz maddeler yok demektir. Dolayısıyla, bu seçim OO ‘yu kavramış biri olursanız anlamlı olacaktır. Anlatılanların hiçbirisi size OO’nun ne olduğunu söylemez, buradaki bilgi bu seçimi yapmıyorsanız ne şansları kaybettiğiniz konusunca ufacık bir giriş, o kadar.

   Not: Tabii ki senin fikirlerin, ve paylaştığın için tekrar çok teşekkür ederim. Bu arada şöyle bir baktığımda bir süreden sonra hitabım “sizden”, “sene” dönüşmüş, umarım gücenmezsin.

9. 
   9
   ikizmaz:
   Eylül 9th, 2008 @ 11:09 pm

   yok canım ne gücenmesi.
   bu arada bişeyler daha ekleyeyim bu konuda.
   php nin oop özellikleri hakkında olumlu görüş sahibi olmam, sadece bir web geliştiricisi olarak bana ihtiyacım olan mekanizmaları sunuyor olmasından kaynaklanıyor. sonuçta kaçımız oop yi dibine kadar kullanan programlama gurusuyuz ki. hem php nin bir web programlama dili olduğunu unutmamak lazım. yani ben php ile çok rahat oop yapabiliyorum ve öyle “ulan bu da olmaz mı bir dilde ya” dediğim bir zaman olmadı. dolayısı ile php nin oop özelliklerinin çok kötü olduğunu söylemek biraz haksızlık oluyor. ha eksikleri yok mu? çok sofistike baktığınız zaman belki vardır bilemiyorum. java yı çok yüzeysel inceledim ben, ve gördüğüm kadarı bir web geliştirici için öyle arada uçurum göremedim. istedikten sonra php ile de gayet güzel oop yapılabiliyor.

   php6 ile çok fazla şey söyleniyor. benim ayrıntılı inceleme şansım olmadı. bazı yeniliklerden bahsediyorlar, bunlardan birisi de daha iyi oop olduğu söyleniyor. ama kullanmaya başlamadan bu konuda net birşey söylemem zor. (belki bu konuda ileride ayrıntılı birşeyler yazarsın)

   birde linux ve Quake 3 ü prosedürel programlama konusunda olumlu birer örnek olarak göstermişsin ancak bence bunlar istisna (ama tabi tartışılabilir). özellikle işletim sistemleri direkt olarak donanım üzerine yazıldığı için daha çok makine diline yakın diller daha uygun oluyor sanırım, bilemiyorum. ayrıca çekirdek belki %100 prosedürel olabilir ama daha yukarıdaki uygulamalar da mı prosedürel. bilmiyorum ama tahmin ediyorum ki çekirdek dışındaki uygulamaların çok büyük çoğunluğu oop dir. quake 3 konusunda ise (eğer bunların istisna olmadığını söyleyen birisi varsa ona) bu oyunun oop ile daha başarılı yazılma şansı olup olmadını sorarım. özellikle bu tür oyunlarda oop bulunmaz hint kumaşı bence.. (ayrıca quake 3 ün prosedürel olduğunu ilk kez duydum. gerçekten bunu yazan adamların elini öpmek lazım. şaka değil, cidden çok büyük programcılarmış.)

   ayrıca tabi dil ne olursa olsun sonuçta makina onları prosedürel olarak işliyor olabilir. ancak burada unutmamak lazım ki oop bir dil değildir. yani bu söylemi yukarıdaki gibi kullanabilmek için oop nin bir dil olması gerekir bence. mesela java ve pascal karşılaştırması yaparken bunu örnek verebilirsin. oop bir kurgulama yöntemidir(bir iş yapış şeklidir). tamamen yazılımcıyı ilgilendirir ve işini kolaylaştıran bir araçtır. yani oop nin hedefi aslında programcıdır, bilgisayar değil. orada çok ince bir ayrım var. yani python ile oop yaklaşımı ile hazırladığınız bir uygulamayı siz hiç zorlanmadan java da tekrar baştan kodlayabilirsiniz. her iki dili bilen birisi için bu iş sadece benim bu yazıyı yazdığım kadar zordur. makina açısından, o şekilde bakılırsa aslında oop yazarken de prosedürel kullanırsınız. öyledir de.. yani o açıdan bakarsanız oop, prosedürelin bir alt kümesidir denebilir. hem oop hem prosedürel olan php gibi dillerle kodlama yaparken, oop yaparken, presedürelin tüm kurallarına tabisinizdir. bu durum aşağıdaki gibi ifade edilebilir; :)

   class oop extends prosedurel
   {
   }

   sonuç olarak; oop gibi bir yaklaşımı içine sindirmek için harcanacak zaman gerçekten yol su elektrik olarak programcıya geriye dönüyor. buradan, henüz oop yapmayan ya da oop yi sadece phpclasses.org dan sınıfları alıp kullanmaktan öteye gitmeyen arkadaşlara şiddetle tavsiye ederim. benim bu konuda geçtiğim süreç ve edindiğim deneyim, bu yönde. ve öyle ahım şahım, öğrenmesi zor birşey de değil. sadece biraz çaba ve pratik istiyor.

   bu arada üstadım aslında yazılarını yazarken çok da ortada olman ve hakem gibi davranman gerekmiyor. benden söylemesi :)

10. 
    10
    Gökçe YALÇIN:
    Eylül 16th, 2008 @ 2:31 pm

    Dediğim gibi istisnalara pek inanmıyorum bu konularda, nitekim linux/unix’in pek çok konsol yardımcısı (bash, awk, vb) / veya deamonı (kerberostan, loggerlara kadar) programı procedural yazılması ilginçtir. C ile OO yapılıyor mu yapılıyor, fakat C ile OO temellerini atan, uğraşılmış projeler gerçekten nadir.

    Performans açısından da mesela MySQL OO, PostgreSQL procedural kurgulanmıştır (üstelik daha düzenli olduğu söylenmekte) ve bütününde performansı Postgre sağlıyor. Bu arada elbette OOP bir dil değil, fakat prosedürel yaklaşım, makinanın işlediğine daha yakın olduğu için, daha hızlıdır. Bunu şunun gibi düşünün; hiç bir code generator, araya code generator koymadan yazılan kadar -en azından- kaynak yönünden o performansı sağlayamaz. OO kullanım, insanın yaşamı işleyiş şeklinde daha yakın geldiğinden düşünülmüştür. Pek çok bilgisayar konusunda film programları çağrılan insanlar gibi gösteriyor, işleri yaparken öyle davranıyor (orada dikkat edin, programlar durumlara göre davranıyor-yani eventlara. bkz: tron, vb). Çünkü öyle anlaması kolay. Böyle düşününce objectlerin yaratılması ve böyle bir kurgunun kurulması çok normal. Zaten konuşmanın aslı, ‘en kolay’ programlama dili olarak çıkan, OO’nun uygulayıcı atası olarak söylenen smalltalk bu şekilde çıkmış. İngilizce gramerine, ve gerçek yaşam örneklerine en yakın dil diye.

    Diğer konuda da istisnalara pek inanmadığımı söylemiştim :) Windows’un yapısal sorunları, istisna olamaz. Q3′ün benzer niteliklere sahip motorlardan çok daha az kaynak yemesi, istisna olamaz. Tabii Linuxun bir windows veya macos’un yetkinliklerini içerememesi de istisna olamaz. Benim görüşüme göre tabii. Buarada quake3 ‘de enginein main coderı, John D. ‘walking compiler’ Carmack II, walking compiler demişler adama çünkü yazarken kodu hem compilerin optimizasyonu nasıl yapacağını (hataları dahil) hem de nasıl işlemciye göre çalışacağını kestirebiliyormuş, kısacası bilgisayar gibi işlemesini bilen bir adam. Procedural seçiminin de bu yüzden olduğuna eminim.

    Kendimi kesinlikle hakem tarafsızlığında görmüyorum ama ortada olmaya gelince, ortada olmak zorunda hissettiğimden değil, nitekim programlama dünyasında olunacak pek bir taraf göremiyorum. O anda elimizdekine göre yapılacak bir seçim var o kadar. Burada vs. ile başlayan yazı, aslında bir karşıtlık yazısı da değil, bu sanki “Meyveli vs. Çikolatalı” başlıklı bir yazıda, ikisinin de değerinin olduğunu, kattığı tatların üzerine gidildiği bir yazı. Hangisini yemek o an için eğlenceli olacaksa, iyi düşünüp o yenmeli diyorum o kadar :-)

11. 
    11
    ikizmaz:
    Eylül 20th, 2008 @ 11:00 am

    saygı duyarım gökçe kardeşim.
    özellikle programlama konusunda yazdıklarına cidden saygı duyarım. burada bahsettiklerim sadece kendi tecrübelerimin bana öğrettiği şeyler. kesin böyledir demiyorum, çünkü bu konuda çok iddalı değilim. yazılım deyince çok geniş uygulama alanları işin içine giriyor, herbiri ayrı uzmanlık dalı, ayrı bir derya… kuşkusuz sadece web tabanlı uygulamalar geliştiren benim gibi birisinin oop, her durumda prosedürelden üstündür diyebilmesi mümkün değil. yazdıklarım sadece benim kendi penceremden görünenler. zaten bu tür blogları da katkıda bulunmaktan çok, bilgi edinmek amacıyla takip ediyorum.

    bu arada istisnalara inanmıyorum demişsin, bundan eminmisin :). biz inansakta inanmasakta hayatın her durumunda istisnalar olabilir. programlama yaparken bile istisnaları yönetmek zorunda kalabiliyorsun :) … ele aldığımız durumda q3 ve linux un istisna olması onların başarısız birer örnek olduğu anlamına gelmez. ayrıca istisna rastlantı demekte değil ki. prosedürel programlama konusunda deha denebilecek seviyede zeka ve deneyime sahip bir yazılımcı, tabii ki bazı istisnaları ortaya koyabilir.

    ayrıntıları bir kenarıya koyarsak aslında bu konuda herkes aynı şeyi söylüyor. ihtiyacın o an için neyse ona uygun araç kullanılmalı. önemli olan bu…

    kolay gele…

12. 
    12
    Gökçe YALÇIN:
    Eylül 23rd, 2008 @ 4:30 am

    Öncelikle çok teşekkürler,

    Tabii ki istisnalar olabilir, fakat istisna yapılmak için zorlanmıştır diyorum ben, biraz da o yüzden “Drupal.org’dan kaynak kodunu indirin, orada yapılanları herhangi bir class kullanmadan yapmayı deneyin, tabii sabrınız yeterse. Gerçekten yaparsanız görmek isterim.” diye ekledim. Çıkan iş, nolursa olsun en azından görülmeye değer olacaktır, hatta büyük ihtimalle her ne kadar emek/zaman konusunda oldukça çuvallasa da performans ve sağlamlık yönünden artıları olacaktır bu çalışmanın. :-) Fakat programlama gibi özellikle performans ve işleyiş analiz araçları gelişmiş bir dalda, genel verimin toplamda önce tutulduğu iyice tartılarak girişilen bir projenin olabildiğince istisnalardan arındırılmış olduğunu zannediyorum. Tersinin ihtimali bana, bir ustanın çekiç ve ingiliz anahtarı elinin altındayken, çiviyi çakarken illa ingiliz anahtarı kullanma zorunluluğu neyse, o kadar geliyor.

    Buarada evet, istisnaları programlamada gayet iyi biliyoruz, sözünü ettiğin OO’da kurguyu kolay sağlamamıza yardımcı olan exception handler’lar da bu yüzden varlar. Buarada hatırlatma yapayım, gerçek hayattaki kurgulamaya yaklaşan OO’da bu exception handlerlar var, proceduralda yok. Proceduralda, bir iş yapılır, veya yapılmaz; birkaç nesneye yollanan imdat fişeği (throw) yoktur, olsa olsa kayıt eder. Fakat gene de programlamada istisnaları, aksilikleri sevmeyiz, bu alet denileni yapacak deriz, güvenilmez bir durumun oluşması, iş akışından çıkarak kurgunun bir ürünüdür. Nitekim bilgisayar düşünmüyor, bizim verilerimizle hareket ediyor. Nasıl olur da yanlış biyerlere sapar? Beklenmedik bir durum ortaya çıkar? Bu durumlar hiç var olmasalardı, bütünü daha “sağlam” kurgulardık, o da bir gerçek. Elektriğin hiç bir zaman kesilmediği bir ülkede fabrika kurgulamak gibi. (düşünün jenatör eklenmesinin getirdiği zorunluluklar, jenaretörün benzinin bitmesi, dünyanın petrol kaynaklarının azalması, buyrun biton istisnai durum, oysa biz ayakkabı üretecektik) Aksilikler gerçek hayata dair şeyler, her söyleneni yapan bilgisayara değil, hatta biraz bilgiçlik olacak ama gerçek hayat kurgusundan çıkan bir durum sanki; bu istisnaların genelde oluşmasının nedeni de, OO’da kurgulamada bilgisayarın aslolarak işleri nasıl yaptığıyla ilgilenilmemesi olabilir mi? Nitekim OO’da önemli olan, gerçek hayat kurgusundaki gibi iş akışıdır. İş akışında oluşan bilinmeyen ve anlaşmak için uğraşılmayan, beliren istisnaları da kurgu gereği exception handlerlara bırakıveririz, onlar halleder. Yani onlarla karşılaşmamızın nedeni var olma zorunluluklarından değil, arka plandaki işleyişle ilgilenilmemesi olasılığı bana çok uzak gelmiyor.

    İnanmıyorum derken tabii ki bu bir inanç meselesi değil, yapılmasına yapılır canım. Hatta öyle yapılmasının özel bir nedeni de olabilir. Aslında konu az da olsa yukarıdaki paragrafla benziyor. Radikal bir örnek vermek gerekirse, bir programcı PHP’de web sunucusu yapıldığını gördüğünde, “hmmm demek ki PHP ile web sunucusu yazılır” diyebilir, ama iyice araştırdığında bunun bir “istisnai” bir gerekliliğin (ki inat da bunlardan biri sayılabilir :-) ) örneği olduğunu diğer örneklerin arasında çıkaracaktır. Örnek bu kadar radikal olmayınca, hangisinin daha verimli olacağı konusu, neler kattığı ve neler kaybettiği daha saydamlaştığı için bir tartışma konusuna dönüşebiliyor, o kadar.

13. 
    13
    Erhan:
    Ocak 7th, 2009 @ 2:51 am

    Bu OOP işi gerçekten kafamı karıştırıyor. Şöyle ki;
    Ben henüz 4-5 aylık bir junior (daha altı varsa kendimi o sınıfa koyarım) php coder’ım. Bu süre zarfında bi’kaç içerik yönetimli websitesi falan yazdım kendi çapımla orantılı olarak. Sonra kesmemeye başladı, araştırıp dururken baktım millet “ağbi oop süfer” diyor. “nedir bu oop?” diye bakınırken öyle bir iki makale okudum (ie deki tabların en sonuncusu da bu sayfaydı). şimdi ben facebook kadar büyük bi proje yapmıcaksam (ki şu durumda imkansız olduğu ordan belli oluyordur) oop benim neyime? koyarım spanlar arasına php taglerimi ohh mis. ya da günlük hiti 5k olan bir site yapsam ve de kodları sadece kendim yazmış olsam yine oop benim neyime? ama kafama takılan birkaç soru var;

    *OO programlamaya dayalı kod yazdığımızda hız farkedecek mi?
    *Projenin büyüklüğü ne olursa olsun, kodları tek kişi yazıp optimize ediyorsa OOP külfet midir?

    şimdiden teşekkür ediyorum.

14. 
    14
    Gökçe YALÇIN:
    Ocak 7th, 2009 @ 5:19 pm

    •OO programlamaya dayalı kod yazdığımızda hız farkedecek mi? Evet, fakat değişimin hangi yönde olacağı hız tipine bağlı ve hesaplanması biraz hummalı. Uygulamanın kod çalıştırma performansdan bahsediyorsan, OO daha yavaştır çünkü yazıda da belirttiğim gibi, uygulama kurgusu insanın gerçek hayat problemleriyle karşılaştığı şekilde çözümüne izin verdiği için arkaplanda bir sihir sözkonusudur. Yazılan kodun tekrar procedural işlemlere çeviren programcının görmediği, sadece arkaplanda işleyen bir dönüşüm işlemi yapar, ve bu işlemci için bir extradır. Fakat, uygulamanın performansı, sadece kodunun ne kadar hızlı çalıştırıldığından öte, nasıl ve neleri kullanarak çalıştığı önemlidir. OO yazılım kurgusunu kolaylaştırdığından uygulama gelişim hızını arttırır, ve uygulamanın genişletilebilirliğini/ölçeklenebilirliğini ve bakımını kolaylaştırır. Özellikle durum bazlı (event driven) destekli diller de kurgu yardımı daha iyi anlaşılabilir – PHP tam bir OOP sunmaz.

    • Projenin büyüklüğü ne olursa olsun, kodları tek kişi yazıp optimize ediyorsa OOP külfet midir?Programcılar genelde OOP değil, procedural yazımı külfet olarak görür, nitekim kolaylıkları sağlayan OO. Büyük projelerdeki genel seçim nedeni, herşeyin düşünülmesinin zorluğu ve daha komplike sorunlarla karşılaştıkça altyapının sürekli baştan yapılmasının gerekliliği, ve maliyetin de doğal olarak düşüşü. Fakat bu demek değil ki küçük projelerde OO kullanılmaz / kullanılması doğru olmaz. Kararı vereceğiniz tek nokta projenin büyüklüğü küçüklüğü değil elinizdeki işin tipi/geleceği. Elinizdeki uygulama ne kadar büyüyebilir? Ölçeklenmesi gerekir mi? Uygulama ne kadar değişir? gibi sorular sizi doğru sonuca yaklaştıracaktır.

15. 
    15
    Erhan:
    Ocak 7th, 2009 @ 10:30 pm

    Çok teşekkür ederim yanıtlarınız için.

16. 
    16
    Delifisek:
    Ocak 11th, 2009 @ 3:53 pm

    Bence gozden kacan baska bir husus var.

    Kendimizi bir an static typing bir dilde dusunelim. Kullanacagimiz her degiskeni tek tek tanimlamamiz lazim. Dusunun bu ne kadar gicik bir istir. $i hede $n hodo. her fonksion icin yaz babam tekrar bastan yaz.

    OO yaklasimin bu kadar populer olmasinin bence en buyuk nedeni bu. Uygun sekilde patternlere baglarsan, Yeni degiskenlerin define edilmesi isinden kurtulursun, buda sana cok hizli ve pratik bir programlama yaklasimi getirir.

    Tabi zaten Compiled otamda oldugun icin, OO yuku de seni o kadar germez. Zaten baskasinin compiled edilmis kodundaki class i kafana gore alip minciklamakta baska bir guzelliktir.

    Ve fakat, web ortamina geldigin zaman hele hele elindeki dil Dynamic typing bir dil ise, tasarim shared noting ise. OO nun getirisi nedir ?

    Efendim cok daha iyi project management sagliyor. Neden ?
    Cunku OO disiplini geregi, en ufak kod blogunu dahi bir methoda bagliyoruz, bu sayede her kod block wrap edilmis oluyor, luzum oldugunda refactoru kolayca yapabiliyoruz.

    Peki efendim bunu Procedural kodda yapmanizi engelliyen nedir ?

    Ha madem ki procedural deyip koca koca kod bloklarini copy paste ediyorsaniz, efendim ne yapsin size procedural kod, degilmi ?

    Baglarsak, PHP ortaminda OO bazli yaklasimin overhead i yaklasik 4 kat fazlasidir. Ortam share nothing oldugu icin her requeste bi o objeleri tekrar bastan init ediyoruz.

    Bence PHP ve Web programciligi icin OO yaklasimi kesinlikle over enginereed bir modeldir.

    Kisisel olarak zaman icinde geldigim nokta, yazdigim buyuk kod bloklarini ve fonksiyonlari parca pincik hale getirdikten sonra bir daha onlara dokunmadigimdir.

    Bu aralar PHP OO modelini saydece public static ile kullanip, kendime virtual namespace yaratiyorum. Degiskenleride ayni sekilde init ettigimde, GLOBALS copunden kurtuluyorum. Iyi oluyor. Performanstanda memnunum.

    Paylasayim dedim…

17. 
    17
    kunthar:
    Haziran 7th, 2009 @ 11:50 am

    Bakınız;

    http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
    http://en.wikipedia.org/wiki/Functional_programming

    Kuyunun dibinden dünyaya bakan kurbağa, dünyayı, gördüğü o kuyu ağzı sanarmış…

18. 
    18
    Ramo:
    Nisan 3rd, 2010 @ 12:35 am

    Şimdi ilk önce yazlarını ilgiyle okuduğumu belirteyim.Ayrıca bu sistenin içieriğide iyi.OOP öğrenildiğinde iyi programlar yazmak için birebir hem de bu OOP mantığını kavradıktan sonra ister javada kullanın bu mantığı ister php de ister c# de değil mi?Ama elzemmi yani illa büyük projeler OOP mantığı ile mi kodlanmalıdır.Eğer programcı OOP bilmiyorsa kötü programcımıdır demodemidir.Büyük projlere başlaymaz mı, başlasad bir yerde tıkanır mı?
    Peki Unix büyük bir projemi kuşkusuz evet.İçinde ne kadar OOP ya da desig patern mantığı var sizce…(Şimid bu sorunun ardından Unix’i kullanan kaldımı diye birisi yorum yapadan öce biraz araştırsın derim)
    Bu sorular sadece kendi görüşümü paylaşmak için ve hala oop mantığını dibine kadar öğrenmeli diyorum…

    Bence MVC ile ilgili bir yazı da yazın konu iyice yadınlığa kavuşur OOP yalınlığı, anlaşılabilirliği,mantığı nedeni niçinini anlamak ve anlatmak için.

19. 
    19
    zekeriya koç:
    Ekim 9th, 2010 @ 3:40 pm

    oop için “yeni teknoloji” diyenler mi var gerçekten?

20. 
    20
    zekeriya koç:
    Ekim 9th, 2010 @ 3:42 pm

    ayrıca 20 değil hemen hemen 40-50 yıllık bir geçmişten bahsetmek lazım.

21. 
    21
    fultifaster:
    Mart 21st, 2011 @ 8:47 pm

    Object oriented programlama tabikide ihtiyaç duyulan bir yöntem bu karmaşanın cevabı ( yani projeyi oop mi yazayim yada procedurel mi yazayim? ) basitliği kullanmaktır.Mesela burada gökceninde verdiği örnekte ekrana bir hello yazdıracaksanız bunu procedürel yazmak daha mantıklıdır.kısa yoldan ve hic akla zarar kodlarla bogusmadan amacımıza ulastik ve daha okunabilir oldu.
    Ama komplex bir projede oop kullanma taraftarıyım fakat oop kullanirken de bir basitliğe ihtiyaç duyuyoruz bu basitlik hem projenin hizli olmasini sağlayacak hemde okunabilirliği arttıracak..
    Procedürel bir programcı demode midir sorusuna gelince hayır değildir demenin dısında ek bir seylerde söyleyeyim.
    Procedürel programcılar günümüzde ( uygulamada ) oop kullananlara göre daha cok amaca yönelik kod yazmaktadirlar yani bir nevi sonuca cok cabuk ve öyle akla ziyan kod yazmamaktadirlar ( programcıya göre değişir gördüğümü söylüyorum)
    Opp programcılar ise sonuctan ziyade sonucu kolaylaştıracak türde yazarlar ancak bu noktada sonucu gitmeyi kolaylaştırmaya calisirken bazı yerlerde gereksiz bir şekilde oop yi abartırlar ki bu kodu daha cok anlamsız kılar ve programı yavaşlatır.
    Dolayisiyla oop kullanmak isteyen bir programcı pek fazla kavram karmaşası yapmamalı daha doğrusu
    bağlantıları iyi kullanmalıdır.Yoksa yazılan kod ne oop dir ne de anlamlıdır.

Bir cevap bırakın

Additional comments powered by BackType

Kategoriler

• 3rd Party
• Code Igniter
• CSS
• Diğer
• Dizayn
• Eclipse
• Framework
• Frontend
• Günlük
• Güvenlik
• HTML / XHTML
• IDE
• İyileştirme / Performans
• Javascript
• Kütüphaneler
• Linux
• MySQL Spesifik
• Performans / İyileştirme
• PHP
• SQL
• Tarayıcılar
• Veritabanı
• Zend Framework

Seçilmiş İş İlanları

Etiketler