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

0
anonim
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ı?

Görüşler

0
Tarık
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.
0
ahmetaa
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.
0
Tarık
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.
0
innaw
Neden bu kapsam disinda dusunuyorsunuz ki? Bu cabaya hic gerek yok.
0
innaw
Ş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.
0
Tarık
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 .
0
innaw
Soyledikleriniz olayin sosyal tarafi ve dusuncelerinize kesinlikle katiliyorum. Ama teknolojinin bu yanlisliklarda ne gibi bir kabahati olabilir ki?
0
Tarık
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
0
bio
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.
0
ahmetaa
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.
0
newman
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.
0
bio
> 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."

ve

"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.

0
newman
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.
0
FZ
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.
0
ahmetaa
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
0
newman
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.
0
ahmetaa
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.
0
newman
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.
0
ahmetaa
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.
0
newman
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 :).
0
FZ
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
0
bio
Galiba "new" olmayacak orada, yaniliyor muyum?
0
newman
"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).
0
bio
Ha tamam. Ben Builder'in NutritionFacts'in inner class'i degil, statik bir metodu oldugunu dusundum.
0
mbayer
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

Eben Moglen Türkiye'de

butch

Sanat ve Tasarım Odaklı Programlama

arikan

Bugün pek çok sanatçı ve tasarımcı paketlenmiş yazılımlar (Photoshop, Illustrator v.s. Adobe serisi) kullanarak görsel ve işitsel iş üretiyor. Bu yazılımlar onları üreten kişiler tarafından tanımlanmış sınırlarda iş üretilmesine izin veriyor, haliyle bu durum birbirini takip eden banal işler üretilmesine sebep oluyor. Oysa üzerinde çalıştığımız bilgisayara bir araç değil de bir medya olarak baktığımızda pek çok yeni düşünceyle karşılaşıyoruz.

fazlamesai.net'e soralım: 'Linuxçu' diye bir insan türü var mı?

FZ

"Linuxçu" diye nitelendirilebilecek bir "insan türü" var mıdır? İnsanlara gerçekten itici gelebilir mi? Güzel bir şeyi sunmak ne denli önemlidir? Gerçekten düzgün çalışan ve iyi işleyen sistemler bazı sunum şekillerinden ötürü "dışarıdan birilerine" itici gelebilir mi? Teknoloji, sosyoloji ve psikoloji arakesitinde ne denebilir? Bütün mesele gerçekten özgürlük müdür? Yoksa kişisel bazı problemler midir?

Turkix Datron Özel

anonim

Türkiye'nin lider dizüstü üreticilerinden Datron, Intel Sonoma tabanlı yeni nesil bilgisayarlarında, işletim sistemi olarak Turkix tarafından optimize edilmiş Linux kullanmayı tercih etti.

Bir CNBC-E´ye hastayım, bir de sabah uykusuna...

butch

Sonunda dayanamadım ve CNBC-E kanalının haftalık yayın akışı tablosunu (gerçi 300Kb ama) duvar kağıdı yaptım. Çünkü artık takip edemez oldum. Gerçek bir fazlamesai'ci olarak sabaha karşı 2-3 gibi mekandan (bir nevi büro) çıkıp, ertesi gün saat 16:00 sularında yine mekana döndüğümden benim için vazgeçilmez oldu bu kanal. Saat 02:00 gibi başlayan komedi kuşağı, 03:00'de başlayan -hergün başka bir tarz- süpper filmleriyle benim için ikinci bir hayat oldu adeta. Tabi durum böyle olunca sabah 6 gibi başlayan uyku süreci iyice keyifli bir hal alıyor. Eminim birçoğunuz benim gibisiniz, özellikle memleket şartları ve işsizlik gözönüne alınınca. Eğer öyleyseniz siz de duvar kağıdınızı değiştirin...
Not: Bu bir reklam değildir...