Effective Java Madde 7: Finalizer (Sonlandırıcı) Kullanmaktan Kaçının

Salı, 27 Oca 2015 yorum yok

Java’da sonlandırıcılar (finalizer) çoğu durumda gereksiz, tehlikeli ve tutarsız davranışlar sergileyen metotlardır. Kullandığınız taktirde anlam veremediğiniz hatalı davranışlar, kötü performans ve taşınabilirlik (portability) sorunlarıyla karşılaşabilirsiniz. Sonlandırıcı kullanmak sadece bir iki durumda işe yarayabilir, onları da yazıda göreceğiz. Ancak genel bir kural olarak sonlandırıcı kullanmaktan sakınmalıyız.

Öncelikle sonlandırıcı derken tam olarak neyi kastettiğimizi söyleyelim. Java’da bütün sınıfların atası olan Object içerisinde aslında hiçbir iş yapmayan finalize() metodu vardır. Eğer yazılımcı nesne bellekten temizlenmeden önce bir takım kaynakları serbest bırakmak istiyorsa, bu metodu override edebilir. Teorik olarak çöp toplayıcı, bir nesne tamamen erişilemez duruma geldiğinde bu metodu çağıracak ve sistemden silinmeden önce finalize() metodunun içeriği işletilecektir. Ancak pratikte bu yaklaşım çalışmamakta ve uygulamada ciddi sorunlara yol açmaktadır.

Devamını Oku…

FacebookTwitterLinkedInPocketEmailFriendFeedDiggDeliciousTumblrPaylaş

Effective Java Madde 6: Erişilmeyen Nesnelerin Referanslarından Kurtulun

Çarşamba, 14 Oca 2015 yorum yok

C veya C++ gibi bellek yönetimini yazılımcının yaptığı dilleri kullandıktan sonra Java gibi çöp toplayıcı (garbage collector) mekanizmasına sahip bir dile geçiş yaptığınız zaman, yazılımcı olarak işinizin ne kadar kolaylaştığını farkedersiniz çünkü çöp toplayıcı sizin için bellekte kalmış kullanılmayan nesneleri temizleyecektir. Bu durum size Java ile kodlama yaparken bellek yönetimini düşünmek zorunda olmadığınız izlenimini verebilir ancak bu doğru değildir!

Hemen aşağıdaki yığıt (stack) kodunu inceleyelim:

// Bellek sızıntısını bulabilir misiniz?
public class Stack {

    // Yığıt yazarken generic türler kullanmak daha mantıklı olacaktır
    // ama buradaki amacımız farklı olduğu için üzerinde durmuyoruz
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
   
    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }

    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        return elements[--size];
    }
    
    /**
    * Dizide boşluk kalmamışsa, bir sonraki elemanın eklenebilmesini
    * sağlamak için diziyi genişletiyoruz
    */
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

Devamını Oku…

Effective Java Madde 5: Gereksiz Nesne Yaratmaktan Kaçının

Salı, 13 Oca 2015 yorum yok

Yazılım geliştirirken var olan bir nesneyi kullanmak, işlevsel olarak aynı işi yapan yeni bir nesne yaratmaktan genellikle daha faydalıdır. Nesnelerin yeniden kullanımı hem uygulamayı hızlandıracak hem de daha okunabilir bir kod yazmanızı sağlayacaktır. Eğer bir nesne değiştirilemez (immutable) ise, o nesne her zaman yeniden kullanılabilir.

Aşağıdaki kod gereksiz nesne yaratılmasına bir örnektir:

String s = new String("merhaba")   // YANLIS KULLANIM!!

Yukarıdaki kod her çalıştırıldığında, içeriği aynı olan yeni bir String nesnesi yaratılacaktır. Tırnak içerisindeki “merhaba”, Java’da zaten bir String nesnesini ifade eder ve gereksiz yere yapıcı metot (constructor) kullanarak yarattığımız bütün nesnelerle işlevsel olarak aynıdır. Dolayısıyla yukarıdaki kodun bir döngüde çalıştırıldığını düşünürseniz çok fazla sayıda gereksiz String nesnesi yaratılmış olur. Bu durumu engellemek için aynı kodu aşağıdaki gibi yazabiliriz:

String s = "merhaba"   // DOGRU KULLANIM!!

Devamını Oku…

Effective Java Madde 2: Çok Sayıda Parametreyle Karşılaştığınızda Builder Kullanın

Cuma, 12 Ara 2014 yorum yok

Daha önce birinci maddesini işlediğimiz Effective Java kitabının ikinci maddesiyle devam ediyoruz.

Sınıf yapıcılar (constructor) ve statik fabrika metotlarının (static factory methods) paylaştığı ortak bir kısıt vardır: çok sayıda parametre geçmeniz gerektiği zaman kullanışsız bir duruma gelirler. Örneğin, paket gıdaların üzerinde yer alan ve besin değerlerini gösteren bir etiketi Java’da bir sınıf kullanarak ifade etmeye çalıştığımızı düşünelim. Bu etiketin üzerinde kalori, kolesterol, protein, karbonhidrat, yağ, doğmamış yağ, kalsiyum, demir ve daha birçok besin türü görürüz. Ancak besinlerin bir çoğu için bu değerlerin büyük bir kısmı opsiyonel olacaktır, yani bu alanlara hiçbir atama yapmamıza gerek olmayacaktır.

Böyle bir sınıf yazmamız gerektiği zaman nasıl bir sınıf yapıcı veya statik fabrika metodu kullanırız? Genelde yazılımcıların aklına gelen ilk yöntem iç içe geçmiş yapıcı metotlar (telescobing constructors) kullanmak olur, yani sadece zorunlu parametreleri içeren bir yapıcı metot, ardından zorunlu parametreleri ve sadece bir opsiyonel parametre içeren başka bir yapıcı metot, ardından iki opsiyonel parametreli üçüncü bir yapıcı metot ve bu şekilde devam eder. Şimdi örnek kodu inceleyelim, kolaylık olması açısından sadece 2 tane zorunlu 4 tane de opsiyonel değişkenimiz olsun.

Devamını Oku…

Effective Java Madde 1: Statik Fabrika Metotlarına Bir Şans Verin

Perşembe, 11 Ara 2014 yorum yok

Effective Java kitabını duymuşsunuzdur, Joshua Bloch efsane kitabında madde madde sizlere nasıl kaliteli Java kodu yazacağınızı anlatır. Bu kitapta anlatılanlarla ilgili yüzlerce İngilizce kaynak bulmak mümkün ama ben Türkçe bir kaynak bulamayınca sizlere bu kitabı özetlemeye karar verdim. Direk kitabın tam çevirisi olmasa da kendimce eklemeler çıkarmalar yaparak ve önemli gördüğüm yerleri vurgulayarak kitaptaki bölümlerden daha kısa ama aşağı yukarı aynı şeyi anlatan yazılar paylaşacağım. Başlangıç olarak kitaptaki ilk madde olan statik fabrika metotlarıyla başlıyoruz.

Normal şartlarda bir sınıf kendisinden nesne oluşturulmasını istiyorsa public bir sınıf yapıcı (constructor) tanımlar ve diğer sınıflar bunu kullanarak nesne oluşturabilir. Ancak her yazılımcının bilmesi gereken başka bir nesne yaratma yöntemi daha var. Bu yöntemde sınıf, dönüş değeri kendi nesnesi olan statik bir fabrika metodu (static factory method) tanımlar ve bu sınıftan nesne oluşturmak isteyenler bu metodu kullanırlar.

Devamını Oku…

Birim Test Nedir? Niçin Yapılır? Nasıl Yapılır?

Pazartesi, 03 Mar 2014 yorum yok

Yıl olmuş 2014 hala birim test makalesi mi yazıyorsun diye düşünüyor olabilirsiniz. Ancak, birim testi uzun zamandır kullanılan bir yöntem olmasına rağmen tam olarak ne işe yaradığı, neden yapıldığı ve nasıl yapılması gerektiği konusunda açıklayıcı bir Türkçe yazı bulmak malesef zor. Bu yüzden, yazılım mühendisi adaylarına ve kariyerine yeni başlayan arkadaşlara faydalı olabilmek adına bu yazıyı yazmak uygun olur diye düşündüm.

Birim Testi Nedir?

Birim testi adından anlaşıldığı üzere yazılım birimlerinin test edilmesidir. Burada yazılım birimi dediğimiz şey ise test edilebilen en küçük yazılım bileşenidir. Nesneye yönelik programlama yaklaşımını ele alacak olursak, yazılım birimleri sınıflardır diyebiliriz. Yapılan şey basit olarak sınıf davranışlarının (metodlar) belirli girdiler sağlandığı zaman doğru bir şekilde çalışıp, istediğimiz sonucu üretip üretmediğini kontrol etmektir. Bu şekilde yazılımın küçük birimleri test edildiği zaman, bütünü oluşturan parçaların en azından kendi içlerinde çalıştığından emin olmuş oluruz. Buraya kadar söylediklerimiz birim testinin genel tanımıdır, ama yazılım geliştiren kişiler olarak asıl anlamamız gereken şey birim testini niçin yaptığımızdır.

Birim Test Niçin Yapılır?

Bu soruyu eminim ki birçok yazılımcı kendi kendine sormuştur. Bir kısmımız tam olarak neye hizmet ettiğini anlamasak da, faydalı olduğunu düşündüğümüz için ve kendimizi daha güvende hissetmek adına birim test yazarız. Bazılarımız ise birim test yazmanın faydalı olduğunu bilmemize rağmen çeşitli bahaneler üreterek birim test yazmaktan kaçarız. Bunun arkasındaki asıl sebep ise birim testlerin ve test odaklı yazılım geliştirme tekniğinin (test-driven development) asıl amacını kavrayamamış olmamızdır. Her şeyden önce şunu söylemek gerekir: Birim testleri yazılımları test etmek için yazılmaz. İsmi “birim test” olan bir yöntem için “asıl amacı yazılımları test etmek değildir” demek ilk başta çok mantıklı gelmeyebilir ama yazıyı okudukça bana hak vereceğinizi düşünüyorum.

Birim testler hata bulmak için değildir

Bir yazılım sistemindeki hataları (bug) bulmak birim testler ile mümkün değildir. Çünkü birim testlerin yaptığı iş yazılımın en küçük parçalarını kendi içerisinde test etmektir. Peki bu küçük parçaların kendi içlerinde çalışıyor olması, yazılımın gerçek kullanıcılar tarafından kullanılmaya başladığı zaman bir bütün olarak çalışacağını gösterir mi? Kesinlikle hayır. Bir yazılım sistemi, onu oluşturan parçaların toplamından çok daha fazlasıdır. Dolayısıyla bu bütünü test etmek için farklı yöntemler kullanmak gerekir. İşlevsel test (functional testing), bütünleştirme testi (integration testing) bunlara örnek verilebilir ancak konumuz birim test olduğu için bunlara değinmeyeceğim.

Hataları bulamıyorsa birim testler ne işe yarıyor?

Birim test yazmanın sağladığı gerçek fayda, bizi kaliteli kod yazmaya teşvik etmesidir. Peki bu nasıl olur? Öncelikle şunu söylemek gerekir ki, birim test yazmanın birinci kuralı test etmekte olduğumuz sınıfı, bağımlı olduğu diğer bütün bileşenlerden izole etmektir. Örnek verecek olursak, test ettiğiniz sınıfın bir Google servisine bağlanarak veri çektiğini düşünün. Ancak birim test esnasında bu sınıfın Google servisine bağlanıp veri çekmesini istemeyiz. Çünkü birim testin amacı yazılımın Google servisleriyle çalışabildiğini kanıtlamak değildir. Birim test yazarken, bağlantılı olduğumuz diğer bütün parçaların sorunsuz biçimde çalıştığını varsayarak yazarız, çünkü odaklandığımız şey sınıfın kendisidir, bağımlı olduğu diğer bileşenler değil. Bu varsayımı yapabilmek için de, mocking dediğimiz tekniği kullanarak test esnasında gerçek Google servisine bağlanmak yerine bizim yarattığımız sahte bir servise (mock object) bağlanıp sınıfın ihtiyacı olan veriyi döndürürüz.  Bu şekilde test ettiğimiz sınıf dışarıda bir servise bağlanmadan ihtiyacı olan veriyi alır ve işletimini tamamlar.

Şimdi test etmekte olduğumuz bu sınıfın dışarıdaki Google servisiyle sıkı sıkıya bağlı (tightly coupled) olduğunu düşünün. Sınıf Google servisiyle ilgili bütün bilgileri içinde barındırıyor ve bağlantıyı yaratıp kullanıyor, veri alışverişini yapıyor. Biz bu sınıfa gerçek Google servisine değil de bizim belirlediğimiz sahte servise (mock object) bağlanmasını nasıl söyleyeceğiz? Bu şekilde birbirine sıkıca bağlanmış yazılım bileşenlerini birbirlerinden bağımsız bir şekilde test etmek mümkün değildir. Ancak bu bileşenler gevşek bağlı (loosely coupled) olsaydı, biz sınıfımıza test esnasında sahte servisi, gerçek işletim esnasında ise Google servisini kullanmasını söyleyebilirdik. Bu şekilde yazılım bileşenlerini birbirlerine gevşek bir biçimde bağlamak Dependency Injection tekniğiyle mümkündür ve gevşek bağlı sistemler çok daha kolay bakım yapılabilen, test edilebilen ve eklemeler yapması çok daha kolay olan sistemlerdir.

Test odaklı yazılım geliştirme yapıyorsak (test-driven development), birim testleri sınıfın kendisinden önce yazmamız gerektiği için bu tarz tasarım detaylarını henüz işin başındayken doğru bir şekilde belirlemiş oluruz. Doğru biçimde birim test yazmak, yazılım bileşenlerini birbirlerine sıkı sıkıya bağlamamızı engelleyerek daha tasarım aşamasındayken daha kaliteli bir yazılım çıkarmamıza yardımcı olur. Özet olarak şunu söylemekte fayda var, bütün bileşenleri birbirinden bağımsız olarak test edilebilen yazılımlar, bakımı nispeten daha kolay olan ve kaliteli yazılımlardır. İşe birim testleri yazarak başlamak da bunu başarmamıza yardımcı olur.

Birim test yazmak kodda iyileştirme yapmayı (refactoring) kolaylaştırır

Birim test yazmanın bir diğer büyük faydası da kodda iyileştirme yaparken (refactoring) ortaya çıkar. Hiçbir kod mükemmel değildir ve iyileştirme her zaman bir ihtiyaçtır. Ancak birçok yazılımcı çalışan sistemi bozmaktan korktuğu için iyileştirme yapmaz. Ancak kapsamlı birim testleriniz varsa, değişiklik yaptığınız sınıfın hala çalışıp çalışmadığını anlamak için birim testlerinizi kullanabilirsiniz. Daha önce birim testlerin hataları bulmak için kullanılmadığını söylemiş olsak da iyileştirme esnasında üzerinde çalıştığımız sınıfı bozup bozmadığımızı anlamak mümkün olabilir. Dolayısıyla birim test yazmak sadece kodu yazarken kaliteli yazmaya teşvik etmekle kalmaz, aynı zamanda ileride kodu iyileştirmemize de yardımcı olur.

Doğru birim test nasıl yazılır?

Birim testin nasıl yazılması gerektiği de çok önemlidir. Doğru yazılmayan birim testler bize hiçbir şey kazandırmayacağı gibi en ufak değişiklikte hatalar vermeye başlayıp başımızı ağrıtırlar. Üstüne bir de testlere bakım yapmakla uğraşmak zorunda kalacağımız için de fayda sağlamanın aksine zararlı olabilirler. O yüzden birim test yazarken aşağıdaki noktalara dikkat etmekte fayda var:

  • Tek bir şeye odaklanınHer testin tek bir şeyi test ettiğinden emin olun. Çok gerekli değilse aynı test içerisine birden fazla assert ifadesi koymayın.
  • Bağımlılıkları (dependency) değil, tek bir sınıfı test edin: Yazıda daha önce de değindiğimiz gibi, bir sınıfı test ederken o sınıfı bağımlı olduğu diğer yazılım bileşenlerinden izole edin, aksi taktirde yazdığınız test birim test değildir.
  • Yazdığınız testler birbirini etkilemesin: Yazdığınız her test birbirinden bağımsız bir şekilde tek başına sorunsuz çalışabilmelidir. Eğer yazdığınız bir birim test başka bir birim testin üreteceği veriye bağımlıysa yanlış yapıyorsunuz demektir.
  • Testlerinizi doğru isimlendirin: Test sayısı arttıkça isimlendirmenin önemi de artar. Kafa karıştırıcı test isimleri kullanmak ileride problemlere yol açar. Açıklayıcı olması için test isimlerini uzun tutmanız gerekiyorsa öyle yapın, uzun isimler yanlış isimlerden daha faydalıdır.
  • Test koduna ikinci sınıf kod muamelesi yapmayın: Testler de yazılımın bir parçasıdır. Dolayısıyla normal program kodunu yazarken ne kadar özen gösteriyorsanız test kodlarına da aynı özeni gösterin, kod tekrarlarından kaçının, okunabilir test kodu yazın.

Bir Yazılım Mühendisinin Hayatı – Bölüm 2

Perşembe, 21 Mar 2013 2 yorum

İkinci bölümle devam ediyoruz. Birinci bölüm için buraya tıklayın.

Üzerinde saatlerce çalıştığımız bir scripti ilk defa çalıştırmayı denediğimiz zaman:


Devamını Oku…

Bir Yazılım Mühendisinin Hayatı – Bölüm 1

Perşembe, 21 Mar 2013 yorum yok

Yazılım mühendislerinin hayatına bir de böyle bakın.. Bu tarz şeyler yaşamıyorsanız gerçekten bir yazılım mühendisi olup olmadığınızı sorgulayın derim :)

Google’da arama yapmadan bir problemi çözdüğümüz zaman:


Devamını Oku…

Redgate SQL Search Plugin

Çarşamba, 09 Oca 2013 yorum yok

SQL Server Management Studio 2008 kullanarak veritabanınızdaki bütün tablolar veya saklı yordamlar (stored procedure) içerisinde bir metin aramanız gerektiği zaman yapamadığınızı anlamak uzun sürmüyor. Benim de bugün bütün stored procedureları taramam gerektiğinde üçüncü parti yazılımlara yöneldim Redgate firmasının geliştirdiği SQL Search Pluginini buldum. Plugin SQL Server Management Studio içerisine entegre oluyor ve veritabanınızdaki bütün objeleri arayıp metin bulmayı çok kolaylaştırıyor. Oldukça başarılı olan bu eklenti aynı zamanda bedava. Mutlaka deneyin..

http://www.red-gate.com/products/sql-development/sql-search/

C# – Using Anahtar Kelimesi ve Kullanımı

Perşembe, 03 Oca 2013 9 yorum

C# dilinde “using” anahtar kelimesi iki farklı şekilde kullanılmaktadır. Bunlardan birincisi isim uzaylarını (namespace) koda dahil etmek veya isim uzayları ve türlere başka isimler vermek için kullandığımız using bildirimi, ikincisi ise IDisposable arayüzünü gerçekleştiren nesnelerin doğru bir biçimde ele alınmasını sağlayan using ifadesi. Bu kullanımların her ikisini de örneklerle açıklamaya çalışacağım.
Devamını Oku…

%d blogcu bunu beğendi: