örneğin yaptığımız bir tasarımda şöyle bir ihtiyacımız var, bir timer'ımız (sayaç diyelim) var ve bu timer'ın değeri sürekli güncelleniyor, farklı sınıfların bu timer'ın anlık değerine ihtiyacı var, dolayısıyla timer sınıfının ürettiği değerlerin tüm diğer sınıflar tarafından erişilebilmesi gerek, bu noktada bir kaç alternatif çözüm var, OOP olarak bakarsak en uygun çözüm ne olur

  • timer sınıfının sayaç değişkenini "static" ya da diğer paketlerden de erişilecekse "public static" yaparız ve erişiriz
  • bu tarz projenin bütününde anlam ifade eden variable'ları ayrı bir sınıfta "public static" olarak bir araya toplayıp oradan erişiriz
  • normal bir sınıf yaparız ama singleton olur, proje genelinde geçerli setleri bu sınıftaki field'larda tutarız ve diğer sınıflar bu sınıfın instance'ını alıp oradan ortak setlere erişirler (gerçi bunu pek beğenmedim, static sınıf ile aynı oluyor zaten)

veya başka daha şık bir önerisi olan var mı böyle durumlar için, yani projenin konfigürasyon setlerini OOP de nasıl bir mantık ile tutmak gerek, ya da anlık değişen ama bir çok sınıfın zaman zaman erişmesi gereken değerleri proje genelinde nasıl tüm ilgili (farklı paketlerde de olsalar) sınıfların erişebileceği şekilde tutarız

ben genelde konfigürasyon ayarları için :

public final class Configuration
{
    public static String DB_NAME = null;
    public static String DB_USERNAME = null;
    public static String DB_PASSWORD = null;
    public static String DB_SERVER = null;

    private Configuration()
    {
    }

    static
    {
        try
        {
            Properties prop = new Properties();
            InputStream ins = Configuration.class.getResourceAsStream(CONF_FILE_PATH);
            prop.load(ins);
            ins.close();
            DB_NAME = prop.getProperty("DB_NAME");
            DB_USERNAME = prop.getProperty("DB_USERNAME");
            DB_PASSWORD = prop.getProperty("DB_PASSWORD");
            DB_SERVER = prop.getProperty("DB_SERVER");
        }
        catch(IOException ex)
        {
            System.exit(1);
        }
    }
}

sonra da Configuration.DB_NAME v.s. diyerek erişiyorum (late binding).

Bu yöntem OOP açısından uygun bir yöntem midir?

soruldu: 05 Haz '12, 07:27

nht's gravatar image

nht
95651720
cevap kabul oranı: 33%

değiştirildi: 05 Haz '12, 07:46

%C3%B6zcanacar's gravatar image

özcanacar ♦♦
17.2k59183183


Timer sinifini static bir metoda erisim seklinde ya da singleton olarak tasarlarsiniz, kodun bircok yerinden bu sinifa bagimlilik olusacaktir. Timer sinifinda meydana gelen her türlü degisiklik diger siniflarin yerniden derlenmesini gerektirir. Bu sekilde kodunuz daha kirilgan bir hal alacaktir. Bu sebepten merkezi bir sinifin kullanimi tavsiye edilmez. Bunun yanisira static bir metodun ya da singleton sinifin test edilmesi cok zordur. Ayrica kodunuz Timer sinifina bagimli oldugu icin, bu sinif olmadan tekrar kullanimi imkansizdir. Sizin kodunuz nereye giderse, Timer sinifi da oraya gitmek zorundadir.

Bunun yerine Timer sinifina ihtiyac duyan sinifa, Timer sinifindan bir nesnenin enjekte edilmesi daha esnek bir cözümün olusmasini saglar. TImer'in bir interface oldugunu düsünürsek, istedigimiz türde bir implementasyonunu diger siniflara enjekte edebiliriz. Bu sekilde Timer sinifinin implementasyonlarinin ve kullanici siniflarin test edilmesi daha kolaylasir.

sonra da Configuration.DB_NAME v.s. diyerek erişiyorum (late binding).

Bu late binding degildir. Static olan bir degiskene deger atamasi yapiyorsunuz. Verdiginiz örnegi test etmek cok güctür. Singleton oldugu icin new ile bir nesne olusturmak zordur. Ayrica static blogu icinde test edenin kontrol edemeycegi bircok islem yapilmaktadir. Bu ayrica testleri zorlastiran bir durumdur.

EOF (End Of Fun) Özcan Acar

permanent link

cevaplandı: 05 Haz '12, 07:45

%C3%B6zcanacar's gravatar image

özcanacar ♦♦
17.2k59183183
cevap kabul oranı: 52%

late binding ile ilgili bir ifade hatası yapmışım, polymorphism'de geçerli olan bir durum o, buradakine ancak late initialization diyebiliriz belki :)

peki bu tarz konfigürasyon bilgilerini kullanmak isteyen her metod

new Configuration().getDBName() v.s. gibi bir yapı mı kullanması gerek, burada bir dosyada konfigürasyon bilgilerinin tutulduğunu varsayarsak her seferinde file I/O yapacağız, çok sıklıkla kullanıyor olabiliriz bu konfigürasyon bilgilerini bu açıdan bakarsak yine de instance mı oluşturmalıyız

(05 Haz '12, 08:08) nht nht's gravatar image

Timer'i kullanmak istediginiz herhangi bir sinifa, konstrüktörü araciligi ile Timer sinifinin bir nesnesini verebilrisiniz. Bu durumda isterseniz new ile yeni bir nesne olusturursunuz ya da bir factory üzerinden olusturdugunuz tek bir singleton nesneyi kullanirsiniz. Timer'i kullanan sinif sadece Timer interface'ini tanir, ama konstrüktörü üzerinden Timer'in herhangi bir alt implementasyonu olan bir sinifin nesnesini alabilir. Böylece bagimlilik sadece Timer interface sinifina olmus olur.

(05 Haz '12, 08:28) özcanacar ♦♦ %C3%B6zcanacar's gravatar image

Konfigürasyon bilgilerini tutan sınıfı da tüm kullanan nesnelere constructor'dan geçmek mi gerekiyor

(05 Haz '12, 08:58) nht nht's gravatar image

Konstrüktör olabilir ya da bir setConfig() metodu olabilir.

(05 Haz '12, 09:11) özcanacar ♦♦ %C3%B6zcanacar's gravatar image
Cevabınız
toggle preview

Bu soruyu takip et

E-Posta üzerinden:

Üyelik girişi yaptıktan sonra abonelik işlemlerini yapabilirsiniz

RSS üzerinden:

Cevaplar

Cevaplar ve Yorumlar

Yazı Formatlama

  • *italic* ya da _italic_
  • **bold** ya da __bold__
  • link:[text](http://url.com/ "başlık")
  • resim?![alt text](/path/img.jpg "başlık")
  • liste: 1. Foo 2. Bar
  • temel HTML etiketleri de kullanılabilir

Bu sorunun etiketleri:

×1,079
×13

Soruldu: 05 Haz '12, 07:27

Görüntüleme: 863 kez

Son güncelleme: 05 Haz '12, 09:11

powered by BitNami OSQA