Java ve İlişkiler

Nesne yönelimli programlama dersinin asistanlığını yapıyorum. Bu bağlamda sorular geliyor. En son Nesne Yönelimli Programlama'da Association, Composition ve Aggregation kavramları soruldu. Bu kavramları kodumuzda kullanıp kullanmadığımızı nasıl anlarız? Bu soruyu ortada bırakmak şartıyla, bu kavramların tanımlarını yapmaya çalışayım.

Association (Birliktelik): İki sınıf arasındaki yapısal ilişkiye verilen isim. Herhangi bir dereceye sahip olacak şekilde aralarında ilişki bulunan sınıflar bu birlikteliğe sahip olurlar. UML gösteriminde düz bir çizgi ile temsil edilmektedir. Bu ilişki bize o iki sınıf arasında mesaj alışverişini sağlayan bir kanalın olduğunu anlatır. Burada Java'da mesaj alışverişinin metot çağrımlarıyla gerçekleştiğini hatırlatmak gerekir. Birliktelikler genellikle referanslar ile gerçekleştirilir.

Aggregation (Münasebet): "Sahip olma" ("possession") ilişkisini temsil eden özel bir birlikteliktir. Dairesel olmama koşulu vardır. Bunun anlamı nesne kendisiyle münasebet kuramaz. Bu yüzden münasebet çizge değil, ağaç yapısı oluşturur. Aggregation "has-a" ilişkisidir. Her iki nesne de kendi bağımsız varoluşlarına sahiptir.

Composition (Oluşum): Sahiplik ("ownership") modellemesi için kullanılan özel bir birliktelik türüdür. Aggregation'a benzer ama tek farkı Bütün-Parça ilişkisini temsil etmesi ve parçanın kendi bağımsız varlığına sahip olmayışıdır. Bütünün varlığını temsil eden nesne ayrıca parçanın da yaşamından sorumludur. Oluşum "contains-a" ilişkisi olarak anlaşılmalıdır. Münasebete benzer olarak oluşum da Ağaç yapısı oluşturur, çizge değil ve dairesel olamaz.

Aggregation-Composition arasındaki farklar

• Aggregation "has-a" (var) ilişkisidir, Composition "contains-a" (içerir) veya "bütün-parça" ilişkisi
• Aggregation'da iki nesne de kendi bağımsız varoluşlarına devam ederler, Composition'da parça'nın ömrü bütün nesnesiyle temsil edilir.
• Composition'ın daha güçlü ilişki olmasına karşın Aggregation daha gevşek bir ilişkidir.
  
• UML'de Aggregation işi boş köşegen ve düz çizgi, composition dolu köşegen ve düz çizgi ile gösterilir.
• Composition ilişkisindeki "parça"nın sadece bir "bütün"ü olabilir. Aggregation kapsanan tarafta 0..* derecesine sahip olabilir.

Bir bağlantıda Araba örneği üzerinden Composition ve Aggregation arasındaki farkı şöyle anlatıyordu:

Bir örnek Arabadır. Araba Parçalarından oluşur. Bu parçalara sahiptir. Eğer bir Parça yoksa araba bozuktur. Araba Parçalarıyla Composition oluşturur.

Ayrıca Arabanın Yolcuları vardır. Yolcular Arabanın Parçası değildir. Eğer bir Yolcu yoksa Araba bozuk değildir. Araba Yolcularına sahip değildir. Araba'da değillerse başka bir yerdedirler. İlişki geçicidir. Yolcular gelir ve gider. Araba ve Yolcular arasında Aggregation ilişkisi vardır.

Her iki ilişki aslında compositiondır. Arabanın hem Parçaları hem de Yolcuları vardır. Farklılık süresindedir. Parçalarla olan ilişki daimidir, Yolcularla olan ilişki geçicidir.

Kaynaklar:
http://faq.javaranch.com/view?AssociationVsAggregationVsComposition
http://ootips.org/uml-hasa.html
http://www.javaworld.com/javaworld/jw-06-2001/jw-0608-java101.html
http://geekexplains.blogspot.com/2008/07/composition-vs-aggregation-whats.html
http://www.bilgisayarkavramlari.com/2008/12/20/birliktelik-munasebet-ve-olusum-association-aggregation-and-composition/
http://stackoverflow.com/questions/1384426/distinguishing-between-delegation-composition-and-aggregation-java-oo-design
http://www.coderanch.com/t/468736/Java-General/java/Aggregation-Java

DISTINCT yerine IN veya EXISTS

SQL cümlelerinde JOIN kullanımı sonucu tekrarlayan kayıtlar ile karşılaştığımız oluyor. Bunları tekil hale getirmek için DISTINCT kelimesini kullanabiliriz(1), ancak distinct sıralama ve filtreleme işlemi yapacağından sorgunun performansını azaltacaktır.
DISTINCT kullanmak yerine mümkünse JOIN ifadesinde kullanılan tablo ve koşullar ayrılarak altsorguya dönüştürülebilir, aranan değere ulaşmak için performansı bu tür durumlarda JOIN den daha yüksek olan IN veya EXISTS kullanılabilir(2).

(1)
select distinct m.musteri_no
from tbl_musteri m
join tbl_hesap h
on h.musteri_no = m.musteri_no
and h.kayit_durum = 'A'
and m.musteri_no = 123456

(2)
select m.musteri_no
from tbl_musteri m
where exists (select h.musteri_no
from tbl_hesap h
where h.musteri_no = m.musteri_no
and h.kayit_durum = 'A')
and m.musteri_no = 123456

Özgür Yazılım Göçleri

Dünya yavaş yavaş özgür ve açık kaynak kodlu yazılıma geçiyor. İtalya'da yapılan bir ankete göre şirketlerde %50 OpenOffice.org, %63 GNU/Linux kullanılıyor. Ayrıca dün okuduğum bir habere göre Fransa'da Ö/AKK yazılıma geçiş yaşanıyor, Mono bile kullanılmamak üzere kaldırılıyor.

Basit kod için 7 kural (KISS - Keep It Simple Stupid)

Basit kod geliştirmenin 7 adet ölçütünden bahseden bir yazı buldum. Yazıyı ayrıca okuyabilirsiniz. Özetle bu 7 özellik şunlar:

1. Okunması kolay olmalı
2. Kullanımı kolay olmalı
3. Değiştirmesi kolay olmalı
4. Gereksiz yere üçüncü parti kütüphane, araç veya teknoloji kullanmamalı
5. Basit görünmeli
6. Zarif olmalı (sadece gerekli olanı yapmalı, fazlasını değil, az ve öz olmalı)
7. Dobra olmalı (gereksiz yere yönlendirmeler içermemeli)

Bu özellikler tartışılabilir, ama yazılım geliştirirken bir şeyi unutmamak lazım. Kaynak kodun genişletilebilir, değiştirilebilir, güncellenebilir ve anlaşılabilir olmasıdır.

Aynı yazıda ayrıca önemli bir vurgu yapılmış. Bu vurgu basit kodun geliştirilebilmesi için sürekli sınama ve sürekli yeniden yapılandırmanın (refactoring) yapılması (zaten sürekli yeniden yapılandırma yapıyorsanız sürekli sınama da yapmanız ve dolayısıyla bol bol testlerinizin olması gerekir, bu noktada birim testler devreye girer) gerektiğidir.

JUnit 4

Bir aralar, yüksek lisansa ilk başladığımda aldığım bir ders sonucu Test güdümlü yazılım geliştirme konusuna merak sarmıştım. Ders kapsamında da test güdümlü yazılım geliştirme yöntembilimi yardımıyla yaptığımız bir proje ödevimiz de vardı. Önce testleri yazıyorduk, sonra testleri doğrulayacak kodlarımızı. Oldukça hoş, naif ve kolay bir yöntembilimdi. Gerçi testleri yazarken testlerin nasıl yazılması gerektiği, neyin sınanıp sınanamayacağı konularını irdelemek bir tecrübe gerektiriyordu.

Testler için Java'ya yönelik olarak JUnit aracını kullandık. JUnit 3. sürümü kullanılıyordu. Üzerinden 2-3 yıl geçti. Ondan sonra arkadaşlarla yapmaya çalıştığımız bir kalıcı katman gerçekleştirimi esnasında da bu yöntembilimden yararlandık ve bazı arkadaşlara öğrettik, beraber kendimizi geliştirdik. Aradan geçen yıllarda önce test yaklaşımı alışkanlığımı kaybettim, artık Python'a kaymak gibi tercihlerim oldu ve Java geliştirmesinde büyük yazılımlarla uğraşmadığım için testleri yazmadan çalışan kod üretme yaklaşımını benimsedim. Uzun zamandır çok büyük bir projeyle uğraşmamamın da etkisi vardır. Ağırlığı teorik kısma verince sonuç bu oluyor :)

Yazmaya başlayınca iyice uzatıyorum. Aslında JUnit'in 4. sürümünde kolaylaşan test yazımlarından bahsedecektim. Ve herkese Test güdümlü geliştirmeyi araştırması, öğrenmesini önerecektim. Yazı geçmişten bahsetmeye başladı (yazı mı ben mi) :)

JUnit'in 4'ün en önemli getirisi "annotations" (Türkçesi: dipnot, not, açıklama teknik karşılığını bilmiyorum). Böylece çok kolay bir şekilde testleri yazabiliyorsunuz. Örnek verelim:

@Test public void simpleAdd() {
Money m12CHF= new Money(12, "CHF");
Money m14CHF= new Money(14, "CHF");
Money beklenen= new Money(26, "CHF");
Money sonuc= m12CHF.add(m14CHF);
assertTrue(beklenen.equals(sonuc));
}

@Test ifadesiyle bu metotun bir test metotu olduğunu belirtmiş oluyoruz, assertTrue ile de sınamamızı yapıyoruz.

Bu kadar kolay. Sınayacağınız sınıf içerisine de yazabileceğiniz gibi ayrı bir test sınıfı da kullanabilirsiniz.

Not: Python için unittest var
Kaynak: JUnit Cookbook,JUnit

IBM’de Sendikal Haklara Saygı İstiyoruz!

BASIN AÇIKLAMASI:

TARİH :21 EKİM 2009 ÇARŞAMBA

SAAT :12.30-13.00

YER :BÜYÜKDERE CADDESİ YAPI KREDİ PLAZA ÖNÜ B BLOK LEVENT / İST.

2008 yılının Şubat ayından bu yana IBM işyerinde Sendikal mücadelemiz devam etmektedir. IBM işyerinde örgütlenip çoğunluğu almamıza rağmen işveren hem çoğunluğumuza hem de işkoluna itiraz ederek çalışanlarının Anayasal haklarını kullanmalarına engel olmak istemiştir. Diğer taraftan işyerinde sendikal örgütlenmeyi yürüten arkadaşlarımızı işten atarak, sendika düşmanı tutumunu devam ettirmiştir.

IBM işyerinde hem hukuksal hem de demokratik ve meşru mücadelemiz devam etmektedir.

Ancak bu sefer de işverenin yeni bir oyunu ile karşı karşıyayız. IBM işvereni notere sendikadan istifa formu bırakarak üyelerimizi istifaya zorlamakta ve işten atma ile tehdit etmektedir.

IBM’in bu tavrını kınamak, ve mahkemelerde yaşananları basına ve kamuoyuna duyurmak için 21.10.2009 ÇARŞAMBA günü IBM önünde basın açıklaması yapacağız.

Basın açıklamamız, tüm genel merkez yöneticilerimizin katılımıyla genel başkanımız Sn. Gürsel Doğru tarafından yapılacaktır.

TÜM EMEK DOSTLARINI BASIN AÇIKLAMAMIZA DESTEK VERMEYE ÇAĞIRIYORUZ.

TEZ-KOOP-İŞ SENDİKASI

İSTANBUL 5 NO’LU ŞUBE

İklim Değişimi

Dünyada sıcaklar, soğuklar, seller, felaketler artmış durumda. Neden olarak dünyanın insanın yarattığı çevre felaketinin ortaya çıkardığı iklim değişimi söyleniyor. Ne kadar doğrudur bilinmez, gerçekten bir iklim değişimi var mı yoksa yok mu. Bir şeylerin ters gittiği kesin. İnsanlık kapitalizmin barbarlığını daha açık bir şekilde görüyor. Bir taraftan aşırı üretim-tüketim çılgınlığı nedeniyle çevre felaketini ortaya çıkaran sistemin kendisi artık kendisini, dünyayı ve insanlığı tüketmiş durumda, tüketmeye devam ediyor. İnsanlar bir avuç zengin için çalışıyorlar, sömürülüyorlar ve ölüyorlar. Bir kadının (kadınlarla bir zorum yok, aklıma gelen ilk örnek olduğu için veriyorum) makyaj (hadi aşırı makyaj diyelim :) ) masraflarıyla binlerce insanın açlıktan ve hastalıklardan kurtulacağına inanıyorum. İnsanlar sistemin vardığı barbarlık düzeyinde kendilerinden başka hiçbirşeyi düşünmüyor, dünyayı sadece kendilerine ait sanarak sınırsız tüketiyorlar. Bu arada bu tüketim hırslarından dolayı kendi sonlarını, en azından insanlığın sonunu getirdiklerini de bilmiyorlar. Bu noktada Sinan'a sorsam, insanlık zaten öldü, bir avuç insan kaldık Aşık Veysel dinleyen diyecektir. Haklıdır, insanlık öldü, ölmeye devam ediyor. Can çekişiyor.

İklim değişiminden bahsedecektim ama insanlığa geldi söz. Bence insanlığın kurtulması için ciddi bir "iklim değişimine" ihtiyacımız var. Eyleme geçen, hakkını arayan, insanlığı için mücadele eden insanları ortaya çıkaracak olan "iklim değişimine". Yazıyı uzatmıyorum, "insanlık"a olan umudumu yitirmeden "iklim değişimi" için herkesi uyanmaya çağırıyorum.


Not: Bu yazı Blog Action Day kapsamında yazılmıştır.