info fra andre klasser

Måske. Det kommer an på den anden klasse, men hvorfor vil du det?

Du laver en get metode som returnere det array du ønsker at have fat i.

Eller den grimme metode:
lav arrayet public så kan du tilgå det direkte.

du kan hente en referanse til den variabel...den peneste metoden (og forsåvidt den eneste korrekte måten) er å lage en getmetode i din klasse som returnerer denne array:

class DinKlasse{
  Array dinArray;
 
  public Array getDinArray(){
    return dinArray;
  }
}

deretter kan du i din andre klasse opprette et objekt av klassen DinKlasse og kalle getDinArray på den:

DinKlasse dinKlasse = new DinKlasse();
Array nyArray = dinKlasse.getDinArray();

/nute

mange tak

takker :)

Ja, undskyld jeg blander mig ;)

Det er alt sammen teknisk set korrekt, men hvis man ønsker at skjule
implementationsdetaljer i din klasse - altså at den tilfældigvis er lavet ved
hjælp af Array - er det bestemt ikke særlig smart at gøre denne attribut
tilgængelig udefra.

Lad os rent hypotetisk antage, at jeg skulle bedømme en opgavebesvarelse,
der indeholdt dette - så ville det sandsynligvis trække ned.

erikjacobsen >> hvis jeg forstår deg dithen at du ikke tillater modifikasjon av objektet i en annen klasse (uten bruk av fx. set-metoder) så er jeg helt enig...

erik er du lærer ?

Du snakker hele tiden om det ville trække ned osv.

Vi snakker vel om en form for funktionskomponent, hvor der er forskellige
valg af implementionsmetoder (vælg et eller andet fra Collection). Dette valg
må ikke være synligt udadtil - hvad enten det sker direkte til attributten eller
via get/set-metoder.

Det må det godt hvis udvikleren vælger det.

Og normalt kan man sagtens finde typen alligevel via reflection.

Jeg ved ikke hvor meget det kommer til at afvige fra mit oprindelige spørgesmål... men i det store hele ... skal jeg via en metode i en anden klasse have hentet et array ind, men metoden er ikke færdigudviklet endnu, så jeg skulle have noget at øve mig på, har slet ikke tænkt over information hiding endnu.....

Det må det da ikke, disky, hvis designet af de indgående klasser ikke
tillader det. Spørgeren er nok startet bagfra, uden at tage stilling til et
overordnet design. Men det kan jo være det kommer :)

korrekt :-)

Men at sige man ikke må er lidt meget, da man godt må men det er en dårlig ide.