Spørgsmål til god OOP-skik

class Test {

private int x;

public Test(int value) {
x = value;
}

public int getX() {
return x;
}

public int squared() {
return x*x;
}

}

        return x*x;

        return getX()*getX();

public int getX() {
return x;
}

public int X{
get{
return x;
}
}

public class Test {

float dividend = 0;
float divisor = 1;

Test(float initDividend, float initDivisor) {
dividend = initDividend;
divisor = initDivisor;
}

public void setDividend(float value) {
dividend = value;
}

public void setDivisor(float value) {
if (value == 0) {
throw new ArithmeticException("Divisor can't be 0.");
}
divisor = value;
}

public float getQuotient() {
return dividend / divisor;
}

}

        dividend = initDividend;
divisor = initDivisor;

        setDividend(initDividend);
setDivisor(initDivisor);

arne_v (6) skrev:

Jeg vil sige x*x fremfor getX()*getX().

Fordi jeg betragter getX() som værende tiltænkt kode udenfor klassen og x som værende tiltænkt kode indenfor klassen med den angivne accessibility.

arne_v (7) skrev:

#1

Bemærk iøvrigt at de to måder vil give forskelligt resultat, hvis objektet er en sub klasse af Test som har overridet getX med noget der retrunerer noget andet.

arne_v (13) skrev:

Jeg ville føle det fristende at flytte testet til getQuotient (...)

return getX()*getX();

public int getX() {
return anotherx;
}

public class Test {

int elefanter = -1;

public void setElefanter(int elefanter) {
this.elefanter = elefanter;
}

public int getElefanter() {
if (elefanter < 0) {
elefanter = Util.magic();
}
return elefanter;
}

public int getMeningsløs() {
int e = getElefanter;
return e*e;
}

ZiN (20) skrev:

#17: Jeg forstår ikke hvordan det kan være mest Objekt-Orienteret at benytte en get metode hellere end en variabel.

ZiN (20) skrev:

Hverken eller af delene har noget med Objekter at gøre.

ZiN (20) skrev:

Kun hvis du vil bruge nedarvning vil du have godt af, muligvis ikke at skulle rette så meget, men i mine øjne kunne man også bare tage sig sammen og rette i squared-metoden selv hellere end i get-metoden,

ZiN (20) skrev:

efter som samme variabel sandsynligvis er i den nedarvede metode skal der jo nok være en get på både "anotherx" og "x", også vil du jo ikke bruge getX() til at hente anotherx, som #15 ellers nævner - det ville hellere ikke give nogen mening i programmatisk henseende at returnere "anotherx" i getX() metoden. Det vil man bruge getAnotherX() til, for pokker da - og så skal du alligevel rette i selve metoden.

ZiN (20) skrev:

Rant. Pis.

ZiN (22) skrev:

#21:
Encapsulation kender jeg til. Det bruges dog kun uden for klasserne i OOP - ingen metoder skal have direkte adgang til variabler osv., men interne metoder har, selvfølgelig. Alt andet er da slam.

ZiN (20) skrev:

#8: For det første; Det er nemt at sige, nu hvor det er blevet sagt at det er Java. For det andet; Nej. I min klasse hvor vi lærer C# bruger vi camelCasing, ligesom i Java - små bogstaver først. Med mindre du er Microsoft fanboy (undskyld udtrykket, begrundelse følger), så er sandsynligheden at du har en gammel hund til at undervise C#, der sandsynligvis er vant til camelCasing fra eksempelvis C, C++, Java eller andre sprog. Ergo ved du ikke at man benytter anden casing medmindre du selv går ind og søger på det.

myplacedk (23) skrev:

Spørgsmålet er, om det du reelt skal bruge, er X, eller resultatet af getX. Det vil næsten altid være det samme, men hvad nu hvis det pludselig ikke længere er? Så vil det højest sandsynligt være resultatet af getX du skal bruge, og derfor mener jeg, at det reneste design som udgangspunkt er at brugere getteren.

arne_v (26) skrev:

Og at jeres underviser vælge at ignorere den slags er pinligt for uddannelses institutionen.

Pascal Casing

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example:

BackColor

Camel Casing

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. For example:

backColor

Do use Pascal casing for all public member, type, and namespace names consisting of multiple words.

Note that this rule does not apply to instance fields. For reasons that are detailed in the Member Design Guidelines, you should not use public instance fields.

Do use camel casing for parameter names.

Classes

Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).

class Raster;
class ImageSprite;

Methods

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

run();
runFast();
getBackground();

Variables

Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed.

Variable names should be short yet meaningful. The choice of a variable name should be mnemonic- that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.


int i;
char c;
float myWidth;