fazlamesai.net'e Soralım: Getter ve Setter Şeytani Mi?

anonim
26 Haziran 2006 , 1 dakika okuma süresi

Linux-programla listesinde Nesne Tabanlı Programlama ile ilgili bir mesaj dizisini okurken Java'da sürekli kullanılan "getter/setter"larla ilgili bilgimi tazelemek istedim. Karşıma bir hayli ilginç makaleler çıktı...

Örneğin bu makalede getter ve setterların kullanımının sakıncalarına değinirken burada da " Do getter/setter methods violate OO? " başlıklı ilginç bir tartışmaya rastladım.

Ve FM'nin deneyimli programcılarına sormak istedim. Sizce getter ve "setter"lar şeytani mı?

fazlamesai.net

Görüşler

Tarık
18 yıl önce

bir mevzu java ile uzaktan yada yakından ilintiliyse kesinlikle hiçbirşeyinde şeytanilik yoktur. Java herkesin anlayacağı ve derinlere inemeyeceği, usta programcılara hiçbirşey öğretemeyecek sığ bir dildir. Evet usta programcı deilim sadece duygusal anlamda java dan nefret ediyorum. JAVA bir balondurrr habareyyy.

ahmetaa
18 yıl önce

Usta programcilik karmasik ya da anlasilmasi zor dil ozelliklerini kullanmak degildir.. Aksine, karmasik dil ozelliklerini kullanmak ozellikle takim calismasi ile yurutulen ve uzun sure bakim gerektiren uygulamalarda son derece sakincalidir.

Tarık
18 yıl önce

Olayı herhangi bir projenin kapsamı dışında düşünüyorum. Uzun süreli, takım çalışması gerektiren, bakımı uzun süren projelerden bahsetmiyorum.

innaw
18 yıl önce

Neden bu kapsam disinda dusunuyorsunuz ki? Bu cabaya hic gerek yok.

innaw
18 yıl önce

Şahsen, Java dilini ben de pek sevmiyorum.

Ama bir platform olarak Java'nin (JVM) sunduklari gozardi edilemez. Cevresindeki yazilim muhendisligi ekosistemi de cabasi.

Maalesef kacirilan nokta hep ayni oluyor. Java dilinin söz diziminden hazzetmeyip platformu "harcamak", pireye kızıp mahalleyi yakmaya benziyor.

Tarık
18 yıl önce

Hayır kesinlikle, platformun yada platformların(.NET, Java) hiçbirine kesinlikle karşı değilim karşı tez üretecek bir uzmanlığım yok. Fakat bu yeni yetme platformların benim gibi köhnemiş insanlara "derlenmiş programlardan bile daha hızlı çalışırız, herşeyi biz yaparız sende gel buraya işini illaki bizimle yap yoksa geride kalıyorsun" dayatmasını sevmiyorum. Platform bağımsızlığı, kodlama kolaylıkları, diller üstü yenilikleri, binlerce insanın destekliyor olması her taraftan java, c# kaynağı fışkırıyor olması benim için pekte önemli değil. Bir gün bu işten soğuyacaksam oda işimde java yada c# kullanmaya başladığım zamana denk gelecektir eminim. Kişisel dertlerimin yanısıra. İnsanlara herşeyin ilacı olarak ilk önce temel programcılık, sistem işleyişi değilde java, c# kullanmalarının öğütlenmesi çok .oktan bi durum bence. Ki bu işi daha gelişimine başlayamamış bir ülkede yapıyorsanız insanlar daha C, Assembley gibi temel üretim dillerinin ne olduğunu bilmiyorsa, hainlik ediyorsunuz demektir. Zira ben programlama dili, işletim sistemi gibi fantezileri gerçekleyebilmek için bu ülke insanlarınında tüm dünya programcılarının geçtiği yolları en azından bilmesi gerekliliğine inanıyorum. Buda insanları önce Java'ya sevk etmekle olmaz sanırım. Ama dikkatle görüyor ve düşünüyorum ki bir Java,.net dayatmasıdır gidiyor. Neyse bunlar benim düşüncelerim. saygı sevgi GNU/Linux .

innaw
18 yıl önce

Soyledikleriniz olayin sosyal tarafi ve dusuncelerinize kesinlikle katiliyorum. Ama teknolojinin bu yanlisliklarda ne gibi bir kabahati olabilir ki?

Tarık
18 yıl önce

Dediğim gibi aslen dilin yada platformların değil bunları satarak para kazanma arzusunda olan üreticilerin itici "albeni kullan beni, başkada bişey arama" politikası, dolayısıyla işin tamamı beni negatif düşüncelere sevk ediyor. Yoksa tövbe, java' yı , .net'i, Ruby' i bilmem neyi geliştiren ustaların başımız üstünde yeri var :d

bio
18 yıl önce

Birincisi, tartisma Java'daki getter/setter'lar ile kisitlanmamis. Her turlu "accessor" kullanimina, encapsulation prensibine aykiri oldugu icin, karsi olma durumu soz konusu.

Ikincisi, ben bu derece "pürist" yaklasimlarda bulunanlarin gercek bir proje gerceklestirip gerceklestirmediklerinden suphe duyuyorum. Nesne yonelim konusunda bu kadar teorik dusunursek, yuzlerce abstract class, interface, delegation yapmaktan, asil isi yapacak kodu yazmaya yer bulamayiz.

JavaWorld'deki makaledeki "diyelim ki property'nin tipi ileride int'ten long'a degisti" ornegini de eksik buluyorum. Bu tur bir degisiklik zaten sadece property'leri degil, method signature'lari, boundry check'leri de degistirir, basli basina bir sorundur. Accessor kullansak n'olur, kullanmasak n'olur?

Acikcasi bence bu tur maintainability sorunlarina onceden hazirlikli olmanin garantili bir yolu yok. Zaten bu yuzden modern IDE'lerin hepsinde refactoring ozellikleri bu kadar gelismis durumda.

ahmetaa
18 yıl önce

IDE refactor ozellikleri inanilmaz guclu olsa bile ne yazik ki property tip donusumu konusunda oldukca yetersizler halen. Sanirim bunun nedenlerinden birisi otomatik olarak int->long donusmunu kestirmenin her zaman kolay olmamasi. Ya da otomatik donusum sonrasinda sistemde derleme hatalarinin olusmasi kacinilmaz olabilir (down-up casting nedeniyle..) Genede yazarin o konuyu abarttigi konusunda katiliyorum.

newman
18 yıl önce

Bence siz bu makaleyi yanlis anliyorsunuz. Adam genel olarak getter/setter karsiti filan degil. Sadece bunun cok kez kolaya kacilarak yersiz ve asiri kullanildigini vurguluyor. Ayrica tum makaleyi ozetleyen cok da yerinde bir tespit olarak su cumleye dikkat edin:
don't ask for the data that you need to do something; rather, ask the object that has the data to do the work
Makalenin javayla sinirli olmadigi da son derece dogru. OO paradigmayla modellenmis bir cozum kullanilacaksa bu duzgun yapilmali. Problem su ki: OOP tekbasina herzaman dogru veya en verimli cozum olmayabilir. OO paradigmanin yetersiz kaldigi veya daha soyut ve nesne sinirlarini yatay kesen bir yaklasima ihtiyac duydugu durumlar kolaylikla dusunulebilir. Bu durumlara zaten deginilmiyor -- konu disi onlar. Fakat ilginc olarak, iyi bir OOP dizayn, functional paradigmaya oldukca yaklasabilir: tipki insanoglunun fizik dunya ile matematiksel soyutlamayi atbasi kosturdugu gibi (ve bu ikisi birbirini hayret verici bir duzeyde geri besledigi gibi) bu iki paradigma birlikte oldukca yararli olabilir.

bio
18 yıl önce

> Adam genel olarak getter/setter karsiti filan degil.

Ne kadar karsit oldugunun derecesi mechul:

"Using accessors violates the basic object-oriented (OO) principle of encapsulation, so you should avoid them."

"You shouldn't use accessor methods (getters and setters) unless absolutely necessary"

Her neyse, zaten onemli olan adamin ne derece karsit oldugu degil; hakli olup olmadigi. Benim nacizane sahsi gorusum, "accessor'larin OO prensiplerine aykiri oldugu ve kullanilmamasi gerektigi" gorusunun biraz abartili oldugu seklinde.

newman
18 yıl önce

Yok yok, mechul degil :), makeleyi baska bir gozle ve devaminda yapilan yorumlara adamin verdigi cevaplari okursaniz bana katilirsiniz sanirim. Yalniz adamin uslubu abartili yer yer. Yazi yeterince nezaketli ve olculu yazilmamis: boyle seylere cokca rastlamak mumkun. Biraz nasihat verir gibi olmus, tabii bu da mesajin alinmasini engellemis. Zaten yorumlarda da bunu gormek mumkun. Mesela ben yazinin ana icerigine tamamen katiliyorum, fakat ilk okudugumda bile yaziyi sosyal olarak kiskirtici buldum.

FZ
18 yıl önce

Ayrica tum makaleyi ozetleyen cok da yerinde bir tespit olarak su cumleye dikkat edin: don't ask for the data that you need to do something; rather, ask the object that has the data to do the work

Zannımca yukarıdaki cümleyi hakkıyla anlayan kişi çok şey anlamış olur. Gerek Java, gerek C#, gerekse benzer diğer OOP dillerini kullananların sürekli akılda bulundurmaları gereken bir cümle.

ahmetaa
18 yıl önce

ozellik erisim metodlarinin "seytani" olarak nitelendirilmesi abartili. ama bu metodlarin gereksiz ya da yanlis kullanimi sakincali. Ornegin pek cok sinifi "immutable" yani degistirilemez yapmanin buyuk faydalari vardir (Thread-safety, guvenlik). Bu durumda sinif degiskenlerini degistirilemez yapip tekil bir constructor ile ilklendirilmesine izin verip sinif parametrelerine sadece "okuma" erisimi - o da gerekiyorsa- (getter) vermeniz gerekir. Yani gelistiricinin hemen sinifa sarilip aman hemen get-set metodlairi ureteyim su IDE ile demesi yanlis.

Fakat bazi durumlarda (ornegin ORM uygulamarinda) bu genellikle onerilen bir sey oldugundan genellile bur metodlar yazilir, ya da ozellikler "public" ya da package-visible tanimlanabilir..

setter kullaniminin sIkca yapildigi bir yer bazen siniflarin olusturulmasinin dis veri erisimine bagli olmasi. zemberek projesinde acikcasi o konuda biraz muzdaripiz. Ornegin harflerin ya da eklerin cesitli ozellikleri bir dis dosyadan okunuyor. Ve yeni bir ek olusturulacaginda "set" medodlari kullaniliyor. Bu, caisma aninda bu degistirilemez olmasi gereken nesnelerin degistirilmeye acik olmasina neden oluyor. Birisi alakasiz bir yerde 'a' harfini sessiz harfe donusturebilir yani. Bunu engellemek icin cok parametreli constructor kullanilabilir ancak bu da oldukca rahatsiz edici ya da mumkun olmayabilioyor. 10 parametreli bir constructor dusunun. Gecenlerde okudugum Joshua Bloch'un "Effective Java reloaded" sunumunda bu durumda kullanilmasi onerilen "Builder" Patterni onerilmis. Basitce su sekilde, sinifin icine bir adet "Builder" ic sinifi koyuluyor. Bu nesne icinde gercekten set metodlari var ve bu medodlar gene olusmakta olan Builder nesne referansini donduruyor. Bu sekilde cok parametreli bir sinifi su sekilde olusturabiliyorsunuz:

NutritionFacts twoLiterDietCoke = new NutritionFacts.Builder("Diet Coke", 240, 8).sodium(1).calori(0).build();

Yani setter ya da cirkin constructor olmadan gayet zarif bicimde sinifimizi turetebiliyoruz. Bu yapiyi, eger uyarsa zemberek icindeki degismez siniflara uyarlayacagim. sunumu suradan indirebilirsiniz, icinde ilginc baska konular mevcut.. Effective Java Reloaded

newman
18 yıl önce

Bu son yazdiginiz sey bana Ada, Common Lisp, ve belki baska dillerdeki "named parameter" tarzini hatirlatti. Bunu degisik sekillerde emule etmek mumkun. Mesela C programcilari bunu bir struct olusturup (hafizayi default degerler icin sifirlayarak tum alanlari her zaman doldurma zahmetinden kurtulmak mumkun) Factory fonksiyonuna parametre olarak geciyorlar. Baska bir alternatif, duzenli olarak constructor metodlarina bir "Property" listesi gecirmek olabilir. Bu da cok parametreli constructor'leri onleyebilir. Sizin yazdiginiz da zarif bir metod. Acaba benim goremedigim bir avantaji var mi bunun disinda? (Gorebildigimi yazdim zaten, eger burada yoksa demek ki gorememisim :)). tesekkurler.

ahmetaa
18 yıl önce

Bu yapi daha cok degistirilemez siniflar icin dusunulmus saniyorum. Dediginiz gibi aslinda bunun statik sinif factory metoduna (ya da constructor'a) parametreleri tasiyan bir nesne yollayarak ana nesnenin olusturulmasindan pek farki yok. Guzelligi olusturma isleminin farkliligi (parametrelerin arka arkaya ulanmasi ve build() metoduyla ana sinifin uretilmesi). Ortada ana uretilecek sinifin constructorundan ve uretilecek sinifin icindeki bir factory metodundan eser yok.

newman
18 yıl önce

Ben de oyle dusunmustum. En son nokta haricinde katiliyorum:
Ortada ana uretilecek sinifin constructorundan ve uretilecek sinifin icindeki bir factory metodundan eser yok demissiniz. Dogru, ancak kullanilan nested sinif yuzunden, gerekli parametreleri alan Builder(...) constructor'ini siz bir static Factory metodundan ilk bakista ayirdedebiliyor musunuz? Tek farki baska bir sinif olusturmasi ve isimlendirme konvansiyonu sayesinde "Aha, buyuk harfle basladigina gore herhalde normal bir metod degildir!" diyebildim ben (new operatorunu saymazsak). Ustelik iki tane fazlalik var en azindan bir static factory metoduna gore: bastaki "new" ve sondaki "build". Tabii ki bircok metod cagrisi da cabasi. Gerci oyle tek komutluk fonksiyonlari HotSpot halleder... Ama dusununce, Property listesi metodu cok daha esnek olabilir: netice de oyle bir liste sadece bir istek listesinden ibaret oldugu icin runtime'da yukelenebilir mesela ve public API'yi *hicbir zaman* degistirmek zorunda kalmazsiniz. Property listesini de *dilediginiz kadar* esnek yorumlayabilirsiniz, cok karsilasilan kullanici hatalarini tahmin edebilirsiniz, vs, vs. Bunlar ilk aklima gelenler. Fakat Joshua Bloch'un onerisini siz yazmasaniz bunu irdelememis olacaktim: guzel oldu dogrusu. Saygilar.

ahmetaa
18 yıl önce

anladigim kadariyla bu yontemin farkliligi islemin anlasilir sekilde tek satirda yapilmamasi. Statik Factory metoduna parametreleri tasiyan bir nesne gondersek once parametre tasiyan sinifi olusturup daha sonra icindeki ozellikleri belirleyip en sonunda Factory'e gondermek gerekirdi. yani su sekil bir kullanim olurdu:

B b = new B("abc",2);
b.setc(123);
b.setd("asdf");
A = A.newInstace(b);

bu yontemde ise onceki ornekte oldugu gibi
A a = A.B("abc",2).c(123).d("asdf").build();

Gercekten eger bu sIkca uretilen bir sinif ise saniyorum bu yontemin cok hafif bir performans etkisi olabilir. Ama projedeki ornekteki gibi bir defa acilista olusturulan degismez siniflar icin bunun bir onemi yok.

Acikcasi Property listesi yaklasiminin bu yonteme karsi soylediginiz avantajlarini net goremiyorum. Property listesi kavramini belki ben yanlis algiladim. Yani sonucta bu yontemde de public api'yi degistirmeniz gerekmiyor..
son olarak, sunumdaki kodda kucuk bir hata var, Builder sinifinin "static" tanimlanmasi gerekiyordu galiba.. Saygilar.

newman
18 yıl önce

son olarak, sunumdaki kodda kucuk bir hata var, Builder sinifinin "static" tanimlanmasi gerekiyordu galiba.. Saygilar.
Ben buna dikkat etmedim, yuzeysel okuyup gecmistim. Haklisiniz elbette. Yeni ogrenen arkadaslar var ise, bir de malumu ilan kabilinden link:
http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html
Farkettiginiz ve uyardiginiz icin sagolun. Acikcasi Property listesi yaklasiminin bu yonteme karsi soylediginiz avantajlarini net goremiyorum. Property listesi kavramini belki ben yanlis algiladim. Yani sonucta bu yontemde de public api'yi degistirmeniz gerekmiyor.. Aslinda cok derinlikli birsey kasdetmedim. Fakat evet, ufak bir yanlis anlama (benim kisir ifademden dolayi) var. Belki "request list", veya "memo" demeliydim. public api ile de Builder'in public apisini kasdettim (sadece var olani degistirme degil, genisletme, vs. baglaminda). Aklimda ise daha cok net ortaminda birbirine konusan objeler vardi. Mesajlasma ve Is siparisi gibi bir paradigma vardi kafamda, vardi da vardi ;-). Ama ornek bazinda bakarsak fazla uzerinde durmaya gerek yok. ben sahsen ilk baktigimda daha ilginc gelmisti ornek, neyse... Bir is bin degisik sekilde yapilabiliyor gormus oldugumuz uzere deyip bu ornegi bir kenara koyuyorum simdilik :).

FZ
18 yıl önce

Bu son yazdiginiz sey bana Ada, Common Lisp, ve belki baska dillerdeki "named parameter" tarzini hatirlatti. Bunu degisik sekillerde emule etmek mumkun. Mesela C programcilari bunu bir struct olusturup (hafizayi default degerler icin sifirlayarak tum alanlari her zaman doldurma zahmetinden kurtulmak mumkun) Factory fonksiyonuna parametre olarak geciyorlar.

Çağrışım yaptı, paylaşayım dedim:

"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." -- Philip Greenspun

bio
18 yıl önce

Galiba "new" olmayacak orada, yaniliyor muyum?

newman
18 yıl önce

"new" olmak zorunda: Builder, NutritionFacts icinde bir nested class. O uzun ifadenin new NutritionFacts.Builder("Diet Coke", 240, 8) kismi bir Builder nesnesi uretiyor. "new" bunun icin. Geri kalanlar o sinifin metodlari. Hepsi, sondaki build() haric, Builder nesnesine bir referans dnduruyor. En sonunda artik tamam dediginizde build()'i cagiriyorsunuz, o artik bir NutritionFacts nesnesi olusturup donduruyor. Neden bu dolambacli yol? Cunku amac, datasi final olan bir nesne olusturmak, ama bunu bir constructor'a cok sayida e hepsi de onemli olmayabilen argumanlar gecerek yapmamak. Overloaded constructor cozum degil, cunku exponential olarak kodu sisirecektir. ahmetaa'nin verdigi linkteki pdf belgesinde bazi detaylar var (ilk sayfalarda).

bio
18 yıl önce

Ha tamam. Ben Builder'in NutritionFacts'in inner class'i degil, statik bir metodu oldugunu dusundum.

mbayer
18 yıl önce

Bende ilk başta c# yada java'ya karşıydım, koyu bir c progamcısıydım. Ama artık değiştim c# ve java'yı bolca kullanıyorum. Temelde bu dillerin syntax'ı zaten c ile acayip yakın. Zatem asm kodlamadığıma göre ha c ile yazmışız ha c# ile. (Java'da dahil.) Her ne kadar ms; vs2005, office2007 ve msn live'i c++ ile yazıyor olsada... :) Bu gidişle teknoloji onlardı mı kalacak merak etmiyorda değilim doğrusu..

Görüş belirtmek için giriş yapın...

İlgili Yazılar

İsmi lazım Değil

butch
2 Nisan 2005, 1 dakika okuma süresi

Herkesin haberi vardır. Mart ayı başında İstanbul Bilgi Üniversitesi tarafından düzenlenen Özgür Yazılım ve Açık Kaynak Günleri etkinliğinin konuklarından biri de Miguel Icaza idi. Özgür yazılım dünyasının bu önemli simasıyla tanışmak için herkes sıradaydı. Bu ortam sağlandı da. Çeşitli gazeteler, televizyonlar , web siteleri söyleşiler gerçekleştirdiler.

Bloguma Ses Ver!

redogre
25 Aralık 2007, 1 dakika okuma süresi

Fazlamesai.net Globus´da

butch
2 Mart 2002, 1 dakika okuma süresi

Aylık ekonomi ve finans dergisi Globus'un bu ayki sayısında bizlerle yapılan bir röportaj yayınlandı. İlgilenenler için Sayfa 88 (125 KB), Sayfa 89 (146KB). Küçük bir hatırlatma; dergi ABD, Almanya, Avusturya, Fransa, Hollanda ve KKTC'de de satılıyormuş.

An Istanbul breakfast with Tim O'Reilly

sundance
6 Nisan 2011, 31 dakika okuma süresi

It all began with a tweet; "Just arrived in Istanbul for #occrp meeting. Staying at the lovely Antalya hotel with a view of the sea of marmara. Now out for a ramble Tim O'Reilly"

I asked if he would care for an interview, to my surprise he kindly accepted, even introduced us to OCCRP people, stating that we are from "Turkish Slashdot", which made us feel both proud and overinflated :)

Let me say that all the blunders are mine (especially not mentioning more about OCCRP guys who are doing a wonderful job) while all the provacative thoughts belong to Mr. O'Reilly (of course I do not refer to the Fox Tv Guy :)

We enjoyed talking with him, I hope you enjoy reading it. (Bu uzun röportajın deşifresini ancak bitirebildim, bu yüzden daha fazla bayatlamadan çevirmek için beklemeyip yayınlayalım istedik. Türkçe halini (referanslar eklenmiş olarak) kısa süre sonra yayınlamayı umuyoruz.)

GPL Uygulamaları Windows'da paralı mı olsun?

sundance
6 Aralık 2004, 1 dakika okuma süresi

Linux üstünde en sevilen IRC istemcilerinden biri X-Chat Windows için derlenmiş halini $20'a satmaya başladı.

Uzun süredir tartışmak istediğim bir konu.X-Chat bunun tek örneği de değil, bir çok yazılımcı "GNU/Linux üstünde ürünü geliştirirken, Linux camiasına da bir şeyler geri veriyor gibi hissediyoruz ve bu bize yetiyor. Fakat eğer bunu Windows altında kullanmak istiyorsanız para ödemek zorundasınız, ya da oturun kendiniz derleyin" diyor.

Merak ediyorum acaba FM okurları bu konuda ne düşünüyor?