Pazartesi, Ekim 02, 2006

Programı Katmanlara Ayırma

Nesne yönelimli programlamanın temelinde yeniden kullanılabilirlik (reuseability) yatar. Yani yazılan kod parçalarının olabildiğince biribirlerinden bağımsız ve gerektiğinde yeniden kullanılabilir olması gerekir. Buna neden gerek var?

Sanayi sektöründeki en büyük gelişmelerden birisi yarımamül üretiminin yapılamya başlanmasıdır. Yarımamüller biraraya gelerek ana mamülleri oluştururlar. Mesela ayakkabı üreten bir firma için ayakkabının taban kısmı bir yarımamüldür. Aynı taban kullanılarak birçok değişik modelde ve renkte ayakkabı üretmek mümkündür. Bu sayede her model ayakkabı için ayrı bir taban tasarımı yapmaya veya ayakkabı üretimine taban üreterek başlamaya gerek kalmaz.

Yazılım sektörü de bu tür yarımamüller üretme arayışı içindedir. Mesela ticari program üreticisi bir firmanın hitap ettiği sektörlerin bir çoğunda fatura kesme özelliği vardır. Eğer fatura modülü programın diğer parçalarından bağımsız bir parça olarak tasarlandıysa yazılımevi aynı fatura modülünü birçok sektöre yönelik değişik program içinde kullanabilir. Eğer fatura modülü stok modülüne bağımlı olarak tasarlandıysa fatura modülünü kullanacağımız her yerde stok modülünü de kullanmamız gerekir. Bu durum hizmet sektörüne yönelik program yazdığımızda (bir kuaför mesela) bu fatura modülünü kullanamayacağımız anlamına gelir. Çünkü bu firmalar maldan ziyade hizmet satar ve faturaya verdiği hizmeti yazar. Kimi programlarda hizmeti stok olarak tanımlayarak çözümler aranır ancak bu durum hizmet konusunun doğasına aykırıdır. Buradaki örneğimize göre fatura modülü diğer her türlü modülden bağımsız tasarlanarak gerçek bir yarımamül haline getirilmelidir.

Aslında konuyu program modülleri olarak anlattım ancak aynı durum program için yazdığımız kodlarda da vardır. Mesela bir veri aktarma bileşenini sadece SQL Server veritabanından veri aktaracak şekilde yazarsak veri aktarma için yazdığımız kodlar SQL Server varsa işe yarar. Birgün XML dosyasından veri aktarmak gerekirse eskiden yazdığımız şeylerin birçoğunu tekrar yazmamız gerekir. Gerçek yarımamül bir veri aktarma kodu veri kaynağından ve verinin yazılacağı yerden bağımsız çalışabilmelidir.

Günümüzde yazılım fabrikası terimi git gide yaygınlaşmaktadır. Hızlı ve doğru program üretme ihtiyacına yönelik olarak ortaya çıkan bu olgu yazılım üretme şeklimizin daha verimli hale getirilmesi anlamına gelir.

Bir program 3 temel iş yapar. Kullanıcıdan bilgiyi alır, bunu işler ve veritabanına yazar. Tam tersi düşünürsek verikaynağından bilgiyi alır, bunu işler ve kullanıcıya gösterir. Modern programlamada bu üç iş biribirinden bağımsız yapılmalıdır. Yani bilgiyi işleme mantığı veritabanından ayrı olmalıdır ki biz istediğimiz herhangi bir veritabanını kullanabilelim. Ya da bilgiyi gösterme mantığı veri kaydetme mantığından ayrı olmalıdır ki biz istediğimiz şekilde kullanıcıya bunu formla veya web sayfasıyla gösterebilelim. Bu ihtiyaç 3 katmanlı yapıda program yazılmasını gerektirir. Bu üç katman sunum, iş ve kayıt katmanıdır.

  • Sunum katmanının görevi kullanıcıdan bilgi almak ve kullanıcıya bilgi göstermektir.
  • İş katmanının görevi kullanıcıdan alınan bilgi üzerinde hesaplar yapmak veya kullanıcıya gösterilecek bilgiyi anlamlı hale getirmektir.
  • Kayıt katmanının görevi bilginin verikaynağından okunması veya kaydedilmesidir.

Mesela bir müşterimiz web üzerinden sipariş almak istiyor. Bizim yapımız katmanlara ayrıldıysa, iş katmanına veya kayıt katmanına hiç dokunmadan sadece sunum katmanında değişiklik yaparız. Siparişin hesaplama ve değerlendirilme mantığı siparişin gösterilmesinden ayrı ele alındığı için bu konularda tekrardan kodlama yapmamıza gerek kalmaz.

Nesne yönelimli diller bu gibi katmanlı yapılar oluşturabileceğimiz altyapıyı ve dil özelliklerini bize sağlar. Nesne yönelimli dillerde her olgu bir nesnedir. Yukarıdaki örneğimizi düşünürsek kabaca bir sipariş, bir sipariş gösterme ve sipariş kaydetme nesnemiz vardır. Sipariş nesnesi siparişin hangi kurallara göre işlem göreceği ile ilgili işleri yapar. Sipariş nesnesinin nasıl gösterileceğini sipariş gösterme nesnesi, nasıl kaydedileceğini de sipariş kaydetme nesnesi bilir. Biz diğer nesnelere hiç dokunmadan sipariş gösterme nesnemizi gerektiğinde web sayfası gerektiğinde de bir formla çalışacak şekilde geliştirebiliriz.

Siparişleri listelediğimiz bir listemiz olduğunu düşünün. Müşterimiz sevk tarihi geçen siparişlerin kırmızı renkte gösterilmesini istemiş olsun. Hemen basitçe siparişi gösterdiğimiz grid bileşeninin uygun bir olayına (event) gideriz ve

[eger] "gününTarihi > sevkTarihi"
[ise] "fontRengi = kırmızı"
[degilse] "fontRengi = siyah";

gibi bir kod yazarız. Koda baktığımızda üstteki tarih kontrol kodunun iş mantığını, alt taraftaki renk atama kodunun da sunum mantığını ilgilendirdiğini görebiliriz. Bu durumda ne olur? Eğer bir gün siparis bilgisini başka bir yerde (mesela bir web sayfasında) göstermemiz gerekirse sevk tarihi geçmiş satırların kırmızı olması ile ilgili kodumuz gridde kalır. Büyük ihtimalle de aynı kodu tekrar yazmamız gerekir. Sipariş görünen her yere bu kodu tekrardan yazarsak ve birgün müşterimiz sevk tarihine 1 hafta kalanları mavi renkte görmek isterse siparişi gösterdiğimiz heryeri hatırlayıp değiştirmemiz gerektir.

Gördüğümüz gibi aslında nesne yönelimli programlama yapıyor olmamız bizi yavaşlatan ve zaman israfına neden olan problemlere tek başına çare değil. Nesne yönelimli diller nesnelerimizi bu sorunları yaşamayacağımız şekilde tasarlayabilmemize yardımcı oluyor. Yine doğru tasarımı yapmak bize kalıyor. Bu konuda Design Patterns gibi sık yaşanan tasarım sorunlarına çözümler üretmekle ilgili çalışmalar var. Nesne yönelimli dilllerle program yazanların bu olanaktan tam olarak faydalanabilmesi için nesne yönelimli mimariler konusunda da kendilerini geliştirmesi gerekiyor. Aslında bu konuda daha çok şey yazmak lazım. Yine zaman buldukça bunlarla ilgili yazılarıma devam edeceğim...

OOP konusuna aşina olanlar için iki kitap tavsiye ediyorum

Head First Design Patterns (Elisabeth Freeman)
Patterns of Enterprise Application Architecture (Martin Fowler)

Pazar, Ekim 01, 2006

Delphi nerede hata yaptı?

Windows işletim sisteminin yaygınlaşması ile birlikte windows için yazılmış programlar da yaygınlaşmaya başladı. İlk zamanlarda windows programları genellikle C ile Windows API (Application Programming Interface) arabirimi üzerinden yazılıyordu. Windows API programcılara büyük kolaylıklar getiren bir arabirimdi ama yine de windows için program yazmak kolay bir iş değildi. Microsoft Visual Basic ürününü çıkarana kadar windows programcılığı fazla yaygınlaşamadı, yazılan programlar da belli bir kapsamı aşamadı.

Formlar ve bileşenler kulllanarak program geliştirme yönteminin ilk atası Visual Basic'dir. Bu dönemde dilin haricinde başka görsel unsurlar da kullanılarak yapılan programlama şekline RAD(rapid application development) programcıya da geliştirici (developer) denmeye başlandı. Bu dönemde c++, smalltalk gibi nesne yönelimli programlama dilleri olmasına rağmen Visual Basic (VB) nesne yönelimli (object oriented) bir dil değildi ancak windows için program yazma işini çok basitleştirmişti. Program yazma şekli de daha çok prosedürel programlamaya benzediği ve o dönemde nesne yönelimli diller çok yaygınlaşmadığı için VB hızlı bir şekilde yaygınlaştı. Bu sahnede Microsoft daha fazla tek başına kalamadı. Önemli bir rakibi efsane Borlan Pascal'ın üreticisi Borland'dı.

Borland Pascal 7 paketi ile birlikte iki ürün daha geliyordu. Bunlar Turbo Vision ve Pascal for Windows idi. Pascal for Windows Pascal dili ile (bugün delphi ile program yazarken kullandığımız dil) windows programlarının yazılabilmesini sağlıyordu ancak VB gibi basit bir görsel tasarım aracı yoktu. Turbo Vision ise DOS programlarının daha basitçe yazılabilmesini sağlayan bir araçtı. Eğer windows programları gibi köşesinden tıklanarak kapatılabilen pencereleri olan, combobox, textbox gibi özellikler içeren ve mouse ile kullanılabilen bir DOS programı gördüyseniz bu büyük ihtimalle Turbo Vision ile yazılmıştır.

Bu ürünlerin varlığı Borland'ın elinde tamamen nesne yönelimli bir windows programlama aracı çıkaracak birikim olduğunu gösteriyor ama Borland prosedürel programlama ile nesne yönelimli programlama arasında bir orta yol üreterek Delphi ürününü çıkardı. Sanırım o dönemde prosedürel programlamaya da olanak sağlanması ticari bir karardı. Bu durum bir anlamda OOP temeli üzerine Prosedürel programlama yapılması anlamına geldi. Delphi programıcları bilirler. Eğer VCL'e ek bir bileşen yazmaya kalkarsanız yapmanız gerekenler ve düşünme şekliniz normal program yazarkenkinden çok farklıdır. Bu Delphi nin iki paradigmayı da barındırmasından kaynaklanır. VCL OOP temeli üzerine kurulduğu için VCL'e yapacağınız eklentileri nesne yönelimli kurallara göre yapmalısınız. Bileşen işine hiç girmeden program yazıyorsanız OOP'den anlamanıza gerek yoktur.

Önemli bir gelişme JAVA dilinin ortaya çıkmasıyla yaşandı. JAVA, VB ve Delphi den farklı olarak %100 nesne yönelimli bir programlama diliydi ve OOP ile windows programcılığını başarıyla biraraya getirmişti. Tabii JAVA ile yazılan programların windows haricinde Linux gibi windows dışı platformlarda da çalışabilmesi büyük bir avantajdı. JAVA bir anda dünyanın en çok kullanılan programlama dili haline geldi ve Microsoft ile Borland bu gelişmeye farklı tepkiler verdiler.

Microsoft'un Java'nın temel başarısının OOP temelli olması olduğunu düşünerek .NET altyapısı ve C# dili ile cevap verdi. .NET platformu %100 nesne yönelimlidir ama (multiplatform desteği olmasına ve Mono gibi Linux desteği olan projelere rağmen) resmi olarak Linux'da çalışmıyor.

Borland ise Java'nın temel başarısının Linux ile çalışması olduğunu düşünerek %100 nesne yönelimli olmayan ama Linux için program yazılabilmesini sağlayan Kylix ile cevap verdi. Sonradan Kylix'i piyasadan kaldırdı ve kaçan treni yakalayabilmek için .NET desteği olan Delphi2005 ürününü çıkardı ancak zamanında Delphi ile yapabileceklerini yapmakta çok geç kaldığı için istediğini bir türlü alamadı. Aslında bir zaman Borland bu gidişatı sezerek CORBA gibi çözümleri Delphi'ye entegre etmiş hatta şirketin de ismini Inspire olarak değiştirmişti. Daha sonraları Delphi ile birlikte DUnit ve ModelMaker gibi nesne yönelimli programlamaya hitap eden ürünler de gelmeye başladı ama bunlar Delphi programcılarının varlığını bildiği ama kullanmayı hiç düşünmediği ürünler olarak kaldı. Belkide asıl değişmesi gereken Delphi'nin hem prosedürel hem de nesne yönelimli program yazmaya imkan tanıyan yapısıydı.

Turbo Pascal ve Delphi dilinin yaratıcısı Anders Hejlsberg 1996 yılında Microsoft tarafından transfer edilmişti. Daha sonra Anders Hejlsberg Microsoft'ta J++, MFC ve C# ürünlerinin baş mimarlığını yapmıştır. Mutlaka Borland'da çok yetenekli mühendisler çalışmaktadır ancak bu transferin Delphi dilinin gelişimini nasıl etkilediği üzerinde düşünülmesi gerekir. Bu günlerde Borland'ın uygulama geliştirme ürünlerinin tamamını satacağı ve proje yönetimi ürünleri üzerine yoğunlaşacağı konuşulmaktadır.

Perşembe, Eylül 28, 2006

UML Nedir?

Bir inşaat mühendisi bina inşaatına pat diye başlamaz. Belki beyninde hiç yardımsız bina inşaatı yapacak kadar bilgi vardır ama yine de bina tasarlama konusunda eğitim almış deneyimli mimarlardan yardım almak daha akıllıcadır. Mimar ile inşaat mühendisi arasında belki hiç konuşma dahi olmayacaktır ama mühendisin yaptığı bina tam olarak mimarın düşündüğü şekilde olacaktır. Aradaki iletişimi proje denilen araç sağlayacaktır. O projenin üzerine konulan her işaretin bir anlamı, her sayının açıkladığı bir bilgi vardır. Alman mühendis Japon mimarın çizdiği projeyi eksiksiz yapabilir çünkü konuştukları dil inşaatcadır. Bir inşaat projesindeki şekillerin neyi ifade ettiğini bilen bir kişi o inşaatla ilgili her detayı görebilir. Hatta bu inşaata ne kadar malzeme gideceğini dahi hesaplayabilir. İnşaatın maliyetini çıkarabilir. Bir bina tasarımını hiç şekil kullanmadan sadece yazıyla ifade etmeye çalışsak çok şey yazmak gerekir. Hatta bunu da yapmadan sadece anlatarak çözmeye çalışsak ne kadar başarılı olabiliriz? Bazen basit bir şekil sayfalarca dökümandan daha açıklayıcı olabilir.

Aslında çok eski zamanlardan beri yazılım dünyasında da birçok simgesel tasarım aracı kullanılmış ancak evrensel anlamda kabul görmüş bir standart oluşmadığı için çok yaygınlaşmamıştı. Bu ihtiyacı gören OMG konuya el attı ve varolan standartları birleştirerek UML (Birleşik Modelleme Dili) standartlarını yayınladı.

UML bir yazılım tasarımının diyagramlarla açıklanması için kullanılan bir araçtır. Kodlama yapmaya gerek kalmadan sistemin genelinin veya bir parçasının tasarımını bu yolla gösterebilmek mümkündür. Analist, tasarımcı ve programcılar arasında iletişim kurmak için kullanılabilecek iyi bir araçtır. İnşaat projelerinden farklı olarak yazılım projeleri ihtiyaçlara paralel olarak üretimi boyunca sıkça değişir. Bu nedenle yazılım üretme metodları bu sık değişikliklere cevap verecek şekilde döngüsel bir mantıkla işleyecek şekilde tasarlanmıştır. Klasik bir yazılım döngüsü kabaca gereksinim belirleme, analiz / tasarım, kodlama ve test aşamalarından oluşur. Bu döngü 1 hafta - 1 ay arasında değişen bir süreyi kapsar. Son aşama tamamlandıktan sonra tekrar başa dönülür. Bu süreç böylece devam eder. Her döngü başlı başına bir proje olarak da kabul edilebilir. UML bu aşamaların herbirine hitap eden farklı diyagram çeşitleri içerir. Örneğin gereksinim belirleme (bir diğer deyişle müşteriden istekleri alma) aşamasında Use Case (vaka veya kullanım durumu olarak çevirenler var) diyagramı veya tasarım aşamasında sınıf diyagramları ve etkileşim diyagramları kullanılır. Sınıf diyagramı bir sınıfın yapısını, etkileşim diyagramları ise sınıfların çalışma esnasında biribirleriyle olan iletişimlerini gösterir. Bir programcının modellenmiş bir gereksinimi kodlaması hem zaman kazancı sağlar hem de olası hataların önüne geçilmesine yardımcı olur. Aslında programın her parçasını UML ile modellemeye gayret etmiş firmalar da vardır ama bu kadar kapsamlı bir çalışma içine girmenin ne kadar faydalı olduğu hala günümüzde süregelen bir tartışma konusudur. UML diyagramlarını basit bir iletişim aracı olarak algılamak amaçsız bir şekilde herşeyi diyagrama çevirmeye çalışmaktan çok daha iyidir.

Programımız nesne tabanlı bir dille yazılmıyorsa da kullanabileceğimiz UML diyagramları vardır ama asıl olarak UML nesne tabanlı diller düşünülerek tasarlanmıştır. Eğer nesne tabanlı programlama konusunda yeterince bilgili değilsek önce o konuyu öğrenmemiz daha faydalı olacaktır. UML ile ilgili Martin Fowler'in UML Distilled kitabının 3. sürümünü önerebilirim. Aynı kitabın 2. sürümünün Türkçe çevirisi de var. Ancak Türkçe kaynak aranıyorsa Bora Güngören'in UML ile Nesne Tabanlı Çözümleme ve Tasarım kitabı bence daha derli toplu ve faydalı bir kitap. UML dilinin kullanımının yanı sıra yazılım mühendisliğinin önemli ve genellikle zor anlaşılan konularından da işin pratiğine yönelik eğlenceli örneklerle bahsetmiş. Ayrıca nesne yönelimli programlama (OOP) bilmeyenleri de düşünerek kitaba nesne yönelimli programlamaya giriş yaparak başlamış.

Hazır yeri gelmişken bir konuya daha değineyim. Yukarıda yazılım üretimi döngüsünü anlatırken bahsettiğim gibi, program yazma işi sırf kodlama işi değil. İşin mühendisliği ve sosyal bir boyutu da var. Kodlama aşaması, üzerinde uzmanlaşılması gereken temel aşamalardan sadece birisi. İşini ciddi yapan yazılımevlerini bir kenara ayırırsak genelde işin kodlama haricindeki kısmı önemsenmez veya çok yüzeysel uygulanır. Bunun en büyük nedeni iyi kodcunun iyi program yazmak için yeterli olacağıyla ilgili yanlış bir görüş olması ve eğitim eksikliği. Bunları kitap okumadan öğrenmek pek mümkün değil. Bu konularda Türkçe kitap pek yok. Genellikle program yazarken kullandığımız araçları öğreten kitaplar yazılmış. Bunların birçoğu da çeviri. Kodlama bilgisi elbette gerekli ancak analiz, tasarım, test, üretim metodolojileri, kalite güvence gibi konularla ilgili daha çok Türkçe kitap görmek istiyorum. Tabiiki bize düşen orjinal kitap satın alarak yazarlara destek olmak ve yenilerinin yazılması için bu potansiyele sahip kişileri teşfik etmek.

Çarşamba, Eylül 27, 2006

Canon EOS 400D



Canon $1000 altı SLR konseptine yeni bir ürün daha ekledi. 400D yeni birçok özellik içeriyor. 350D'den sonra 400D ile gelen önemli yenilikleri şöyle özetleyebiliriz.


  • 10 Megapixel çözünürlüğe ulaşılmış.

  • Ultra-Sonic titreşim özelliği marifetiyle ayna temizliği yapabiliyor ve artık toz taneciği derdinden kurtuluyoruz. Ayrıca bazı hassas parçalar antistatik malzemeyle kaplanmış.

  • Otomatik fokus noktası sayısı 7'den 9'a çıkmış ve artık 30D modelindeki gibi diamond diziliminde.

  • Seri çekim hızı artmış.

  • Küçük LCD panel kaldırılmış ve hem bilgi alma, hem de önizleme için tek ve daha büyük bir LCD panel kullanılmış.
  • Dış tasarımda ve menülerde bazı yenilikler yapılmış.

Aslında Rebel serisi kullanıcılarının ısrarla beklediği özelliklere hala yer verilmemiş ama yine de Canon iyi bir ürün çıkarmış bence. Yurtdışı fiyatı $899 gibi bir rakam. Tabii Türkiye satış fiyatı ne olur, $1000 altında kalır mı bilemiyorum. KDV vesair de ekleyince aksesuarlı paket fiyatları 2000 YTL'ye yaklaşır diye tahmin ediyorum. Belki bu ürün 350D'nin fiyatını düşürürse 350D modelini almak da iyi bir tercih olabilir.

Makinenin özellikleri ile ilgili detaylı bir inceleme http://www.dpreview.com/articles/canoneos400d/ adresinde...

Salı, Eylül 26, 2006

Lego Mindstorms NXT


Lego'nun bildiğimiz lego parçaları ile tasarlanan ve bilgisayarla programlanabilen robot tasarım seti yeni sürümü ile piyasada. Yenilikleri şöyle kabaca bir incelediğimde eski pakete göre en büyük fark NXT adı verilen programlanabilir kontrolcüde. Eski 8 bitlik mikroişlemci 32 bite terfi etmiş ve üzerine güzel bir programlanabilir LCD Panel eklenmiş. Bluetooth iletişime izin vermesi ve hızlı USB arabirimi kullanması da artı özellikler. Eski paketteki ışık ve dokunma sensörlerine ek olarak mesafe algılayıcı bir ultrasonic sensör ve ses algılayabilen bir sensör daha eklenmiş. Bunların dışında farklı amaçlara yönelik bazı 3. parti sensörlerin de üretilebileceği söyleniyor. Servo motor sayıları 2'den 3'e çıkarılmış. Motorlar ve bazı parça tasarımlarında da görsel faklılıklar var. Yeni tasarımlı parçalar değişik robot tasarımlarına imkan vermekte. Robot kol gibi tasarımlarda ihtiyaç olabilecek bazı ek parçalara da yer verilmiş. Ayrıca eski pakette olduğu gibi robotu programlamak kontrol etmek için Microsoft'un robotics platformu ve Visual Studio 2005 kullanılabiliyor. Yani tasarladığınız robotu kontrol etmek için C# veya VB.Net ile programlar yazabiliyorsunuz. Web sitesini biraz incelediğimde yaratıcı beyinlerin yumurta yazıcısı, sms atan, tic tac toe oynayabilen robot, hatta analog saat gibi değişik tasarımlar yaptıklarını gördüm. Gerçekten bu kutuyla yapılabilecekler sadece hayalgücüyle sınırlı. Kendi tasarladığınız robotu programlayıp bir iş yaptırabildiğinizi görmek gerçekten apayrı bir zevk. Türkiye'de henüz satışa sunulmadı ama bazı yerli açık arttırma sitelerinde 800-900 YTL arasına bir fiyatla satıldığını gördüm. Ürünü incelemek ve onlarca değişik robot tasarımlarını görmek için http://mindstorms.lego.com adresini ziyaret etmeniz yeterli. Ayrıca Microsoft'un robotik sayfalarına da http://msdn.microsoft.com/robotics/ adresinden erişebilirsiniz.

Cuma, Eylül 01, 2006

Paradigma Kayması.

Eğer programımız bellirli bir işi defalarca yapıyorsa, her seferinde aynı kodları tekrar tekrar yazmak istemeyiz. Bu nedenle programımızı belli bir düzende mantıklı parçalara böleriz ve bu parçaları yine belli bir düzende biraraya getirerek programı inşa ederiz. Oluşturabileceğimiz parçalar ve bunların birarada çalışma şekilleri kullandığımız dilin yapısal özelliklerine göre farklılıklar gösterir. Kullandığımız dilin özellikleri belli bir kişisel anlayış geliştirmemize neden olur. Bu anlayışa programlama paradigması denir.

Yazılım teknolojisinde yaşanan gelişmeler neticesinde programlama dillerinde bazı yenilikler olur. Eğer değişiklikler eski yapıdan yeterince farklıysa belli bir tarzda düşünmeye alışmış programcılar bu alışkanlıklarını değiştirmek ve yeni anlayışa uyum sağlamak zorunda kalırlar. Bu değişime paradigma kayması denir.

Örneğin düz vitesli araba kullanmaya alışan bir sürücü otomatik vitesli araba kullanmaya başlarsa sürücünün yeni duruma alışabilmesi için bir uyum dönemi yaşaması gerekir. Bu dönem boyunca sürücü hayali vites atabilir, ayağı olmayan debriyaja basmaya çalışabilir. Eski alışkanlıkların tamamen ortadan kalkma süresi kişiden kişiye değişir. Yapıları farklı diller arasında geçiş yapığımızda biz programcılar da buna benzer şeyler yaşarız.

Örneğin Basic dili

  • GW-Basic => Sequential Programming
  • Quick Basic => Procedural Programming
  • Visual Basic => Event Driven Programming
  • Visual Basic.NET => Object Oriented Programming
şeklinde listeleyebileceğimiz yapısal değişiklikler yaşamıştır. Bu dillerden birini bilen ve diğer dile geçiş yapmayı düşünen programcının her ne kadar hepsi de basic temelli olsa da program yazma şeklini değiştirmesini gerekir. Prosedürel yapıdaki bir programlama dilinde programcı programı zihninde prosedürlerden oluşan bir bütün olarak hayal eder ve yaşanılan sıkıntılara bu çerçevede çözümler arar. Halbuki nesne yönelimli (Object Oriented) bir programlama dilinde program prosedürlerden değil nesnelerden oluşmaktadır. Programcının yazdığı programı artık prosedürler bütünü olarak değil nesneler bütünü olarak görmeye başlaması sürecin tamamlandığını gösterir.

Günümüzde birçok Delphi ve Visual Basic programcısı programlarını formlar, bileşenler ve tablolardan oluşan bir bütün olarak düşünürler. Delphi 2005 veya .Net dillerinden birine geçiş yaptıklarında da aynı alışkanlıklarını devam ettiririler. Şunu iyi anlamamız gerekir. Bu diller ticari ürünlerdir. Üreticileri bu ürünleri yaygınlaştırmak ve herkesin program yazabilmesini sağlamak için ürünlerine birçok kolaylık ekler. Bu kolaylıklar bizim daha hızlı program yazmamızı sağlıyor gibi görünse de Nesne Yönelimli programlamanın birçok önemli prensibine aykırı programlar yazmamıza neden olur. Kısacası önceden pratik olarak gördüğümüz bazı şeyler programımızın kapsamı büyüdükçe ayağımıza dolanmaya ve bize zaman kaybettirmeye başlar. Bir dilin nesne yönelimli olmasının bize ne artılar kazandıracağını iyi öğrenmemiz gerekir. Bunu anladığımız zaman ihtiyacımız olan Paradigma Kaymasını tam olarak yaşamışız demektir.