Static ???????

jo det er korrekt.

den primære fordel er at ALLE de instanser der laves af den klasse ser den samme variabel. hvis en af klasserne ændrer den ser de alle den ændring.

fx en måde de kan at kommunikere med hinanden

Svare det til en pointer i eks Pascal ??

det kunne også være anvenligt hvis det er generelle funktioner, eks
Character.isDigit(char);
Math.floor(..);

det er også anvenligt ved variabler, eks:
Integer.MAX_VALUE;
Integer.MIN_VALUE;

så behøver man ikke instanciere klassen for at benytte metoden/variablerne.

jo det kan sagtens gøres uden static. vx ved at oprette den variabel i rod-klassen og give alle klasser af den type et link til rod-klassen.

men hvis vi gør det kan hvemsomhelst aflæse og ændre på den variabel. Det er ofte bedre at gemme den væk i den klasse den hører til i.

Den er ved at være der.
f.eks. til en tæller for hvormange instancer der er lavet af en klasse ikk ??

Niels

nej det har ikke noget med pointere at gøre.

Det eksembel jeg kigger på:
public static final int EATING = 0;

Og så tænkte jeg - hvorfor 'static' når variablen er final

Ja det kunne den være god til.

der er en konvention om at konstanters navne skrives med store bogstaver.
nu er ALLE klasser af den type enige om at EATING svarer til 0.

JAH - men det ville de vel også være uden static, altså når den er erklæret final ???

Tak for hjælpen

nih -> Det svarer jo fuldstændigt til en konstant i Object Pascal. Bortset fra at den altså er erklæret inde i classen opfører disse to sig jo helt ens.

Det ville de ja.
Den der skrev det var nok en gamling ligesom jeg, fra dengang ram var noget man sparede på. eller måske der skal laves 50000 instanser af den klasse :-)

Min bog er HELT ny ;o)

Niels

Static kan bruges til mange nyttige ting.

public static final int EATING = 0;

Ja, det er en konstant, den kan ikke ændres. Hvis vi nu lavede 10 objekter af den klasse konstanten er erklæret og defineret i, ville hvert objekt have deres egen konstant uden static. Dvs. hvert objekt ville bruge en smule ram til at gemme konstanten i. Med static peger alle 10 objekter på den samme konstant i ram. Dvs. du sparer 9 gang konstanten i ram. Og hvorfor gemme det samme tal 10 gange i ram, når tallet alligevel ikke kan ændre sig ???

EN konstant fylder naturligvis ikke det store, men hvad nu hvis det var en større mængde data ???

static kan også bruges f.eks. til at vise hvor mange objekter der er af en klasse. I rumspil kunne antallet af aliens måske afgøre om de andre (mange aliens), forsvarede sig (færre), eller flygtede (få) ....

public class Alien() {
  private static int antal;
  // Flere variable 

  public Alien() {
    antal++;
    // Med mere
  }

  // Flere metoder osv.

  public int getAntal() {
    return antal;
  }

  protected void finalize() {
    antal--;
  }
}

I konstruktøren tælles antal 1 op (ny alien skabt) ... med getAntal() kan man se hvor mange der er, og påvirke Aliens bevægelse (angreb/forsvar/flygt) på denne måde. I dekonstruktøren tæller man antal 1 ned, nu nedlægges objektet jo, så der er en mindre Alien.

Eller hvad hvis man har nogen objekter man skal tilgå mange steder. Man har f.eks. lavet en avanceret GUI med en masse JFrames, JPanels mm. nogle af disse Jpanels skal tilgå et objekt, f.eks. et der giver afgang til en database. Enten skal man sende en reference med rundt til alle JPanels (hvoraf kun nogen af dem skal bruge objektet). Løsningen er static metoder i en klasse, der giver adgang til disse objekter.

public class NogenObjekterDerSkalTilgaas {
  private static DatabaseAdgang dbAdgang; // En klasse der har metoder til
                                          // at tilgå databasen.

  public NogenObjekterDerSkalTilgaas() {
    dbAdgang = new DatabaseAdgang();
  }

  public static DatabaseAdgang getDatabaseAdgang() {
    return dbAdgang;
  }
}

I din main metode eller noget kan du så instantiere NogenObjekterDerSkalTilgaas:

NogenObjekterDerSkalTilgaas nn = new NogenObjekterDerSkalTilgaas();

Nu kan man få tilgang til databasen fra forskellige JPanels ved at kalde static metoder på klassen NogenObjekterDerSkalTilgaas. Når metoderne er static er det ikke nødvendigt at instantiere et objekt først. Da vi har instantieret en instans (objekt) af NogenObjekterDerSkalTilgaas klassen fra main metoden (eller et andet sted i opstarten), er klassens variable sat.

String s = NogenObjekterDerSkalTilgaas.getDatabaseAdgang().enMetodePaaDatabaseAdgangDerReturnererEnString( noget data med );

Så static kan bruges til en masse ...

"om de andre" ... HAHA, det var:"om de angreb" ...

faktisk skal din getAntal metode også være static AFAIK. Ellers får du vist en compile error (trying to reference static variable antal in non-static context - eller sådan noget).

Nej det er den anden vej det er forbudt, at tilgå en non-static variabel fra en static funktion.  (static funktionen kan jo ikke vide hvilken instans at den non-static der menes)

oh ja. det giver jo også mening. en static metode skal jo kunne tilgås uden en instans af objektet.

Man kan altså lave en 'fælles' klasse med static metoder og konstanter. Og bruge den til generelle beregninger, formatter osv.
Så behøves man ikke oprette nye objekter af 'fælles' klassen for at kunne bruge metoderne/funktionerne. ????

En klasse kan jo også oprettes static - måske er det sådan math klassen er defineret ????? - Her skal man jo ikke oprette et objekt af typen math.

Niels

Det kan man godt, men som regel er det en dum ide.

Et af de allerførste programmeringssprog FORTRAN havde det på den måde. Der var et COMMON areal med variable som alle moduler og subrutiner kunne kikke i.

Men når programmerne begynder at blive lidt store bliver det et helvede. De mange programmører på projektet kan ikke allesammen have i hovedet hvilke variable er til hvad og laver fejl ved at bruge dem forkert og ændre dem hvor en anden del af programmet ikke kan tåle at de bliver ændret.

Så man går mere og mere over til at "gemme" alle de variable og konstanter man kan.

i en stap klasse er det fx ikke nogen andre end den instans af stakken den må ændre på stakpointeren. så så man 'gemmer' den i stak classen ved at gøre den private.

i cybermazedk skal alle instanser af 'Alien' vide hvormang aliens der er det får de så at vide gennem den der static der hedder antal. Men det kommer ikke andre klasser i systemet ved, så variablen gemmes væk i Alien klassen.

mch JakobA

Ups.  'i en stap klasse'  ->  'i en stak klasse'

Kanon hjælp :o)

Niels

Det er rigtigt. Det er vigtigt at selve variablen (field) er skærmet fra resten af koden ved at sætte scope til 'private'. Der er i Java tre niveauer af scope: 'private' = kun adgang fra det objekt hvor det er defineret, 'protected' = kun adgang fra samme package som objektet og 'public' = fuld scope.
I den forbindelse kan man forestille sig en metode der KUN kan anvendes af samme objekt. Det skal så erklæres private.
static har ikke rigtig noget at gøre med dette. static (for metoder) afgør om det er nødvendigt med en instans af objektet for at kalde metoden.
Dette er f.x. en klasse Effect, der er brugt til en alkymi applet

class Effect {
    private static String[] matrix = new String[]{"Burden","Cure Blight Disease","Cure Common Disease","Cure Paralyzation","Cure Poison","Damage Fatigue",
                                "Damage Health","Damage Intelligence","Detect Animal","Detect Enchantment","Detect Key","Dispel","Drain Agility",
                                "Drain Endurance","Drain Fatigue","Drain Health","Drain Intelligence","Drain Luck","Drain Magicka","Drain Personality",
                                "Drain Speed","Drain Strength","Drain Willpower","Feather","Fire Shield","Fortify Agility","Fortify Attack",
                                "Fortify Endurance","Fortify Fatigue","Fortify Health","Fortify Intelligence","Fortify Luck","Fortify Magicka",
                                "Fortify Personality","Fortify Speed","Fortify Strength","Fortify Willpower","Frost Shield","Invisibility","Levitate",
                                "Light","Lightning Shield","Night Eye","Paralyze","Poison","Reflect","Resist Common Disease","Resist Fatigue",
                                "Resist Fire","Resist Frost","Resist Magicka","Resist Personality","Resist Poison","Resist Shock","Restore Agility",
                                "Restore Endurance","Restore Fatigue","Restore Health","Restore Intelligence","Restore Luck","Restore Magicka",
                                "Restore Personality","Restore Speed","Restore Strength","Restore Willpower","Spell Absorption","Swift Swim",
                                "Telekinesis","Vampirism","Water Breathing","Water Walking","Weakness to Poison"};
    private int index;
    private String effect;
   
    public Effect(int index) throws IndexOutOfBoundsException {
        this.effect = matrix[index];
        this.index = index;
    }
   
    public boolean equals(Effect eff) {
        return (this.index == eff.getIndex());
    }
   
    public boolean curse() {
        return (index==0||index==5||index==6||index==7||(index>=12&&index<=22)||index==43||index==44||index==71);
    }
   
    public int getIndex() {
        return this.index;
    }
   
    public String getEffect() {
        return this.effect;
    }
   
    public static String getEffectReference(int i) {
        return matrix[i];
    }
   
    public static int effectLength() {
        return matrix.length;
    }
}

Bemærk at den store effekt matrix ikke er en instans variabel, fordi den er fælles for alle instanser af Effect (der er jo ingen grund til at bruge kilometervis af hukommelse hver gang der skal laves en effekt). Desuden er getEffectReference(int) også static, fordi vi gerne vil kunne hente informationer ud uden først at oprette en instans. Altså Effect.getEffectReference(8).
Effect

Det er korrekt at

public int getAntal() {

skal være

public static int getAntal() {

så det godt efter jeg havde postet det, men mente ikke det var nødvendigt at rette. Men ok, nu er det så på plads ...

"Et af de allerførste programmeringssprog FORTRAN havde det på den måde. Der var et COMMON areal med variable som alle moduler og subrutiner kunne kikke i.

Men når programmerne begynder at blive lidt store bliver det et helvede. De mange programmører på projektet kan ikke allesammen have i hovedet hvilke variable er til hvad og laver fejl ved at bruge dem forkert og ændre dem hvor en anden del af programmet ikke kan tåle at de bliver ændret." fra jacoba

Det er fuldstændig korrekt at i ældre programmeringssprog kunne man direkte tilgå variable på klasser. Og det skabte en masse problemer. Blandt andet var det nemt at få fat i den forkerte variabel. Det var nemt at sætte en variabel til en ugyldig værdi. Og det var et helvede at debugge. For i teorien kunne variablen have fået den ugyldige værdi fra hvor som helst i koden !!!

Det har ledt til det princip i Java (og andre sprog) der på dansk kaldes dataskjul. I Java taler man om scope. Ved hjælp af public/protected/private kan man ændre en variabel/metodes/klasses scope. Dvs. hvem kan se variablen/metoden/klassen.

Det er næsten universelt, at variable med klasse scope (dem der er defineret lige under klasse definitionen og uden for metoder) erklæres private. Dvs. kun metoder i klassen selv kan tilgå dem. Men hvordan får andre klasser så fat på de variabel ??? Ved hjælp af public get og set metoder.

public class Test1 {
  private int tal;
  private String tekst;

  public Test1( int tal, String tekst ) {
    this.setTal( tal );
    this.setTekst( tekst );
  }

  public int getTal() {
    return tal;
  }

  public String getTekst() {
    return tekst;
  }

  public void setTal( int tal ) {
    if( tal > -1 && tal < 101 ) {
      this.tal = tal;
    }
    else {
      this.tal = 0;
    }
  }

  public void setTekst( String tekst ) {
    if( tekst.length() > 0 ) {
      this.tekst = tekst;
    }
    else {
      this.tekst = "Du angav en ugyldig tekst, så nu er den her der.";
    }
  }
}

Her er en simpel klasse, der har 2 private variable. tal og tekst, der kan indeholde en int og en String. Konstruktøren tager 2 attributter, der er de værdier, som tal og tekst skal have ved oprettelsen. Klassen har 2 public get metoder. En for hver variabel. På denne måde kan andre klasser se værdierne af denne klasses variable. Der er også 2 set metoder, som også bruges af konstruktøren. set metoder er den eneste måde andre klasser kan ændre i denne klasses variable. Samt den eneste måde denne klasse bør ændre i egne variable.

Fordelen er, at set metoden ET sted opsætter reglerne for hvilke værdier en attribut må tage. Sendes en ugyldig attribut vil begge variable få en standard værdi, men man kunne også vælge ikke at ændre på attributten (beholde den nuværende værdi). Nu kan variablen ikke få en ugyldig værdi. Og skulle 1 flere variabel få standard værdier på et tidspunkt, behøver vi kun kigge i den del af koden, som kan tilgå klassen Test1, for at finde fejlen.

Nu er vi helt derude hvor min teoretiske bagrund begynder at knirke :-)
Men ville man ikke lade setTekst kaste en undtagelse for at forhindre at den bliver sat til en værdi uden programmøren har en chance for at vide det er sket? Eller eventuelt lade metoden stilfærdigt ignorere (hvordan oversætter man silently ignore?!?) en ugyldig værdi.
Jeg lærer selv meget af det her. Hvis jeg spænder buen for meget over bagateller kan I bare stilfærdigt ignorere mig :-D. Jeg er ikke dygtig nok til decideret at kunne forstå alt dette her (bemærk den underdanige tone i mine kommentarer).

Ja ja, vi bemærker den og ser dig gemme dit grin bag hånden :-))

jo det kunne man vælge. fidusen er at det er et situationsafhængigt valg. Nogen gange vælger man det ene og andre gange det andet.

Hvis der midt i en formel bliver divideret med nul er det en katastrofe, programmet skal enten terminere eller bede om bedre inputdata før det starter forfra.
Hvis en af 500 mails ikke kan sendes er det ret ligegyldigt. ignorer det elle læg evt en linie i loggen.

mvh JakobA

Super. En undtagelse skal kastes hvis (og kun hvis) en metode får en værdi der hindre afviklingen af programmet. Så hvis setTekst er en metode andre klasser er afhængig af er det vigtigt at undtagelsen bliver kastet der så man via en stackTrace kan finde ud af hvor programmet får forkerte data. Ellers er der ingen grund til at afbryde programmet (man må for guds skyld aldrig anvende Exceptions til at bestemme programafviklingen. Står vist på side 1 i min bog).
Så man kan vel opstille (ad jakoba's kommentar) følgende tommelfinger-regel:
HVIS ugyldig input er defineret af programøren gennem kode skal der kastes en undtagelse
MEN HVIS input ikke er indenfor programmørens direkte kontrol er det bedre at fortsætte programafviklingen evt. med en log over fejlen.

if(tekst.length()>0) er det ikke det man kalder et sanity check. (noget jeg har brug for :-)

nej nej nej.  ingen lodrette regler tak.

Man kan for eksempel vælge at kaste en exception et sted, ikke fordi noget gik galt, men fordi det er en nem og bekvem måde at breake ud af nogen kompicerede programstrukturer og metodekald.

Det er værktøjer vi har, til at få noget arbejde gjort.
Jo rigtigere vi bruger værktøjerne, jo bedre; men det vigtigste er immervæk at vi får arbejdet gjort.

ØHH - det er MEGET interessant :o)

cybermazedk's kode er en klasse med 2 variable med tilhørende set og get metoder. Det kan jeg godt finde ud af ;o).....
Hvorfor snakker I så om 'silently ignore' og 'Exceptions' - Er det ikke det der undgåes ved setMetoderne - altså:
public setI (int var){
  // undgå værdien 0
  if (var == 0) i=1;
  else i = var;
}

mvh Niels

Som kommentar til maddog.

Normalt vil jeg foreslå 2 muligheder. Enten sæt variablen til en standardværdi, eller lad værdien være den gamle.
Lad være med at bruge Exceptions. Hvis du prøver at indsætte noget forkert, skal programmet ikke stoppe som udgangspunkt. Heller ikke smide exceptions. Dette fordi det er en "programmørfejl" hvis man forsøger at stoppe noget galt ind i variablen. Til hjælp for debug kan man indsætte en System.out.printl( "Du forsøgte at indsætte værdi: " + tekst ); hvis det er en ugyldig værdi. Så må man kigge på, hvorfor. Og her er det rart at se hvad værdien er, da det giver hjælp til at forstå, hvordan man kunne komme til at indsætte den værdi.

Og så må man fikse sit program, så det kun indsætter gyldige værdier.

nih >> Exceptions er henne i tredie-fjerde Java lektion. glem det indtil da. De er bare os der blærer os af at vi engang har fanget en.

det er ikke en god idé at forvente en programmør debugger uden at gribe exceptions.
hvis du i stedet lavede metoden således
public void setTekst( String tekst ) throws IlligalArgumentException{
    if( tekst.length() > 0 ) {
      this.tekst = tekst;
    }
    else throw new IlligalArgumentException("Null or negative length strings are illigal in this method");
  }
ville du kunne fange fejlen ikke bare i implementationer af klassen, men også i nedarvninger eller i andre klasser der anvender dette objekt som argument. Idet du kaster fejlen i den metode, hvor den opstår kan du altid via en stack-trace finde ud af hvor katten ligger begravet. I dette tilfælde er koden så simpel vi kan overskue den, men hvem kan (bortset fra jakoba) se sig bort fra en gang imellem at være overvældet af komplexiteten i kodens struktur.
Det kan jo også være mig der er en pee-wee :-).
I øvrigt har jeg tænkt hårdt og længe og må indrømme at exceptions er nogle gange den bedste måde at styre et programs afvikling (især fordi der som regel er en bruger indvolveret ufff).
(Jakoba: jeg kommer lige fra fadøls-anlægget. vi må have en lille ølsludder igen ved lejlighed. jeg sætter gerne mine 60 m^2 til rådighed og alle er velkomne)
Jeg vil gerne sige tak til nih for at stille sådanne spørgsmål. Det nærmest definerer forskellen mellem Java og Javascript. Dette er et akademisk og meget essentielt spørgsmål for forståelsen af java. Et typisk spørgsmål i javascript kategorien er 'jeg har downloadet denne menu. kan du lave den i blå'.
Jeg vil også gerne tilføje at jeg er absolut ikke ude i blær her. Jeg indtil flere klasser og metoder der skal 'luges ud' for exceptions efter det her.

Illegal men hva' faen.

maddog:

Selvfølgelig kan man da gøre sådan, men det giver egentlig bare samme effekt, som at indsætte en simpel udskrift (System.out.printl()). Dog får man at vide med printStackTrace i hvilken linie det går galt. Men det kan man for det meste alligevel gætte.

Igen, jeg anser det for at være en programmeringsfejl, hvis man prøver at indsætte noget galt i variablen. Det skal rettes programmeringsmæssigt. Det er ikke en runtime-fejl (fordi fejlen kun opstår under kørsel, pga en programmeringsfejl) ...

Cybermaze >
Det er jeg uenig i - for som jakoba nævner, så må det vel afhænge af den situation man står i.
Hvis vi anser det for at være en programmeringsfejl at kalde property-set-metoden med en forkert parameter, er det fordi vi ønsker at programmet skal foretage validering af inputtet _før_ den kalder property-set-metoden. Fx hvis det nu var et tal, som brugeren havde indtastet, kunne programmøren jo med rette lave en validering af feltet så snart brugeren havde forladt feltet - fx for at fortælle at det indtastede bogstav "g" ikke er et tal.
Men der er også situationer hvor det ville være hensigtsmæssigt at lade valideringen foregå i selve set-metoden. Det ville her ikke være en programmeringsmæssig fejl at kalde den med "forkerte" parametre, idet dette er planlagt. Hvis man nu fx havde 5 felter der skulle indtastes tal i, ville det i nogle tilfælde være lettere at putte valideringskoden ind i det objekt, der rent faktisk skal bruge dataene. Så vil man i nogle tilfælde kunne slippe for at kopiere valideringskoden 5 gange...

Jeg er ganske absolut uenig.

Al data der genereres inde i programmet SKAL være gyldig. Har programmet f.eks. beregnet sig frem til noget ugyldigt som det forsøger at sætte ind i en variabel (set-metode), er det en programmeringsfejl. Man kan så EVT. smide en exception eller lave en simpel udskrift på skærmen, men KUN, og KUN som debug hjælp under udviklen af programmet. Ikke i den færdige version.

Det gør sig gældende både når det er internt i det man selv har programmeret, eller det man inkluderer. Bruger vi f.eks. Math.random(), må vi stole på, at vi får et tal større end 0 og mindre end 1. Bruger vi altså random til at lave et tal vi sender med en setmetode, er der intet i vejen for, at setmetoden må validere på det vi sender. Men er det sendte forkert, bør man ikke smide en exception. I hvert fald ikke en der sendes op gennem programmet. Det skal højest være en klassen selv fanger igen og laver en printstacktrace på. Men det er så igen til debugging brug (for at rette en programmeringsfejl).

Det eneste tidspunkt man måske smider en exception er hvis der er tale om en virkelig kritisk ressource, som afskærer programmet fra at køre.

Dvs. internt skal man stole på at programmet overholder reglerne (og det er enhver programmørs opgave at sikre, at reglerne bliver overholdt). Mht. indtastning, hører validering af indtastede værdier ikke til i sådan en klasse. F.eks. hvis jeg har lavet en klasse Dato, som kan indeholde en dato. Det er ikke klasse Dato's opgave, at håndtere korrekt indtastning fra brugergrænsefladen. Det hører til i den controller (en eller anden listener) der aktiveres, når man trykker på en knap (indtast 5 værdier og tryk ok).

Jeg er så uenig med din uenighed.

Programmer bliver store. Afdelingen i hillerød har lavet et inputmodul og afdelingen i Frederikshavn har lavet backend til at vruge det input der kommer.

De har udvekslet specs osv og stoler på hinanden som mennesker. men på begge sider af den grænseflade skal de da alligevel begge indsætte nogle ekstra (formelt overflødige) tests der fanger misforståelser og hvad der ellers er gået galt.

Med assertions gør du det sågar for digselv. så du kan være sikker på at blive adviseret når du bruger det modul du har skrevet på an anden måde end du skrev det til. Den slags doublechecks er gode at have.

mvh JakobA