static eller inte static, public eller private? [Utbruten tråd /Mod]

Tycker det är ganska intressant det där med statisk och när man ska använda det och inte.

Grundtanken är väl att om en metod är static så ska den bara utföra saker som har med 'klassen' att göra, om den inte är static ska den utföra saker som har med 'instansen' att göra.

Och med 'utföra saker' menar jag att ändra och använda variabler.

I det här fallet utför ju inte metoden nånting egentligen så den kan mycket väl vara static.

Om man däremot använder gadzoox lösning, bör den nog i längden vara icke-static (då det som skrivs in troligen kommer ha med instansen att göra så småningom).

iofs, den kan ju mycket väl vara static där. Inga fält att leka med och skapa flera instanser av klassen lär väl inte vara aktuellt. Kanske jag som tänker lite väl objektorienterat och "använd inte static om du inte måste"-aktigt.

Bättre att tänka för objektorienterat än inte alls iofs. Finns hemska nybörjarexempel på program med allt statiskt, eller åtminstone public. Då är det ju bättre att vara för objektorienterad helt klart.

Jag har själv skrivit ett schack-program i Java där i princip allting är statiskt... nu är det ju av prestanda-skäl (att skapa objekt är en ruskig flaskhals), men det är inte lätt att hålla koll på all kod ska jag säga.

(om någon är intresserad finns det här http://mediocrechess.blogspot.com)

Varför blandar folk ihop public och static? De har ju inte det minsta med varandra att göra?

Han jämför dem väl knappast, utan pekar snarare på det faktum att många nybörjare gör alla medlemsvariabler public, precis som de kan göra allt static.

Som ojn sa, jämför dom inte, men det är vanliga nybörjarmisstag när man inte förstått poängen med dem än. Static för att "slippa" göra objekt, public för att "slippa" bry sig om vad man har rätt att ändra och hämta.

Skulle du kunna försöka specifiera dig lite mer och förklara lite mer ingående.
Eller hänvisa till någon beskrivande text ?

http://www.leepoint.net/notes-java/f...c-methods.html <- Static

(varning för onödigt lång och invecklad förklaring )

Public/private

När det gäller public/private/protected innebär de synligheten från andra klasser och paket. Här är en beskrivning på hur synligheten påverkas av dem http://java.sun.com/docs/books/tutor...sscontrol.html.

I korthet:


Poängen med dessa har med objektorientering att göra. Om en metod eller klassvariabel är public kan man komma åt (och ändra) den vart som helst ifrån. Skriver man ett litet program där man tycker man har full kontroll på allt kan detta tyckas vara "praktiskt". Men problemet är att andra delar av programmet kanske ändrar något de borde. Det är faktiskt lätt hänt.

Det är inte helt lätt att förstå nyttan av dessa i början. Men tro mig, att ha variabler som "flyter omkring" och kan ändras när som helst, vart som helst, kommer snabbt göra även enkla program oläsbara så småningom.

I princip ska alla klassvariabler vara private, gör getters och setters för dem istället (alltså små metoder som returnerar värdena på variablerna), då kan man kontrollera att de inte ändras på felaktiga sätt.

Med metoder är det bäst att tänka på vad klassen gör och skriva upp de metoder som behövs för att utföra det. Dessa blir då public. Men finns några hjälpmetoder som göra delar av det klassen ska utföra så håll dem private. Även om de inte ändrar på några variabler (och därför kanske är helt "ofarliga") så blir det mycket enklare att hålla reda på vad klassen kan utföra om bara de grundläggande metoderna är public.

Static

tattares länk ovan förklarar det bra.

Det är egentligen rätt enkelt. Om metoden gör något med variabler som har med en instans (objekt) av klassen att göra, så ska de inte vara static.

Ett exempel på en statisk metod kan ju t.ex. vara om du har en klass "Äpplen", så kanske det finns variabler som "prisPerHekto" och "viktIKilo".

Sedan två metoder "totalPris" och "kiloTillHekto".

TotalPris räknar ut prisPerHekto*kiloTillHekto(viktIKilo). Och kiloTillhekto ovandlar vikten från kilo till hekto.

Här borde totalPris inte vara statisk för den använder sig av variablerna i instansen, medan kiloTillHekto mycket väl kan vara statisk då den bara omvandlar en godtycklig vikt i kilo till hekto och har ingenting att göra med instansen. (sedan är ju frågan om den borde finnas i just Äpplen-klassen, bättre kanske vore en klass "Omvandlare" som innehåller sånna metoder, men det är en annan fråga)

Jag hade en lärare på SU en gång i tiden som älskade metaforer (nog sett för många avsnitt av House) och kom med denna metafor för detta med public/private variabler:

Tänk dig att du har en sommarstuga du lämnar för vintern. För att spara pengar så vill du kunna säkna temperaturen. Detta vill du kunna göra remote. Du kodar ett javaprogram för att åstadkomma detta. Tänk dig en klass termostat.

Om nu mTemperatur är public kan man sätta temperaturen till vad sjutton man vill med
medans om den är private bara kan sättas med t.setTemperatur(); som kollar att man inte sätter något som är tokigt.

Bra exempel (metaforer är trevliga ).

Grejen är ju att man kan göra den kontrollen även utanför klassen.

Poängen är att det är mycket enklare att se till att alla kontroller görs om de finns inbyggda i klassen. Och det går inte att bygga in sånt om inte variablerna är private.

Nja... klasser i samma paket kommer inte åt protected. Det gör endast subklasser... och inom klassen såklart.