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

FM'ye soralım : GNU/Linux uyumlu donanım seçmek

Betelgeuse
11 Mart 2007, 2 dakika okuma süresi

Yeni bir masaüstü bilgisayar toplamaya niyetim var. Linux kurarken sorun yaşamak istemediğim için donanımı seçerken emin olmak istiyorum. Ama bilgisayar malzemesi satıcıları sattıkları donanımlar hakkında linux uyumluluğu konusunda hiç bir şey söyleyemiyorlar. Ben de Fazla Mesai ortamına sorayım dedim. Belki yeni donanım almak isteyen başkalarına da yararlı olabilecek bir rehber oluşturabiliriz burada.

Fazlamesai 3 yaşında

sundance
31 Ekim 2003, 1 dakika okuma süresi

İnsan kendi doğumgününü unutur mu ? Fazlamesai unutur :) Hem de her sene.

Bundan üç yıl birkaç gün önce ilk haberimizi 8 Ekim´i 9 Ekim´e bağlayan gece yayınlamışız.

Aradan üç yıl ve bin küsur haber geçti. Fazlamesai IRC kanalı açıldı, fazlamesai.org forum ve çeviri ortamları açıldı. Tek derdimiz insanların biraz daha katılımcı olması, bir kenarda durup sadece okumak yerine, yorum yapıp fikir üretmeleri ve bunu bizlerle paylaşmaları. Eğer FM daha iyi bir site olacaksa ancak sizler sayesinde olacak bu

FZ´nin blues armonikası ve sesi eşliğinde Mutlu Yıllar Fazlamesai! (Tabi ki ogg/vorbis formatında ;)

Rezervuar Penguenleri

redogre
13 Aralık 2006, 1 dakika okuma süresi

Bilgisayar Biliminin/Mühendisliğinin Anlamı

FZ
14 Ocak 2003, 14 dakika okuma süresi

Eminim bu siteyi takip eden insanlardan bir kısmı genç arkadaşların sorduğu "ya, hocam ben bilgisayar okumak istiyorum, bilgisayar mühendisi olacağım, ne dersin?" şeklindeki sorulara maruz kalmıştır. Bu tür sorulara kapsamlı ve sistematik olarak cevap vermek, genç (ya da yaşlı) insanları "bilgisayar mühendisliği/bilgisayar bilimleri" nedir, ne değildir konusunda aydınlatmak kolay değildir. Ancak geçen gün sundance arkadaşımın bana gönderdiği bir belge bu konuya son noktayı koymuş durumda: ODTÜ'den Dr. Göktürk Üçoluk'un BİLGİSAYAR MÜHENDİSLİĞİNE İLİŞKİN SIKÇA SORULAN SORULAR başlıklı yazısı sanırım konu ile ilgili hemen herkesi aydınlatacak nitelikte.

Linux üstünde .NET

defusion
4 Nisan 2002, 1 dakika okuma süresi

Linux üzerinde Microsoft'un yeni platformu .NET'i çalıştırmak için bir girişim olan mono project eksiksiz tamamlanabilirse , Linux üzerinde müthiş bir program patlaması yaşanacak...