Java Günlüğüm
Yazılım, Java, BT, azıcık felsefe, biraz mizah...
  • Udemy Eğitimleri
  • Temiz Kod
  • Tasarım Kalıpları
  • Hakkımda
  • Arşiv
RSS
28 Nisan 2012

Eğitim şart mı? BT’de Mesleki Eğitim Üzerine

Akin BT, Kültür, Bilgi ve Düşünce Eğitim, teknik eğitim

Mesleki eğitim (professional/vocational training), kurumların sadece İnsan Kaynakları bölümlerinin değil aynı zamanda eğitim alacak kişilerin çalıştığı bölümlerin de sorumluluk alanına giren ve verimli bir şekilde halli hiç de sanıldığı kadar kolay olmayan bir iştir. Bu yazıda verimli bir mesleki eğitimin sahip olması gereken niteliklerinden ve uzunca bir süredir içinde bulunduğum, ülkemizdeki kurumsal Bilişim Teknolojileri (BT) eğitim sektöründen bahsetmek istiyorum.

Her ne kadar İngilizce’deki “education” ve “training” kelimeleri dilimize aynı sözcükle, “eğitim” olarak çevrilse de, aslında ikisi az-çok farklı kavramlardır. Bu konudaki yayınlarda, bu iki kavrama bir de “farkındalık” (awareness) eklenir ve bu üç kavram ile aslında birbirlerini takip eden ama gittikçe daha geniş ve karmaşık hale gelen zihni süreçler ifade edilir. Bu şekilde bir yaklaşımla başladığımızda, farkındalık, kişinin dikkatini çekme, bir olayın, problemin varlığından haberdar etme gibi anlamlar taşır. “Training” ise daha çok, kişiye belli bir işi yapacak şekilde yetkinlik kazandırma ya da onu bir konuda daha verimli hale getirme, olarak tanımlanabilir. “Education” anlamında eğitim ile daha tabi ve zaman yayılmış ve daha karmaşık süreçler kastedilir. Bu anlamda eğitim, kişiye sadece teknik yetkinlik kazandırmaz, o konudaki yaygın bilgi birikimini (body of knowledge) sunar ve eğitimi alan bireyi, konunun sosyal, kişisel vs. boyutları hakkında düşünmeye sevkeder. Karışıklığın önüne geçmek için mesleki eğitim olarak çevrilebilecek olan “training” ya da “professional/vocational training”, çerçevesi çok daha dar olarak belirlenmiş bir konuda, kişilere hızlıca teknik problem çözme kabiliyeti kazandırmayı hedefler. Buna karşılık eğitim ise kişiyi düşünmeye sevkeder ve düşünme için malzemeler sunar. Bu anlamda eğitim, daha çok bir gelişme/geliştirme yani olgunlaşma/olgunlaştırma sürecidir ve bu yüzden de evrimseldir. Dolayısıyla mesleki eğitim daha çok pratik ve uygulamalı olurken, eğitim, hem teorik bilgiyi hem de pratik uygulama becerisini kazandırmayı hedefler. Bu iki kavram arasındaki farkı sanırım en iyi anlatan, Tony Bray’ın “The Training Design Manual” isimli kitabının 35. sayfasında verdiği örnektir. Yazar, kendimizi henüz orta öğretime devam eden bir çocuk sahibi ebeveyn olarak düşünmemizi istiyor ve şu soruyu soruyor: Çocuğunuzun okulda cinsel konularla alakalı “education” mı yoksa “training” mi almasını isterdiniz? Çocuğunuza cinsel “education” yerine cinsel “training” verilmesi durumunda çok farklı tepki vereceğinizi söylüyor yazar. Bu güzel örnek aradaki farkı tamamen açıklıyor.

Biz bu ayrımdan sonra mesleki eğitime odaklanalım ve yazının kalanında eğitim deyince “training”i kastettiğimizi ifade edelim.

Eğitim, kurumlar açısından çok merkezi bir kavram tabiki. İster organizasyon teorileri ve örneğin Öğrenen Organizasyon (Learning Organization) açısından bakın ister Toplam Kalite Yönetimi, TKY (Total Quality Management, TQM) gibi daha sistemli bir noktadan bakın, isterseniz çok daha pratik açıdan bakıp, daha verimli ve üretken çalışanlara sahip olmayı isteyin ya da yeni bir teknolojie geçişten dolayı tamamen zorunluluk olarak görün, eğitim çok önemli. Biz bu gibi durumlarda, genelde gülümseyerek “eğitim şart” deriz; çünkü bu cümle en önemli sloganlarımızdandır.

Uzunca bir süredir BT eğitimleri ile ilgilendiğim ve ciddi miktarda Java ve Yazılım Mühendisliği’nin değişik konularında eğitimler ve eğitim ile ilgili danışmanlıklar verdiğim için (ve dahi ilköğretimde, lisede ve üniversitede, yurt içinde ve dışında eğitim alan çocukların babası da olduğum için, yani eğitime tonla para harcadığım için 🙂 gerek “education” gerek ise) “training” anlamında eğitimin pek çok farklı açısıyla ilgileniyorum.

Kurumlar çalışanlarını eğitirler ya da dış eğitim kurumlarından eğitim aldırırlar. Bunu hangi amaçlarla yaparlar? En genelde, şu ya da bu çapta, ama bir şekilde bir “değişim” ihtiyacına cevap olarak eğitim gündeme gelir. En azından değişimle, çalışanın yetkinliklerinde bir değişim hedeflenir. Peki nedir yetkinlik (competence)? Yetkinliğin ne olduğu ile ilgili detay tartışmalara girmeden, konumuz açısından son derece faydalı olan bir tanımından yola çıkarak, teknik eğitimlerin, yetkinlik geliştirmedeki rolüne odaklanabiliriz.

Yetkinlik, kişinin bir konudaki, bilgi, beceri ve davranış ve tutumlarının tamamına verilen isimdir. Yani bir konuda yetkin olmak ya da yetkinlik sahibi olmak, o konuda gerekli teorik bilgiyi bilmek, o konun gerektirdiği yapabilime becerilerine sahip olmak ve bu beceriyi, ihtiyaç olan her noktada yapıcı bir şekilde kullanabilmektir. İngilizce’de knowledge, skill ve attitude/behavior olarak ifade edilir ve genelde KSA olarak kısaltılır. Bu tanım, sosyal ya da psikolojik açıdan çok yeterli olmayabilir, yani örneğin “aşk” konusuna uygulamada çok aydınlatıcı olmayabilir ama bizlerin de içinde bulunduğu teknik konularda güzel bir modeldir. Bilgi/beceri/davranış yani BBD’den oluşan yetkinlik kavramını bir örnekle açıklayalım: Diyelim ki çocuğunuza ya da yeğeninize diş firçalamayı öğretmek istiyorsunuz. Aslında derdiniz sadece “öğretmek” değil, derdiniz, ona bu konuda yetkinlik kazandırmak yani onu diş fırçalamada yetkin hale getirmektir. Nasıl yaparsınız bunu? Öncelikle onunla konuşarak, diş fırçalamanın gerekliliğini ve bu konudaki en temel bilgileri verirsiniz ki bu yetkinliğin “bilgi” kısmına karşılık gelir. Yeterli midir? Tabi ki hayır, çünkü eğittiğiniz kişiye bu konuda bir beceri de kazandırmanız lazımdır. Bunun için onunla birlikte banyoya gider ve ona diş fırçalamada, hem kendiniz yaparak hem de onun yapmasını sağlayarak, bir beceri sağlarsınız. Macunu nasıl sıkacağını, fırçayı dişleri üzerinde nasıl hareket ettireceğini ve sonunda ağzını nasıl çalkalayıp temizleyeceğini hem siz yaparsınız hem de onun bir kere yapmasını sağlarsınız. Dişini bir kere hatasız fırçalayabilen çocuk, bu konudaki gerekli beceriyi de kazanmış demektir. Yeter mi sizce? Yetmez tabi ki. Çünkü önemli olan şey, nihayetinde çocuğun bu beceriyi, hayatına yayması, onu bir alışkanlık haline getirmesi, mesela yatmadan önce ya da yemeklerden sonra dişlerini fırçalamasıdır. Yani, bu beceriyi sürekli bir davranış olarak hayatına yayması ve bunu yaparken de olumlu bir tutum takınmasını beklersiniz. Yani çocuk, dişlerini isteyerek fırçalamalı, bunu temiz bir insan olmanın bir parçası olarak algılamalı vs. Bu da yetkinliğin tutum, motivasyon vb. boyutunu oluşturur.

Şimdi de isterseniz BBD anlamındaki yetkinliği, örneğin bir programcının birim testi (unit test) yetkinliği açısından açıklayalım. Programcıya, daha kaliteli kod yazabilmesinin birim testi yapmaktan nasıl geçtiğinin açıklanması ve programcının bu konuda ikna edilmesi, kullanılan teknolojiye göre birim testinin bileşenlerinin varsa araçlarının, test kodunun yazımının, etiketlerinin (tag) ve örneğin konfigürasyonun, derleme ve çalışma zamanlarının, yani tüm sürecin bileşenleriyle sistematik olarak açıklanması, bilgilendirme sürecini oluşturur. Bu sırada eğer bu yetkinlik teknik bir eğitimle kazandırılıyorsa, eğitmen, muhtemelen “Selam” gibi basit bir kod parçasından başlayarak birkaç farklı karmaşıklıktaki kod için kendi örneklerini çalıştırır ve benzer şekilde sınıftaki katılımcıların da bunu yapmalarını ister. Bu örneklerle katılımcılar yetkinliğin bilgi kısmını halledip yavaş yavaş beceri kısmına doğru ilerlerler. Sonrasında eğitmen, örneklere benzer uygulamaları, katılımcıların kendilerinin yapmasını ister. Yetkinliğin karmaşıklık seviyesine göre bu, bazen sınıfça, eğitmenin önderliğinde yapılır ve katılımcılar önce taklit ederler ve sonrasında kendileri, eğitmeni takip etmeden kendi uygulamalarını gerçekleştirirler. Böylece her katılımcı birim testi için gerekli beceriyi en az bir defa sınfta göstermiş olur. Peki, bir programcının kaliteli kod yazabilmesi için yeterli midir bu yetkinlik? Kesinlike hayır. Programcı, her yazdığı kod için birim testini uygulamalı, bu konuda yapıcı bir tutum geliştirmeli, mesela etrafına da yaymalı vs. ki bu konuda bir davranış ve alışkanlık geliştirmiş olsun.

Şimdi soru şu: Yetkinlik kazandırmak amacıyla çalışanlarımıza aldırdığımız eğitimden ne bekliyoruz? Yani bir eğitimden, örneğin, başka bir programlama dilinde tecrübeli programcıları, Java ile nesne-merkezli programlama yetkinliklerini kazandırmak amacıyla göndereceğimiz bir eğitimden, yukarıda detaylandırdığımız BBD anlamında ne bekliyoruz? Benim acizane cevabım şu: Hiç bir fikrimiz yok 🙁 Bu güne kadar, BT eğitimlerinde ne İK bölümlerinin ne de teknik bölümlerin, böyle bir eğitimden ne beklediklerini analitik ve rasyonel bir çerçevede açıklayabildiklerine malesef şahit olamadım. Genelde IK birimlerinin de olduğu eğitim ihtiyaç analizi toplantılarında, yukarıdaki BBD cinsinden açıklamayı ben yapıyorum 🙂 Bırakın yatırımın geri dönüşü (ROI) gibi teknik ve çok daha karmaşık ölçümleri, eğitimden gelen kişiden, eğitim sonrasında ne isteyebileceğimizi, istediğimiz şeyi ne kadar sürede ve ne kalitede yapacağını bile tahmin etmekten çok uzakız. Komik ama gerçek bu 🙂 Bir kurum, çalışanlarını eğitime gönderir de, eğitimden döndüklerinde ne durumda olacaklarını bilmez mi? Örneğin 5 günlük bir “Java’ya Giriş” isimli eğitimden sonra BBD anlamında bir programcının ne durumda olacağını bilmez mi? Bilmiyorsa, en azından bilene, mesela bana sormaz mı? Ya da sormadan anlattığımda ona göre davranmaz mı? Cevap, hiçbirini yapmaz. Sonra da “Eğitim Şart”ı dilimize pelesenk yaparız. Gıcığım ben bu slogana zaten. Sadece slogan cünkü, içi boş, lafı güzaf malesef. Neden böyle diyorum? Çünkü, ister kelli felli o kurumsal (!) BT kurumlarının ya da devasa BT bölümlerinin olsun ister ufak yazılım evlerinin olsun, eğitim ihtiyaçlarında hep aynı sıkıntıyı çekiyorum. Bir örnekle açıklayayım ama sıkı durun: Cok sık bir şekilde örneğin Cobol ya da Oracle Forms gibi yapılarla senelerini harcamış, bazen benden daha yaşlı programcılara 3 ya da 4 günde Java ile nesne-merkezli programlama öğretmem bekleniyor 🙂 Yani, Java’nın nasıl tanım tabanlı (specification-based) ve açık yapıda bir dil olduğundan başlayarak (ki burası çok önemlidir çünkü Java kültürünün çok temel bir parçasıdır ve genelde farklı programlama kültüründen gelenlerin anlamakta zorlandıkları ve bu yüzden de “Hangi Java’yı öğreteceksiniz” şeklinde sorular sordukları bir alandır bu), söz dizimi ve anahtar kelimelerini, kontrol yapılarını ve sonra gelen, pek çok programlama kültürüne göre Java’nın en ayırt edici yönünün ele alındığı sınıf ve nesne yapıları, sonrasında kalıtım, çok şekillilik, soyut yapılar ve arayüzler ve sonrasında sıra dışı durumlar ile temel Java yapılarının halledilip, üzerine torbalar, giriş-çıkış, kanallar ve JDBC’nin ele alınması ve bu konularda bir yetkinlik oluşturmak için 3 olmadı 4 gün, nasıl? 🙂 Ve bu konuları gören katılımcıların, bir projede yer almaları, kendilerine verilen programlama görevlerini yerine getirmeleri yani “yetkin” olmaları bekleniyor. Sonra da herkes birbirine soruyor, proje neden gecikti? Ya da Java’nın adı çıkıyor, “Java çok zor” ya da “Java’da kod geliştirmek çok yavaş” 🙂 Şaka gibi…

Peki, yukarıdaki konuları kapsayan bir eğitim, ne kadar sürede nasıl bir yetkinlik kazandırabilir? Bu konularla ilgili gerekli bilgi için rahatlıkla 5 güne ihtiyaç vardır. Eğer eğitimde bilgiden beceriye de geçmek istiyorsak ki tabi olan budur, katılımcıların, eğitmenin bilgilendirirken verdiği örneklere benzer örnekleri yapmaları gereklidir ve bu durumda böyle bir eğitim rahatlıkla 10 güne çıkar. Burada dikkat çekilmesi gereken şey, böyle bir eğitimde beceriyi her konuda kazanmanın mümkün olmadığıdır. Sınıfta katılımcıların ne kadar kendi uygulamalarını yapabileceklerini belrileyen en temel şeylerden birisi, sınıfın mevcududur örneğin. Katılımcıların hangi konularda kendi uygulamalarını yapacakları, hangi konularda eğitmenin örnekleriyle yetinip, örneğin eğitim sonrası kendi gayretleriyle beceri kazanmaya yönelik olarak kendi uygulamalarını yapacaklarını belirlemek çok önemlidir.  Ama kesin olan şey şudur ki, 10 günlük böyle bir eğitimde bile katılımcılar, eğitmenin örneklerinin çok iyimser bir tahminle, yaklaşık 3’te birinde kendi uygulamalarını yapabilmektedirler. Burada şunu atlamamalıyız: İster bilgi tarafı ister beceri tarafı olsun, aslolan anlamadır, yani katılımcının anlamasıdır ve katılımcının örnek uygulamayı yapmış olması bile onun konunun her yönünü anladığını göstermez, çünkü burada “training” anlamında bir eğitimden bahsediyoruz. Yani örneğin neden “Java’da mesela kanal yapısı böyle kurgulanmış da .NET’deki gibi şöyle kurgulanmamış” sorusu nefis bir tartışma konusu olmakla birlikte, “training” anlamında bir eğitimin konusu olamaz. Bu olsa olsa, Programlama Dilleri isimli bir master dersinin konusu olabilir ki bu da zaten “education” anlamında bir eğitimle halledilir.

Davranışa gelirsek, sınıf içi eğitimle, yetkinliğin, davranış kısmını kazandırmanın mümkün olmadığını ifade etmek gerekir. Yani sınıf içi eğitim, davranış kazandırmaz, bu çok açık. Peki davranış, tutum nasıl kazandırılır? Tabi ki eğitimin bir parçası olarak ama sınıf eğitiminden sonra yapılacak bir workshop ile davranış kazandırmaya başlarsınız. Yani alınan eğitime uygun içerikte, örneğin 5 günlük bir sürede yapılacak küçük bir proje çalışması ile katılımcılar, bilgilerini kullanma imkanı bulurlar, becerilerini geliştirirler, eksik kalan becerileri tamamlarlar ve davranış olarak da, özellikle eğitmenin liderliğinde, gerek taklit gerek ise tartışma yoluyla davranış geliştirmeye başlarlar, becerilerini her durumda ve hızlıca nasıl yerine getireceklerini öğrenirler. Bu tipik usta-çıraklık ilişkisidir. Ve teknik yetkinlikler ancak ve ancak bu şekilde elde edilirler. Usta-çırak ilişkisine girebilmek için gerekli altyapı ise sınıf eğitimiyle verilir. Bu anlamda sınıf eğitimi bilgi-beceri yoğun, workshop ise beceri-davranış yoğun yapılardır.

Eğitim ile ilgili kitaplarda otoriteler, eğitim hayat döngüsünden bahsederken workshopı da muhakkak dahil ederler. Bunun sebebi de sınıf eğitimiyle, bilgi ve bir miktar beceriye elde edilen kişilerden, projelerin gerektirdiği davranışı göstermeyi beklemenin haksızlık ve yanlış olduğu gerçeğidir. Ülkemizde workshop alışkanlığı çok ama çok azdır. Ben çok az müşterime bunu kabul ettirebiliyorum. Çoğu zaman yukarıda bahsettiğim 10 günlük eğitimi bile 3-4 güne sığdırmam istendiğinden, tabi olarak ben de 10 gün eğitim ve üzerine 5 gün workshop, dolayısıyla 15 gün diyemiyorum. 200 bin TL’lik bir mala birisinin 10 bin veririm demesi gibi bir durum bu 🙂  Workshopı yapmamak için en sık söylenen sebep, “zaman yok”tur. Halbuki projenin gecikmesinin en temel sebeplerindendir yetkinlik eksiği. Bir diğer argüman da, “katılımcılar zaten eğitimden sonra projeye girecekler ve orada kod yazacaklar”dır. Bu da farkedileceği gibi, workshopın ne anlama geldiğini anlamamaktan kaynaklanan bir argümandır. Workshopta yazılan kod, gerçek kod değildir ama projede yazılan kod gerçek koddur. Yani söylenen şey, tatbikat yapmadan askerlerin doğrudan savaşa girip gerçek mermileri kullanmaları ya da Tıp öğrencilerinin, ameliyat yapan hocalarını izlemeden doğrudan ameliyata girmesidir. Sonra neden hasta öldü demenin bir anlamı yok bence 🙂

Teknik eğitimin, ülkemizdeki yapıldığı haliyle, ciddi problemleri var. Örneğin eğitmen kirliliği, içerik kirliliği, bir ihtiyaç analizi yapmadan eğitim satan ya da alan kurumlar, eğitimi mala indirgeyen dershane mantığındaki eğitim kurumları vs. Bunlara daha sonra değiniriz.

Ama şu bir gerçek: Eğitim şart 🙂

 

Toplam görüntülenme sayısı: 1160

16 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
16 Nisan 2012

Neden Nesne-Merkezli Programlama? II

Akin Java, Yazılım Mühendisliği bohçalama, encapsulation, kapsülleme, nesne, object

“Neden Nesne Merkezli Programlama” başlıklı dizinin ilk yazısında, nesne-merkezli dillerin gerçekliği ifade etme noktasında, yordamsal dillere göre nasıl bir avantaja sahip olduklarını açıklamıştık. Buna “ifade gücü” demiştik.  Bu dizinin ikinci yazısında da, ifade gücünü bir örnekle açıp, sonrasında da “değişim” konusunu ve bu açıdan nesne-merkezli dillerin neler sağladıklarını ele alalım.

Örneğimiz şöyle: Düşünün ki üniversitelerin bölümlerindeki ders planları ve öğrencilerin derslere kayıt işlerini yöneten web tabanlı bir “Üniversite Öğrenci Bilgi Sistemi” geliştirmek durumundayız. Bu yazılımın, öğrencilerin derslere kayıt sürecini içeren kısmını yordamsal bir yaklaşımla nasıl tasarlayıp programlayacağımızı ele alalım. Derslere kayıt sürecinin, “Derse kayıt ol” isimli bir kullanım şekli (use case) ile detaylandırıldığını varsayalım. Buna göre öğrenci, bu kullanım şeklini işletebilmesi için zaten sisteme girmiş (logged on) durumda olmalıdır. Öğrenci, sonrasında alabileceği derslerin listelendiği sayfaya gelmiştir. (Bu sayfaya doğrudan gelebileceği gibi arama yaparak da gelmiş olabilir.) Bu sayfada almak istediği dersleri seçer ve bir tıklama ile bu isteği, tarayıcıdan sunucuya gönderir. Kullanım şekli, sürecin sahip olması gereken ders seçme ve kayıt olma ile ilgili iş kurallarını ifade etmiştir ve sürecin sonunda, sistemin bu kuralları yerine getirip, sonrasında da kaydolunan dersleri göstermesi, kaydolunamayanlar varsa, onları da sebepleri ile listelemesi gereklidir. Bu listelemenin de, sunucunun, tarayıcıya gönderdiği ve sürecin en son arayüzü olan bir sayfada olduğunu da varsayalım.

Yukarıdaki ihtiyaçların tasarımı ile ilgili odaklanmamız gereken nokta şu: Sistem, ders seçme ve kayıt olma ile ilgili iş kurallarını nasıl yerine getirir? Dolayısıyla bu bir tasarım hatta sonrasında da bir kodlama sorusu. İsterseniz önce iş kurallarından bahsedelim biraz. İş kuralları (ya da business rules), sürecin farklı noktalarında, akışın keyfiyetiyle ilgili şeyler söylerler bize. Bazen akışta kısıtlamalar yaparlar bazen de başka fonksiyonları ya da akışları tetiklerler. İş uygulamaları gittikçe daha karmaşık hale geliyorsa, iş kurallarının sayısı ve içindeki öğeleri ve aralarındaki ilişkileri de artıyor demektir. Bu uygulamada da, lisans, yüksek lisans, tam-zamanlı, yarı-zamanlı, gündüz öğretimi, gece öğretimi öğrencisi gibi farklı öğrencilerin farklı iş kurallarına uygun olarak ders seçtikleri ve derse kayıt oldukları varsayılabilir. Örneğin lisans üstü öğrencilerin ders seçme sürecinde, derslerini, danışman hocasının onaylaması, bir adım olarak bulunabilir. Benzer şekilde derslerin de, lisans ya da yüksek lisans dersi, zorunlu ders, seçmeli ders vb. farklı tiplerini olduğu, derslerin önşart derslerinin olduğu, sınıf kapasitesi ya da seçmede belli öğrencilere öncelik vermekle ilgili gibi pek çok iş kuralına sahip olduğu düşünülebilir.

Şimdi, yukarıdaki soruyu biraz daha net olarak şu şekilde sorabiliriz? Öğrencilerin farklı tiplerine göre farklı seçme süreçlerini, derslerin de farklı tiplerine göre farklı kayıt süreçlerini ve bu süreçlerdeki iş kurallarını, yazılım sisteminin hangi parçası bilir ve yerine getirir? “Süreçlerdeki her bir adımı ve iş kuralını yerine getiren bir fonksiyon yazarım” dediğinizi duyar gibiyim? Peki o zaman sorumu şöyle sorayım: Bu fonksiyonları nereye koyarsınız? Yani ortaya çıkan, örneğin toplam 100 tane olan fonksiyonu nasıl bir organizasyona tabi tutarsınız? “Birbirleriyle ilintili fonksiyonları bir araya getiririm” diye cevap vereceksiniz büyük bir ihtimalle. Bu durumda iki sorum olur: Bir, “fonksiyonların ilintili olması” ne demektir? Yani neye göre ilintiye karar verirsiniz? İki, o birbiriyle ilintili fonksiyonların ilişkisini nasıl ifade edersiniz?

Fonksiyonların birbirleriyle ilintili ya da ilişkili olmasına, örneğin aldıkların parametrelerin bazılarının aynı olması, dolayısıyla ortak bir parametre seti üzerine çalışmalarına bakarak karar verebilrisiniz. Yani f() metodu a, b ve c parametrelerini, g() metodu da a, c, e ve f parametrelerini, u() metodu da b, c, ve f parametrelerini kullanıyorlarsa, bu metotların birbirleriyle ilintili olduklarını dolayısıyla aynı “yerde” tanımlanmaları gerektiğini soyleyebilirsiniz.

Peki ilintili olmayı hallettik. “Birbirleriyle ilintili fonksiyonları bir araya getiririm”den ne anlıyoruz? Muhtemelen, ilintili fonksiyonları aynı dosyaya koymayı, değil mi? Peki neden iki dosyaya koymazsınız?  Ya da neden koyarsınız? Demek istediğim, kaç dosyaya koyduğunuzun hiç bir önemi yok, çünkü bir dosya olsun iki tane olsun, iş problemini çözmek açısından hiçbir öneme sahip değiller. Bir dosya ya da iki dosya ne farkeder ki iş alanımız, süreçlerimiz ya da iş kurallarımız açısından? Dolayısıyla ilintili fonksiyonları ve hatta onların üzerinde çalıştıkları parametre setini aynı dosyada tanımlamamızın, iş sürecimize hiç bir katkısı yok, çünkü “dosya” kavramı, bu anlamıyla işle ilgili bir soyutlama değil. Böyle bir durum olsa olsa üzerine farklı programcıların çalışmasını sağlamak açısından bir fayda yaratabilir. Bu fonksiyonlar, makinamızdaki IDE’de ya da kod depomuzda farklı dosyalarda tutulur ama iş süreçleri açısından bu durumun hiçbir önemi yoktur. Brooks babanın dediği gibi olsa olsa “accidental” yani arizi, tamamen ikincil bir problemi çözer, “iş”imizi halletmekle ilgili en ufak bir katkısı yoktur. Bunun sebebinin, yordamsal dillerde, ilintili fonksiyonları, bir üst katmanda bir araya getirecek bir yapının olmamasıdır. (Bazı dillerde “namespace” ya da “package” gibi yapıların olması bu durumu değiştirmez çünkü bu yapılar genel olarak erişim kontrolü için kurgulanmışlardır.) Nesne-merkezli dillerde ise yukarıdaki duruma şöyle bir cevap verilir: Fonsiyonlar, bir nesnenin sorumlulukları olarak ele alınır ve o nesne kendisiyle ilgili sorumlulukları yerine getirdiği gibi, o sorumlulukların üzerinde çalışacakları parametreleri yani veri yapılarını da kendi içinde barındırır. Dolayısıyla “ilintili” olmak kavramı nesne ile anlam kazanır ve fonksiyonlar ile o fonksiyonların üzerinde çalıştığı veri yapılarını bir nesne yapısıyla bir arada ifade etmeye de bohçalama ya da kapsülleme (encapsulation) adı verilir. Yordamsal dillerde de özellikle soyut veri tiplerini (abstract data type) ifade etmek amacıyla bazı bohçalama yapıları bulunsa da bu yapıların, nesne-merkezli dillerin nesne kavramı kadar güçlü olmadığı aşikardır. Bohçalama, nesne-merkezli dillerde genel olarak sınıf (class) yapısıyla oluşturulur. Nesneler ise sınıflardan üretilir ve her nesne (şimdilik) bir sınıfın, bellekte yaşayan bir örneğidir (instance). Dolayıısyla aynı sınıftan üretilmiş nesneler aynı tiptedirler yani aynı değişkenlerden oluşan duruma (state) ve sorumluluklara yani (functions ya da Smalltalk ve Java’cı diliyle “method”) sahiptirler. Aynı tipte olan nesnelerin durumunu oluşturan veri yapıları da aynıdır ama durumun kendisi farkıdır çünkü durumu oluşturan değişkenlerin aldıkları değerler, nesneden nesneye değişir. Yukarıdaki örnekle açıklarsak, öğrenci nesneleri muhtemelen, Ogrenci sınıfında tanımlanır ve bu sınftan türetilirler. Tckn, isim, soy isim vb. bilgiler, Ogrenci sınıfında tanımlanan değişkenlerle ifade edilirler. Dolayısıyla bu bilgilerin tümüne durum dersek, bellekte durumları aynı olan birden fazla nesne olmamalıdır, çünkü öğrenci nesnelerinin en azından tckn bilgisi birbirlerinden farklıdır. Benzer şekilde aynı Ogrenci sınıfından türetilen tüm öğrenci nesneleri de aynı sorumlulukları yerine getirirler, çünkü hepsi Ogrenci sınıfında tanımlanan metotlara sahiptirler. Sadece o metotlar, genel olarak nesnenin durumu üzerine çalıştıklarından, farklı nesneler için aynı sorumluluğu farklı durumlar üzerinden yerine getirirler.

Görüldüğü gibi, nesne/sınıf kavramı ve yapısı, fonksiyonlardan bir yukarıda bir soyutlama yapısı olarak görülebilir ve gerçek dünyadaki fiziksel ya da kavramsal şeyleri ifade etmemize yarar ki bunun da iş süreçlerini modelleyip kodlamamız açısından önemi çok büyüktür.

İfade gücünü, bir örnekle açıkladıktan sonra, nesne yapılarının, değişim konsunda bize nasıl imkanlar sağladıklarını, bir sonraki yazıda ele alacağız.

 

Toplam görüntülenme sayısı: 1618

19 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
15 Nisan 2012

İnomera Java Yazılım Akademisi 2012

Akin Java akademi, İnomera, staj

Her yıl olduğu gibi bu yıl da Java (JEE) Eğitimi ve Staj’dan oluşan “Inomera Java Akademi” programı düzenleniyor. Inomera’nın ücretsiz olarak yazılım sektörüne ve gençlere armağan ettiği bu programla ilgilenebilecek üniversiteli gençler, program detaylarına http://www.inomera.com/academy adresinden ulaşabilirler.
Bol Java’lı günler 🙂

Toplam görüntülenme sayısı: 1094

16 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
15 Mart 2012

Yaşasıııınnnn, JavaTurk’ün Teması Yenilendiiiiii :)

Akin Diğer

Taa başından bu yana, zaman zaman, JavaTurk.org’un teması, özellikle de font renkleri hakkında olumsuz geri bildirimler alıyordum. Bu tür geri bildirimlerde çoğu kez, koyu arkaplan üzerine açık renkli fontun, okunurluğu ciddi bir şekilde zorlaştırdığı belirtiliyordu. Font renkleriyle bayağı bir oynadım ama sanırım okumayı o kadar da kolaylaştıramadım. Neyse, sonunda temayı değiştirdim tümden. Biraz renk de istediğim için bu temayı seçtim, inşallah beğenirsiniz.

Toplam görüntülenme sayısı: 1021

14 Bunu beğendim 🙂
Tweet
Follow me
Tweet to @kaldiroglu
«< 54 55 56 57 58 >»

Günlüğüme Hoşgeldiniz

Bu günlükte, Yazılım Mühendisliği, Bilgi Teknolojileri, Java, kişisel gelişim ve zaman zaman da diğer konulardaki düşüncelerimi sizlerle paylaşacağım. Umarım beğenir ve hoşça vakit geçirirsiniz.

Her türlü düşüncenizi, yorum olsun, beğeni ya da eleştiri olsun, bana iletmenizi rica ediyorum sizden. Ayrıca bana akin@javaturk.org adresinden ya da Twitter'dan ulaşabilirsiniz. Videolarıma da buradan ulaşabilirsiniz.

Teşekkür ederim.

Akın Kaldıroğlu

Rahat Okumak İçin

A Decrease font size. A Reset font size. A Increase font size.

Sosyal Medya

  • Twitter
  • Facebook
  • LinkedIn
  • Youtube

Son Twitlerim

→ Takip Etmek İçin

Abone Olun

Emalinizi girerek yazılardan haberdar olun.
Loading

Son Yazılarım

  • Udemy Eğitimlerim Üzerine
  • (başlıksız)
  • Clean Code / Temiz Kod Eğitimi Udemy’de
  • Java ile Nesne-Merkezli Programlamaya Giriş Eğitimi Udemy’de
  • Selsoft Video Eğitimleri
  • Spring ile Kurumsal Yazılım Geliştirme
  • Corona Günlerinde Design Patterns
  • Corona Günlerinde Java
  • JDK 10 ve “var” Özelliği
  • Onur Özcan
  • Analist ve İş Bilgisi
  • Farklı Dillerin Bakış Açısıyla Nesne-Merkezli Programlama
  • Java Nedir?
  • Bilgi Teknolojilerinde Yetenek Yönetimi – II: Tanımlar ve Eleştiriler – I
  • Alelade Hikayeler – II: Bir Başka Performans Problemi

Yazı Kategorileri

Yazı Takvimi

Mart 2026
P S Ç P C C P
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« May    

Yazı Arşivi

Blogroll

  • Binnur Kurt'un Günlüğü
  • Ender'in Java Blogu
  • Erdem Seherler
  • Kızımın Günlüğü
  • Kurumsal Java
  • Levent Karagöl
  • Levent'in Java Blogu
  • Mert Can Akkan’s java tips,options, news…
  • Yaşar Safkan
  • Yasin Saygılı
  • Yazı Dünyası

Yazı Etiketleri

analiz Bilmek C Desen design pattern EJB Eğitim Fortran Hibernate Java Java'ya nasil baslarim Java dersleri Java EE Java Persistence API Java SE Java Sertifika Java Öğren Java öğreniyorum Java öğrenmek JPA Kalıp Kurumsal Java nesne nesne-merkezli No Silver Bullet object object-oriented Oracle Java Certifications pattern performans programlama programlama dilleri programlama nedir sertifika singleton tasarım tasarım deseni tasarım desenleri tasarım şablonu yazılım yazılım geliştirme Yazılım Mühendisliği yazılımın doğası yazılımın zorlukları Şablon

↑

© Java Günlüğüm 2026
Powered by WordPress • Themify WordPress Themes
 

Yorumlar Yükleniyor...