Previous
Next

JAVA - Abstract(Soyut) sınıflar ve metodlar

by Cem Kefeli 27. Mayıs 2010 04:00

JavaJava programlama dili için soyutlama demek; birilerini soyut tanımlanan her şeyi override etmeye mecbur kılmak demektir dersem sanırım çok da mantıksız olmaz. Biraz karışık mı oldu? O halde devam edelim.... Java'da soyutlama sınıflara ve metodlara uygulanabilmektedir. Aslında buraya kadar söylediğim herşey C# için de aynı. Soyutlama bir konsepttir aslında, dilden dile pek bir farklılık içermez. Soyut tanımlanan hiçbirşey kendi başlarına işe yaramazlar, iş görmezler. Yalnızca bir yol gösterici bir kılavuzdurlar aslında. İçerikleri de yoktur soyut metodların. Soyutlama, kalıtım ile tamamen ilgilidir. Zira az önce bahsettiğim bu yol gösterme ve kılavuzluk türeyen yeni nesnelere yapılmaktadır.

Şimdi biraz daha derinlere dalalım. Kalıtım ve overriding ile ilgili detaylı bir inceleme "Inheritance(Kalıtım) nedir?" başlıklı yazım içerisinde yapmıştım. Soyutlama da kalıtım ve overriding ile çok iç içe olduğu için eksiği olduğunu düşünenler ilk önce burayı tıklayarak gerekli alt yapıyı kurabilirler. Abstract Classes UML Şimdi asıl konumuza geri dönecek olursak, biliyoruz ki ana sınıftan türeyen yavru sınıflar içerisinde ana sınıflara ait metodları override edebiliyorduk. Fakat bu tamamen bizim isteğimize kalmış bir durumdur. Yani siz eğer override etmek isterseniz edersiniz, eğer override etmek istemezseniz ya da buna gerek duymuyorsanız kimse size neden override etmedin diye sormaz. Override etmemeniz derleme zamanında(compile time) ya da çalışma zamanında(run time) herhangi bir hataya da sebebiyet vermez. Pekiala biz eğer bir metodun, metodun içinde bulunduğu sınıftan türeyen tüm alt sınıflarda override edilmesini istiyorsak ne yapmalıyız? İşte soyutlama tam olarak burada karşımıza çıkmaktadır. Yani yazdığımız sınıftan türeyen tüm yavrucularda belirttiğimiz sınıfltarın override edilmesini ve yeniden bir içerik oluşturulmasını zorunlu kılabiliyoruz bir metodu abstract(soyut) tanımlayarak. Bir metodun soyut olarak tanımlanması o metodun bulunduğu sınıftan türeyen tüm sınıflarda override edileceğini garanti altına alır. Peki bu bizim için neden gereklidir? bırakalım da ona yeni sınıfı türeten adam karar versin diyemez miyiz? Diyemeyiz... Şöyle ki; tanımladığımız soyut metod alt üyelerde de mutlaka bulunması gereken fakat ana sınıf için birşey ifade etmeyen bir yapıya sahip olabilir. Yani bu cümleden sonra şu kanıya varabiliriz. Soyut metodlar ana sınıflar için anlamsızdır ve birşey ifade etmezler, asıl anlamlarını ise yavru sınıflar içerisinde kazanırlar. Şimdi bir örnek yaparak bu dediklerimizi biraz daha somutlaştıralım. Sağ taraftaki şekilde örneğe ait UML diagramını bulabilirsiniz.Fazlası...

JAVA - Access specifiers(Erişim belirleyicileri) nedir?

by Cem Kefeli 20. Mayıs 2010 07:16

JavaÇoğu zaman, hayatın her alanında bazı kısıtlamalar ile karşılaşıyoruz. Eğer bir şeylere sahiplik varsa onun saklanması, korunması da çok doğal bir istektir. Herkes, her zaman herşeyini birileri ile paylaşmak istemeyebilir. Daha da ötesi paylaşmasının çok da uygun olmayabileceğini düşünebilir. İzinsiz kullanımın, yetkisiz kullanımın önüne geçilmesi için de böyle bir yapı şarttır aslında. Programlama dillerindeki access specifiers(erişim belirleyicileri) kavramı da tamamen bu doğal dürtünün sonucunda ortaya çıkmıştır. Ben bir sınıf yazıp bunu bir pakatin içerisinde başkaları ile paylaşabilirim. Başkalarının da yazdığım kod parçacıklarından faydalanamasını sağlayabilirim. Fakat sınıf içerisinde yer alan bazı değişkenlerin kimse tarafından değiştirilememesini, bazı yordamların override edilememesini isteyebilirim. Kodun sahibi olarak bunları isteyebilmek benim en doğal hakkımdır aslında. Şöyle toparlayabiliriz bu kısmı; erişim belirleyicileri, programcı tarafından oluşturulan her bir yazılım öğesinin paylaşım sınırlarını belirlemek için kullanılmaktadır. Şimdi bu konuyu biraz daha açmanın zamanı geldi...

Java Access Specifiers - Erişim Belirleyicileri Öncelikle şunu söyleyeyim, yandaki şekil gözünüzü korkutmasın. İş hiç de şekilde görüldüğü gibi karışık ve öğrenilmesi güç bir sey değil. Aslında bu şekli gördükten sonra üzerinde konuşmaya da çok fazla gerek yok. Çünkü bu şekil ne var ne yok gayet güzel bir şekilde açıklıyor olayı. Yine arada ekleyeceğimiz kısa notlar olacaktır. Bizim bu belirteçlerden özellikle üzerinde duracağımız public, friendly, private, protected erişim belirleyicileridir.

İlk önce friendly erişim belirleyicisi ile başlamak istiyorum. Friendly erişim belirleyicisi java dili için standart erişim belirleyicisidir. Yani eğer herhangi bir erişim belirteci yoksa friendly olarak kabul edilir. Bu erişim belirleyicisi metodlara, sınıflara ve alanlara uygulanabilmektedir. Özelliği ise aynı paket içerisindeki tüm sınıflardan bu üyelere erişilebilirken, paket dışı üyelerden bu üyelere erişilememektedir. Burada enteresan olan ise bu erişim belirleyicisinin kullanılmasının istenmemesidir. Yani bir metodun, sınıfın ya da alanın başına friendly anahtar sözcüğünün yazılması istenmemektedir. Yazarsanız hata ile karşılaşabilirsiniz. Eğer bir üyeyi friendly olarak tanımalamak isterseniz yapmanız gereken o alanı boş bırakmaktır.

Public erişim belirleyicsi tüm üyeler tarafından herhangi bir sınırlama olmadan erişilebilmektedir. Hem sınıflara, hem metodlara, hem de alanlara uygulanabilmektedir bu erişim belirleyicisi. Public erişim belirleyicisine sahip bir üyeye hem paket içinden hem paket dışından, hem tanımlandığı sınıftan hem tanımlandığı sınıf dışından, kullanıldığı sınıftan türetilen tüm sınıflardan erişilebilmektedir.Fazlası...

HTML 5.0 nedir? Flash'ın yerini alabilir mi?

by Cem Kefeli 2. Mayıs 2010 02:09

Adobe Flash Player Logo

Geçenlerde şurada (Habertürk - Kedi uzanamadığı ciğere mundar dermiş) bir yazı okudum ve oldukça da ilgimi çekti. Yazı HTML 5.0'ın Steve Jobs tarafından nasıl yorumlandığı üzerine kurulu. Yazının başlığı oldukça dikkat çekici ve iddialı. Peki gerçekten Apple, yani bir anlamda da Steve Jobs için durum gerçekten kedinin ciğere uzanamaması olayı mı? Yani durum Apple'ın flash'ı çekememesinden mi kaynaklanıyor yoksa internetin belki de şimdiye kadar kullanıcılarına sunduğu en büyük güzelliklerinden birisi olan Flash'ın altın devri gerçekten bitiyor mu? Ya da artık Flash devri kapanıp yerini çok daha güncel bir teknolojiye bırakmalı mı?

İlk önce Flash'ın geçmişinden biraz bahsetmek istiyorum. Flash WEB'in altın çocuğu olduğu için şuradaki yazımda (Bayanlar ve Baylar!!! WEB 3.0 karşınızda...) Flash konusuna değinmiştim. Dileyenler Flash'ın WEB dünyasındaki konumunu öğrenmek için detaylı okuyabilirler. Hatırladığım kadarıyla Flash ile ilk olarak Macromedia'nın 1996 yılında Flash'ı duyurması sayesinde tanıştık. O zamanlar flash'ı Macromedia'nın geliştirdiği ve tüm haklarının Macromedia'ya ait olduğu zamanlardı. Hatta ismi de Flash olarak değil de "FutureSplash Animator" olarak biliniyordu. Macromedia aynı sene içerisinde FutureSplash Animator isminden vazgeçip "Macromedia Flash 1" ismini benimsedi. İşte Macromedia için 2005 yılında duyurulan Macromedia Flash 8'e kadar uzanacak Flash yolculuğu da bu isimle birlikte başlamış oldu. Hatırlıyorum da Flash ile yapılmış imam-sayko filan gibi çok ilginç animasyonlar da yapıldı o yıllarda. Laughing Fakat yıllar içerisinde Flash'ın cazibesi arttıkça müşterileri de artmaya başladı. Yıl 2008'i gösterdiğinde Adobe Macromedia'yı satın alarak yeni versiyon olan "Adobe Flash CS3 Professional" ı duyurdu. Şu an sene 2010 ve Adobe'nin kullanıcılarına sunduğu 2010 tarihli son Flash versiyonu Adobe Flash CS5 Professional ismi ile anılıyor. İlk günlerden bu yana Flash hala C++ dili ile yazılıyor ve her zaman vektörel çalışmayı benimsemiş durumda. Yani normalde bir animasyonu video gibi düşünürseniz ard arda geçen video karelerini de birer resim olarak düşünebilirsiniz. Yani videolarda ard arda gelen resimlerin oynatılması durumu vardır. Bu da veri boyunun çok yüksek olması ve her bir resim çerçevesinin sıkıştırma algoritmaları ile sıkıştırılmasını zorunlu kılar. Fakat Flash'ın vektörel çalışma prensibi bu video mantığı ile uyuşmaz. Vektörel çalışma nesnelerin uzam-zamansal konumları ile ilgilenir. Örneğin ekranda bir kare şekli vardır, flash bu kareyi bir nesne olarak yorumlar ve (t) anındaki karenin konumu (x1,y1) ise (t+t0) anındaki konumunu (x2,y2) olmasını sağlar. Böylece karenin ekranda hareketi oluşturulmuş olur. Bu aşamayı sayısal işaret işlemeciler çok daha kolay anlayacaktır, çok da üzerinde durulması gereken bir konu değil... Fazlası...

Blogengine admin paneli giriş şifremi unuttum ne yapmalıyım? - Blogengine password recovery

by Cem Kefeli 7. Şubat 2010 03:14

Blog EngineDaha önce "Acaba Blogengine şifremi unutursam bir daha bu değerli şeyi nasıl bulabilirim? Smile" diye kendi kendinize sordunuz mu bilmiyorum ama ben az önce sordum. Zira hostta kurulu bir sistemde bunu unutursanız bir daha yönetici panelinize nasıl girebilirsiniz ki Frown Çünkü Blogengine'de şu ana kadar çıkan sürümlerinde 'password recovery' gibi bir özellik yok bildiğim kadarı ile. "Eee o zaman, bu şifre veri tabanında bir yerlerde kaydedilmiyor mu zaten? Girer oradan düzeltir, yerine yenisini yazarım ya da bakar hatırlarım." diye bir düşünceye de kapılabilirsiniz hemen. Ama bu düşünce de bir işe yaramayacaktır. Şifre hem SqlServer, Hem MySQL Server, hem de XML database ve diğerlerini kullanan tüm sitemlerde veritabanında tutuluyor doğru. Ama cache'lenmiş ve şifrelenmiş bir şekilde tutuluyor. Dolayısı ile veritabanının ilgili yerlerine baktığınızda siz şifrenizi yine göremeyeceksiniz. Gördüğünüz yalnızca şifrenizin şifrelenmiş hali olacak. Veritabanından değiştirip oraya istediğinizi yazdığınızda da bu sefer panele girerken bu işe yaramayacak Smile. Çünkü o yazdığınız metnin şifresi çözüldüğünde sizin girmeniz gereken metin başka, abuk sabuk bir metin olacak. O halde ne yapmalıyız?

İlk önce bu şifrelerin veritabanında hangi alanlarda tutulduğuna bir bakalım. Biliyorsunuz ki Blogengine hali hazırda birçok veritabanı bağlantısı arayüzüne destek veriyor. Server tabanlı veritabanı kullanan(MSSql Server, MySQL Server vb.) ve XML tabanlı veritabanı kullanan sistemler olmak üzere iki ana başlıkta topluyorum şimdilik. Eğer XML kullanıyorsanız (XmlMembershipProvider) sisteminizin kök dizininden başlayarak /App_Data/users.xml yolunu izleyerek kullanıcılar için temel bilgilerin tutulduğu XML dosyasına erişebilirsiniz. Bu XML'in içerisinde Kullanıcı adı, şifrelenmiş-cachelenmiş şifre, e-posta adresi ve son giriş zamanı gibi bazı bilgiler bulunuyor. Aşağıda bu dosyanın içeriğine bir örnek veriyorum.

/App_Data/users.xml  |  Gizle  |  Göster
<Users>
   <User>
      <UserName>Admin</UserName>
      <Password>jGl25bVBBBW96Qi9Te4V37Fnqchz/Eu4qB9vKrRIqRg=</Password>
      <Email>post@example.com</Email>
      <LastLoginTime>2007-12-05 20:46:40</LastLoginTime>
   </User>
</Users>

4. satırdaki password alanı bizim ilgimizin odak noktasını oluşturuyor diyebilirim. Server tabanlı bir veritabanı da kullanıyorsanız XML tabanlı bir veritabanınız da varsa yapmanız gereken password field'ı içerisindeki şifrelenmiş-cachelenmiş veriyi temizleyip silmek. Böylece blogunuz default ayar olan 'admin' kullanıcısı için 'admin' şifresine geri dönecektir.
Eğer Server tabanlı bir veritabanı kullanıyorsanız ise yapmanız gereken be_Users tablosu içerisindeki uygun kullanıcıya ait ilgili kayıt satırını bulup yine password sütununun içeriğini temizlemektir.

Umarım okuyanların işinize yarar ve faydalı olur. Değişik yöntemler bilen ve atladığım noktaları yakalayan olursa yorum yaparak katkıda bulunabilirsiniz. 

Hakkımda...

Cem KEFELİ

Electronics and
Telecommunication Eng.
devamı...


Son yapılan yorumlar...

Comment RSS

Yasal bir uyarı...

Disclaimer"Bu web sitesinde görmüş olduğunuz bilgilerin, dokümanların ve diğer materyallerin kullanılmasından doğabilecek hiç bir sorumluluktan site sahibi sorumlu tutulamaz. Web sitesi içerisinde yer alan yazılar, yorumlar, resimler ve diğer tüm içerikler yalnızca sahibinin görüşünü yansıtmakta olup içeriğin sahibi kişilerin çalıştığı kurumları bağlayıcı hiç bir nitelik taşımamaktadır. Yapılan tüm alıntılar mutlaka kaynak gösterilerek verilmeye çalışılmaktadır. Web sitesi içerisinde bulunan ilgili materyaller, ilgili yasal kurumlar tarafından uygun görülmemesi durumda kaldırılacaktır."
General