mboost-dp1
"this" keyword for properties, i Java, godt/skidt?
Hej
Havde et argument med min lærer, hvor jeg mente at det var utrolig dårlig skik at bruge 'this.' til at tilgå class-scope variables , specielt til constructor og properties (getters/setters).
Eksempel
Hvor jeg så vil mene at man f.eks. bør gøre sådan her (PHP,C++,C# 2.0 modellen)
Er der nogle gode argumenter for/imod brugen af this. ?
Havde et argument med min lærer, hvor jeg mente at det var utrolig dårlig skik at bruge 'this.' til at tilgå class-scope variables , specielt til constructor og properties (getters/setters).
Eksempel
public class Customer
{
private String name;
public Customer(String name)
{
this.name;
}
public String getName()
{
return this.name;
}
}
Hvor jeg så vil mene at man f.eks. bør gøre sådan her (PHP,C++,C# 2.0 modellen)
public class Customer
{
private String _name;
public Customer(String name)
{
_name;
}
public String getName()
{
return _name;
}
}
Er der nogle gode argumenter for/imod brugen af this. ?
IMHO:
Generelt brugt jeg kun "this", når der er et teknisk behov. Og det er der kun, når der er navnesammenfald. Det bør man alt andet lige undgå, men nogle gange er et navnesammenfald egentlig passende nok.
Ex.:
I koden (de enkelte linjer) burde det som udgangspunkt være ligegyldigt hvilket scope variablen ligger i. Og har man behov for at vide det, bør IDE'en gør det nemt at finde ud af.
I en speciel situation kan man så bruge "this." frivilligt for at tydeliggøre det, men jeg kan ikke lige mindes at det har været relevant for mig.
Generelt brugt jeg kun "this", når der er et teknisk behov. Og det er der kun, når der er navnesammenfald. Det bør man alt andet lige undgå, men nogle gange er et navnesammenfald egentlig passende nok.
Ex.:
public class Customer {
private String name;
public void setName(String name) {
this.name = name;
}
public String getName() {
return name;
}
}I koden (de enkelte linjer) burde det som udgangspunkt være ligegyldigt hvilket scope variablen ligger i. Og har man behov for at vide det, bør IDE'en gør det nemt at finde ud af.
I en speciel situation kan man så bruge "this." frivilligt for at tydeliggøre det, men jeg kan ikke lige mindes at det har været relevant for mig.
#1,
Jeg vil give dig ret i at man ikke skal spamme this. hver gang man har chancen - men er der navne sammenfald, som i #3's eksemple, syntes jeg at this. er brugbart.
Dit forslag om at bruge .NET løsningen med underscore til klasse variabler er ikke en gyldig Java løsning, da den strider mod Java's Naming Convension - og kan muligvis skabe problemer i senere udgaver af Java.
Jeg vil give dig ret i at man ikke skal spamme this. hver gang man har chancen - men er der navne sammenfald, som i #3's eksemple, syntes jeg at this. er brugbart.
Dit forslag om at bruge .NET løsningen med underscore til klasse variabler er ikke en gyldig Java løsning, da den strider mod Java's Naming Convension - og kan muligvis skabe problemer i senere udgaver af Java.
5 skrev:Ville kun være en super god undskyldning for aldrig nogen sinde arbejde i Java igen så :)
Ja, de kapitalistsvin har bare at lade Java være som det er, og aldrig ændre noget. [/ironi]
Jeg tror så ikke de ændre lige på det der. Det er ikke Java-agtigt at konkludere noget ud fra navngivningen.
#5, læg venligst mærke til min bevist super vage formulering.
Jeg regner heller ikke med at java ændre reglerne for hvad der er tilladte variable navne.
Men når naming convensionen klar og uden tvetydighed siger at man ikke skal bruge _ eller $ til at starte variabler med, så bør man heller ikke gøre det.
Naming convensions er der af en grund, og er IMO ligeså vigtige at overholde som w3c anbefalingerne.
Jeg regner heller ikke med at java ændre reglerne for hvad der er tilladte variable navne.
Men når naming convensionen klar og uden tvetydighed siger at man ikke skal bruge _ eller $ til at starte variabler med, så bør man heller ikke gøre det.
Naming convensions er der af en grund, og er IMO ligeså vigtige at overholde som w3c anbefalingerne.
#1
Standard Java er at bruge samme navn for argumenter i constructor og setter som field og derfor er this nødvendig. Der er ikke brug for this i getter.
Jeg vil klart anbefale dig at følge konventionen.
Dit andet eksempel er helt gal som C# kode - man bør bruger property fremfor metode til getter, metode navne skal starte med stort og MS anbefaler at man *ikke* bruger prefix for fields.
Så Java:
og C#:
Så præcis samme brug af this i constructor (men forskel i setter hvor man i C# property vil bruge value keyword)
Standard Java er at bruge samme navn for argumenter i constructor og setter som field og derfor er this nødvendig. Der er ikke brug for this i getter.
Jeg vil klart anbefale dig at følge konventionen.
Dit andet eksempel er helt gal som C# kode - man bør bruger property fremfor metode til getter, metode navne skal starte med stort og MS anbefaler at man *ikke* bruger prefix for fields.
Så Java:
public class Foo {
private String bar;
public Foo(String bar) {
this.bar = bar;
}
public String getBar() {
return bar;
}
}
og C#:
public class Foo
{
private string bar;
public Foo(string bar)
{
this.bar = bar;
}
public string Bar
{
get
{
return bar;
}
}
}
Så præcis samme brug af this i constructor (men forskel i setter hvor man i C# property vil bruge value keyword)
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund