Delphi - nastavenie statických premenných v triede

C# neovládam, takže neviem či som pochopil:

Delphi:

type
  TForm2 = class(TForm)
  private
    { Private declarations }
    const max: integer = 10;
  public
    { Public declarations }
  end;

Statická není to samé co konstantní.

Je to velmi velmi zly napad nieco take do OOP cpat. A vobec by som sa nedivil keby to v delphi nebolo ptz je to velmi velmi velmi zly napad.

Statické proměnné jsou zlý nápad?

V OOP ano. A vseobecne tiez. Deformuje to model vytvara bordel chaos. Stejne tak globalne premenne.
To co on chce je ze ked jeden objekt to zmeni tak sa to zmeni vo vsetkych objektoch. Otazka je to multitasking bezpecne? Druha otazka je taky OOP model logicky? Nie. Priklad mam auto, a zmenim si kolesa zo 17" na 18". V tom momente sa zmenia kolesa na vsetkych autach na svete. Nastany chaos bordel v takomto OOP modeli je snad jasny. Hlavne ak na ostatnych autach sa zmenili len kolesa, a velkost pneumatik ostala povodna

P.S> takmer vzdy je mozne to riesit normalne, bez static.

P.S.2. to co on chce by sa logicky dalo riesit napr. tak ze tu hodnotu drzi jeden nadradeny objekt (ktory vytvoril vsetky tie objekty tej podtriedy) apod.

Co se tady člověk ještě nedočte...tak static prej vnáší bordel...ach jo...a slyšel jsi někdy o statické metodě? nebo o statických konstantách třídy? statické věci jsou normální součastí OOP a využívají je i některé OOP design patterns.

Příklad s autem je hovadina až to bučí, protože jenom debil programátor by dal property, která ma představovat rozměr kol, jako static...

Zajímalo by mě jak bys udělal, třeba to, kdybys potřeboval, aby každá instance třídy X věděla, kolik jiných instancí třídy X už bylo vyrobeno, kdybys neměl static?

"aby každá instance třídy X věděla, kolik jiných instancí třídy X už bylo vyrobeno" je hovadina taka poziadavka nema vobec co hladat v OOP modeli. Ked to potrebujes mas si vytvorit jeden iny objekt ktory to bude pocitat a zabezpeci bezpecne pocitanie v multitaskingu, co tvoj sposob nezabezpecuje (resp. nie vzdy to je bezpecne). P.S. a jedine ten nadradeny objekt by sa mal zaoberat tym poctom, nie samotne objekty podradene...

Ano pouziva sa to a je to bordelchaos. Staci si pozret kod MFC od MS a clovek sa ide dogrcat.

Když nejsi debil, tak to uděláš tak, aby to bylo bezpečné vždy...

Nejsem si teď jistý, ale myslím, že např. v javě je dokonce zaručeno, že každé vlákno uvidí ve static fieldu stejnou hodnotu...

Tak v multitaskingu to bude bezpečné vždy. Pokud ti jde o multithreading, tak se to dá zabezpečit taky.
To, že to někdo používá špatně, ještě neznamená, že je to špatné úplně.
MS se ti nelíbí, to všichni víme, ale proč je to i Javě nebo C++?

Lebo podaktori chaosaci by bez toho neprezili.

BTW. static je presne to iste co globalna premmena (akurat ma inu viditelnost). O nevhodnosti pouzivania globalnych premennych sa uci v zakladoch programovania (experti v MS by si mali dat nejaky kurz :D)

Pojem jako globální proměnná v kontextu OOP nemá žádný význam. A zato statické proměnné (a metody) existují a používají se. Pěkným příkladem může být třeba logování nebo vzor factory method.

Ja sa nebavim o tom ci existuju, samozrejme ze existuju ptz existuje datovy segment. Ja sa bavim o vhodnosti ich pouzivania vzhladom na naslednu bezpecnost a udrziavatelnost kodu.

Nemozes cakat od kazdeho programatora ze bude robit vsetko dobre, to by sme potom mohli ostat u obycajneho C a nebolo by treba vobec ziadne OOP, keby kazdy programator robil vsetko perfektne. OOP vzniklo len preto aby bol kod lepsie usporiadany (ziaden iny dovod na OOP neni, akakolvek funkcionalita sa da urobit aj bez OOP). Ide len o to jak urobit kod tak aby jeden programator ZAMEDZIL dalsim programatorom (pouzivajucim jeho modul) aby ostatni nerobili s jeho modulom nebezpecne veci. Na to bol vymysleny OOP a private premenne atd. A teraz staticom zas do OOP vnasas nebezpecnost a pripadny chaos. Ja osobne by som sa tomu snazil vyhnut a urobit model inac.
P.S. ked chce nech si to pouziva, mne je to fuk. Len sa este budem dnes asi 3hodiny divit na co mu taka kravina je.

A víš o tom, že i static fieldy mohou být private případně i final?

Samozrejme mozu ale aj tak je to chaos ptz na stejnu vec leze 150 inych veci priamo.

V javě je to tuším tak, že static final má zaručenou správnou cross-thread visibility (tohle vím jistě). Pokud by to bylo jen static, muselo bý to být ještě deklarováno jako volatile, aby cross-thread visibility fungovala správně (tohle jistě nevím).

Takže je to zase v rukou programátora, buď to udělá správně, nebo ne. Rozhodně to ale není tak, že static je špatné a o pokud se to udělá dobře, je jedno kolik věcí tam leze na přímo...

Furt sme u toho ze "buď to udělá správně, nebo ne". Musi sa aj brat ohlad na to ze aplikacie sa vyvijaju t.j. najprv sa urobi nieco male, potom sa prida hento, potom tamto, potom sa tam prida thread, no a doteraz to "robil spravne" aj keby to nerobil thread-safe, a po pridani threadu uz vsetok kod ktory bol doteraz "spravne" uz neni spravne, a ten kto tam pridava thread vobec nemysli na nejake staticy kdesi uplne inde medzi dalsimi 1250timi subormi kodu, ptz on ma za ulohu len pridat thread a nie myslet na dalsich 1250 suborov. Vseobecne to veci podla mna len komplikuje aj ked na prvy pohlad to vyzera ze je super jednoduche pouzit static a hura.
Jasne ze ked si robim doma utilitku ktoru viem ze nebudem vyvijat dalej ani zverejnovat tak tam nadrbem aj globaly (v C++ sa to da :) apod ptz to robim narychlo za pol hodinu cely program a nemam cas vymyslat modely, ale ked clovek nieco chce robit poriadne tak sa treba najprv zamyslet ze ktory komponent bude robit co presne a jak presne a potom zisti ze sa to cele da usporiadat uplne inac a lepsie.

To je to co som mu chcel povedat. Aspon to ma na zamyslenie :) Jak urobit static premennu v delphi uz som mu napisal takze ked chce, pouzije static.

BTW. samozrejme u multithreadingu sa musi davat pozor aj na normalne premenne (t.j. ne-static) u stejneho objektu ktory sa pouziva vo viacerych threadoch, static to len posunie z problemu "stejny objekt v roznych threadoch ma problem" na "akykolvek objekt stejnej triedy v roznych threadoch ma problem"... (P.S> a to je drasticky rozdiel, rozsvecuje sa mi v hlave alarm hukacka ked daco take vidim :D)
Zavisi to aj od prekladaca/interpreteru (java garantuje toho viac ako normalne prekladace C++ apod), je to samozrejme komplexna problematika, neda sa to zjednodusit na static versus ne-static (aby to niekto nepochopil blbo :)

...akykolvek objekt stejnej triedy v roznych threadoch ma problem...

Vídím, že vůbec nevíš, co to je static. Když chceš přistupovat ke static fieldům, tak vůbec nepořebuješ objekt, static proměnné jsou proměnné třídy, ne instancí.

OMG ale k tej premennej pristupujes predsa z objektov (tie mozu pouzivat metody alebo premenne triedy). Ked ju navyse urobis public a pristupujes tam este aj odinokadial, tak to je potom este horsie.
Vidim ze nemas o tom sajnu ty, prosimta radsej sa nepokusaj robit multithread aplikacie pokial si to nedostudujes.

P.S. priklad:
vytvoris objekt A
zavolas A.neco_urob_s_premennou()

v dalsom threade vytvoris objekt B stejnej triedy ako A
zavolas B.neco_urob_s_premennou()

Ak je premenna normalna tak s tymto konkretnym pripadom neni problem je to bezpecne (musis davat pozor len vtedy ak by si predal druhemu threadu ten konkretny objekt A, co je skor vyniomcne).
Ak je premenna staticka tak s tymto pripadom mas problem a sakra velky, musis to neco_urob_s_premennou() mat thread safe. No a potom pride este aj nejaky idiot a napise este aj if(B.premenna == 0) B.premenna++ a potom uz mozes povedat spravnej funkcionalite programu dovidenia uplne.

Ale houby, pokud je to static nebotřebuju žádný objekt, volám přímo NázevTřídy.názevProměnné případně .názevMetody(). Nauč se základy OOP a pak poučuj...

if(B.premenna == 0) B.premenna++

Pokud jde o atomické operacne není toto žádný vůbec problém. (v Javě AtomicLong a jeho compareAndSet(), případně pokud je premenna deklarována jako volatile)

Jezisikriste !!!!!

if(B.premenna == 0) B.premenna++
je v multitaskingu problem vzdy !!! OMG OMG OMG. Task switch moze nastat po teste a pred zvysenim. Prihlas sa do MS tam takych programatorov uznavaju.

ked pouzijes nazev tridy (co je mimochodom jedno u statickej metody ale neni to jedno u normalnej metody) tak to nic nemeni na tom probleme co som pisal. Ja som nikde nepisal ze urob_neco_s_premennou je staticka metoda (nemusi byt) a k tomu o co pisem je to totalne irelevantne ze ci nieco volam cez nazov triedy alebo cez nazov objektu.

Nevím, ja v C++ ale javě to rozhodně problém není a nezajímá mě to, protože si to ošéfuje JVM. Já se musím starat jen o vlaknovou bezpečnost v rámci mé aplikace, context switch mezi aplikacemi běžícími v OS mně nezajímá a nemusím ho řešit.

No tak rob v jave ale nie v C++/delphi.

Task switch som myslel aj switch medzi tvojimi vlaknami. Tiez moze nastat medzi tym. V normalnej aplikacii (ak tam neurobis critical section). Co presne si jak riesi JVM je uplne nieco ine to je intepretovane a tam plati to co napisal autor JVM do navodu.

Este (uz posledny moj post tu uz nemam naladu na to) precitaj si napr toto
http://blogs.msdn.com/b/oldnewthing/archive/2004/0 3/08/85901.aspx
zdanlivo perfektny napad ako nieco riesit pomocou static, a v multithreadingu sa z toho stava nocna mora (hladanie chyby je takmer nemozne ptz ti bude uplne nahodne nastavat napr. "program proved neplatnou operaci" a je velky problem to zdebugovat (ptz by si musel chytit debuggerom pripad kedy zrovna pride context switch v nevhodnom momente aby si videl ze co je zle, co je jak vyhrat v sportke).
P.S. samozrejme da sa to urobit aj thread-safe aj so static, ale da sa to urobit aj bez static tak ze hodnotu bude drzat nejaky objekt (inej triedy).

BTW a nepisem to kvoli nejakemu pocitu ze som genius alebo co (mam uplne na haku co si kto o mne mysli), len upozornujem (vsetkych kto to tu pripadne bude citat) na rizika.

ale da sa to urobit aj bez static tak ze hodnotu bude drzat nejaky objekt (inej triedy).

A to snad bude automaticky thread-safe? Určitě ne.

Ne. Ale budes to mat oddelene od inych tried (nemoze si Dezi povedat v nejakej triede XY ze if XY.premenna XY.premenna++ a zabudnut na to ze to je static a ze tam musi robit critical section). Je to proste potom oddelene a pristup mozes umoznit len striktne cez metody.
P.S> nevyhoda je ze musis furt drzat a predavat kazdemu ukazatel na ten objekt.

Možná je problém, že oba máte zkušenosti s jinými jazyky a programovým prostředím, kde se můžou uplatňovat v některých věcech naprosto jiné postupy a praktiky. Co se týká Javy, já osobně statické prvky moc často nepoužívám. Jedná se ale o naprosto běžnou a pro některé věci nepostradatelnou součást jazyka. K vláknové bezpečnosti - téměř ve většině případech se řeší přístup více vláken ke stejnému objektu nebo stavu tohoto objektu. Naprosto běžná věc. Proto je důležité znát principy jako jsou safe publication, vláknová bezpečnost třídy (a řádně to dokumentovat), atd. Statická proměnná třídy v Javě má tu výhodu, že pokud je hodnota proměnné přiřazena během inicializace třídy, můžou k ní bezpečně přistupovat kterékoliv vlákna, dokud některé z nich nezměnní hodnotu proměnné. Vůbec v současné době díky vylepšenému memory modelu a Concurrent utilities (takový .NET si může nechat jen zdát, i když nevím, co je nového od verze 4) je programování paralelních programů v Javě hodně usnadněno.

Ano ja o C++/delphi on o jave. Ale dotaz bol snad o delphi tak nechapem preco sa tu taha java. Java je uplne nieco ine.
P.S. a dovolim si tvrdit ze static NENI nepostradatelny. Co je "bezne" mi je fuk. V stredoveku bolo bezne odsekavanie hlav. Mam teraz kvoli tomu sekat aj ja? P.S. bezne je aj to, ze programy nefunguju tak jak maju.

S tím poslední souhlasím, když si spousta programátorů vystačí s tím, co znají ze školy a konec, jak jsem za pár let praxe "u nás" poznal. No a jestli není static nepostradatelný.. nevím, jestli mi něco neuniká, ale momentálně mě třeba nenapadá, jak bys naimplementoval design pattern Singleton bez možnosti si ho uložit do statické proměnné. Pravda ale, že nepostradatelnost vzoru Singleton je snad ještě více diskutabilnější. 8)

Urobis si jeden objekt triedy aplikacia ktory sa vytvori na zaciatku programu a vsetko taketo bude v nom a nikde v programe nebude nikto vytavarat dalsi objekt triedy aplikacia :) Samozrejme ze je to potom skoro to iste co static, ptz ta trieda "aplikacia" musi byt potom tiez thread-safe kedze kazdy v aplikacii potom dostane nejaky ukazatel na ten objekt apod. Ale aspon su potom multithreading-kriticke veci koncentrovane do jedneho classu a moze sa o to starat nejaky master programmer, zadefinuje v tom calsse vsetko privat aby Dezovia nepristupovali na to priamo, a pristupove fcie urobi thread-safe (v critical section) t.j. moze to byt potom vo velkom projekte bezpecnejsie ako ked si kazdy Dezo urobi staticy kde chce a potom to pusti v 10 threadoch. Je to vec pristupu, vsetko sa da urobit vela roznymi sposobmi. Ked chcem jedno jablko tak mozem si ist kupit jedno jablko, alebo mozem presvedcit predavaca ze ked si pridem niekedy kupit 2jablka aby mi dal 2x stejne jablko (t.j. urobim z predavaca vzor Singleton :D) a tiez budem mat vo vysledku 1 jablko.

To ale nebude Singleton. Protože půjde furt volat konstruktor té třídy! Když chceš napsat singeton v pravém smyslu slova, tak bys musel zabezpečit to, aby mohla v celém programu existovat jen jedna instance té třídy, která má singletonem být.

Většinou se to dělá tak, že se konstruktor schová. Udělá se private. A pak se deklaruje statická metoda getInstance(), která zaručí, že vrátí vždy odkaz na stejný objekt, který si ta třída musí držet ve static fieldu. Např.:

class Singleton {

 private static volatile Singleton INSTANCE = null;

 // privatni konstruktor, neni videt z venku
 private Singleton(){}

 public static Singleton getInstance(){
  if (INSTANCE == null) {
     synchronized (Singleton.class) { 
       if (INSTANCE == null) { INSTANCE = new Singleton();}
     }
  }
  return INSTANCE;
 }   
}

Tenhle příklad vytváří instanci Singleton až je opravdu potřeba. Kvůli tomu je tam zahrnut i double-check locking pattern a tím je zaručeno, že getInstance nikdy nevrátí null, ale vždy odkaz na Singleton.

Uff... Idu spinkat, dobrou...

OMG ale ten samotny Singleton neni potreba. Ked chcem jedno jablko nepojdem si kupovat 2 jablka a chciet od predavaca aby mi aj tak dal len jedno. Ak jasne oddelis to co ma byt v aplikacii len raz, tak to nikto nebude vytvarat druhykrat. Vseobecne ak to je nutne kvoli specialnym veciam (raz za milion rokov) tak ano to je jeden pripad kedy pouzijes static a osetris to potom poriadne. Raz za milion rokov a msx to urcie nepotrebuje.

BTW. keby som tu nenapisal ze static je "velmi zly napad" tak by msx mozno ani nevedel ze pre multithread musi zmeny (a testy+zmeny alebo zmeny so zavislostami, inicializaciu(!!!) - vid link vyssie) staticov poriadne osetrovat (kriticka sekcia = u teba to "synchronized", apod zavisi od jazyka resp. prostredia)

BTW.2. samotny singleton by mohol byt podporovany prekladacom (podobne ako mutexy ktore vpodstate tiez potrebuju niekde v pamati nejaky aspon 1 byte spolocny pre vsetkych) a potom by si zas nepotreboval static ptz mas vsetko v prekladaci :)
Ok ja uz fakt koncim toto by sme mohli natahovat donekonecna :)

Já sice své příklady ukazuji na javě, ale hlavně narážím na to, že ty tvrdíš, že použivat static obecně, je hovadina a špatné. Podle mě (a ostatních daleko zkušenějších programátorů) je to běžná součást OOP a není třeba se jí vůbec vyhýbat (pokud se používá správně).

Ja tvrdim ze to je riskantne v mutithreade (NEpisem o jave) a vo vacsine pripadov to neni nutne ptz to v popise reality objektami je nezmysel. Co sa ukazalo podla mna aj nizsie u dotazovatela - ze to chcel pouzit na nejaku velkost obrazku co je z hladiska popisu reality nezmysel. Vsetky obrazky na svete maju stejnu velkost?

... samozrejme su (zriedkavo :) pripady kedy je vhodne resp. rychlejsie alebo jednoduchsie pouzit static (aby si si zas nemyslel ze som to vzivote nepouzil :), ked to povazazujes za vhodne tak to pouzi vsak ja to nikomu nezakazujem, ale sa poriadne zamysli nad thread-safety ked sa ta premenna meni. A najlepsie urobit ju protected.

Som ti to nasiel googlom, v Delphi na to je "class var"
http://www.aspfree.com/c/a/.NET/The-Delphi-Languag e-Part-2/5/

To som potreboval, dakujem.

Vyuzitie to ma a dost opravnene. Ja to napr. potrebujem na to, aby som si do tej statickej premennej ulozil rozmer obrazka, ktory sa nikdy nebude menit. V o vzorcoch predsa nebudem ako debil stale zadavat cislo. Raz tocvlozim do premennej a odkazovat budem cez nu. Takcl isto to nepotrebujem ako konstantu s viditelnostou zvonka, pretoze ju nikde inde nepotrebujem, zbytocne mi bude oblbovat doplnovac syntaxe.

Zapis z prveho prispevku mi lazarus nebral, preto tato otazka.

MM, vsetko ma zmysel, len tomu treba rozumiet.

Asi mi chyba const. Zajtra sa na to pozriem.

Nema to zmysel. Take veci maju byt inde, resp. v objekte obrazok ktory je len jeden. Iny obrazok bude mat rozmery ine, trieda stejna (obrazok). Rozmyslas blbo.

P.S. a pevne veci ktore sa nikdy nemenia sa robia cez konstanty alebo #define.

Ide o to, že nevieš čo v mojom programe ako bude. Obrázky sú v resource a budú nemenné. Majú pevné rozmery a tie sa nikdy nebudú meniť. Je nezmysel, aby som si zisťoval programovo rozmer obrázka, ktorý už dopredu viem. Ak v budúcnosti dám iné obrázky (o čom pochybujem), tak si tie rozmery v tej statickej premennej len zmením.

Prečo nie konštanta? Pretože konštanta je viditeľná von a ja potrebujem tú hodnotu len v tejto jedinej triede a nikde inde. Takže ju potrebujem zapúzdriť do nej. Má to svoje výhody a to napríklad pri použití doplňovača syntaxe mi nebude túto premennú ponúkať, pretože v triede bude v časti private, čiže ju nič okrem tejto triedy vidieť nebude. Keďže statická premenná nie je v skutočnosti konštanta, programovo ju môžem zmeniť. To ale neurobím, pretože to nebude mať význam. Budem ju používať ako konštantu. Keďže to bude konštanta (pre mňa) nemá význam, aby s každou inštanciou triedy vznikala znova a tak ju tieto inštancie budú zdielať ako si správne napísal.

Prečo nie define? No lebo Delphi, resp. Lazarus nič také nepozná, aspoň nie v takom zmysle ako o tom uvažuješ ty.

A aký je príklad využitia statických premenných? Napríklad v matematickej triede, ktorá bude počítať rôzne funkcie sa dajú takéto premenné použiť ako konštanty (napr. pí a podobne). Používateľ túto konštantu nezmení, pretože mu to trieda nedovolí a trieda túto konštantu tiež nemá dôvod meniť.

Takže všetko má svoj zmysel. Aj používanie statických členov pri programovaní. Musel by si viac programovať v OOP, aby si pochopil rôzne princípy. Napr., kým som ja nevidel C# a spôsob programovania v ňom, tak som kopec vecí z OOP nerozumel. Hlavne som nechápal základnému princípu OOP a to zapúzdreniu. Metódy som volal 5. cez 9. a podstatné bolo, že to fungovalo. Potom som sa tomu trochu venoval viac a pochopil som, že kopec vecí, čo som kedysi robil okľukou sa dalo robiť oveľa lepšie.

Pouzivat staticke premenne namiesto konstant je IMHO nezmysel.
Konstanty nie su "viditelne zvonku" (a su v kodovom segmente t.j. mozu byt sucast istrukcii co moze byt tiez vyhoda ako ochrana proti zmene "nasilim" (hackerom :D)), a mozu byt aj private a aj sucast triedy, "const" sa da pouzit uplne presne na stejnych miestach ako "static" z hladiska viditelnosti platia pre to uplne stejne pravidla (//edit: nie som si sice teraz zhlavy 100% isty, ale na 99% :)
Const ma navyse aj vyhodu kontroly compilera - akonahle chces const premennu niekde zmenit tak compiler vyhodi chybu co je vyhodne na kontrolu chyb v kode, pri kompilacii.
Potrebujes const a nie static. resp mohol by si ten rozmer obrazku vycitat z obrazku ptz o rok az budes chciet obrazok zmenit tak ti garantujem ze uz nebudes vediet co vsetko musis este spolu s nim menit v programe (viem o com hovorim je to 20 rokov skusenosti s tym ze o pol roka nema programator uz ani sajnu ze co pred pol rokom naprogramoval a jak :D)
Vyskusaj const a uvidis...

Aj keď nie som programátor v pravom zmysle slova, neživím sa tým - tak s týmto tvrdením úplne súhlasím

... inac chciet konstatntu na velksot v triede "obrazok" je z principu (objektovy popis reality) nezmysel, pretoze to by znamenalo ze vsetky obrazky na svete maju stejnu velkost. Vyhoda OOP je aj to ze ked si urobis univerzalnu triedu na pracu s obrazkami tak ju mozes pouzivat aj v inych programoch (ako modul) ale potom tam predsa nemoze byt konstanta na velkost. Velkost je vyhradne vec jedneho objektu (instancie), t.j. mala by byt v normalnych (nie static) premennych a pri vytvarani objektu alebo pri otvarani suboru .bmp objektom apod si objekt tie premenne ma nastavit spravne na spravnu velkost bud podla suboru alebo sa da velkost obrazku ako parametre konstruktora apod (a tie premenne kludne mozu byt private).
Tak bude ta trieda "obrazok" univerzalna a mozes ju pouzit aj o pol roka v uplne inom programe a uplne inym sposobom. Skus sa zamyslat aj nad tym ked vytvaras triedy..

P.S> neni to nutne uplne vzdy dodrziavat, samozrejme ked si len lepim narychlo nejaku malu utilitku tak tiez tam nadrbem narychlo co ma napadne a nerozmyslam nad nejakou univerzalnostou :) Vseobecne ale to neni korektne (nejaky narychlo polepeny kod by som nikomu nedal citat ani dalej ho vyvijat :D)

Jenomže ty jsi vůbec nepochopil čeho chce dosáhnout. To je pak problém...

On totiž, tohle:

inac chciet konstatntu na velksot v triede "obrazok" je z principu (objektovy popis reality) nezmysel, pretoze to by znamenalo ze vsetky obrazky na svete maju stejnu velkost

vůbec nechce.

On chce mít v nějaké třídě deklarovat už instanci třídy Obrazek jako statický field. Protože v dané třídě (případně i v jiných) bude využívat jenom tu konkrétní a jedinou instanci třídy Obrazek, bude tento field navíc i konstatntní. Čili něco jako:

class A {
   // nemenny konstantni obrazek
   public static final Obrazek OBRAZEK = new Obrazek();
}

Když bude chtít daný obrazek někde v kódu použít tak tam předá jen A.OBRAZEK. Když se rozhodne OBRAZEK vyměnit za jiný obrázek změní se to jen v třídě A, nikde jinde.

Ale sak to nemoze urobit si univerzalnu triedu Obrazek a velkost zadat v konstruktore? Napr 160x80:

public Obrazek OBRAZEK = new Obrazek(160,80);

velksot si ulozi v konstruktore do normalnych premennych a bude mat univerzalnu triedu "Obrazek" ktora spravne popisuje realitu (nie kazdy obrazok v realite ma stejnu velkost), a ktoru moze pouzit aj v dalsich 50 programoch potom aj s obrazkom 350x640 a aj s 200x500 atd. Nechapem co riesite, neni v tom ziaden problem a nepotrebujes ziadne static.

To může, ale třídu Obrazek tady nikdo nevyvijí, on se jenom ptal jak uložit konkrétní instanci pomyslné třídy Obrázek (která už stoprocentně v API Delphi je) do static fieldu. A pak jsi přišel ty, žačal jsi mluvit o úplně nesouvisející věci, že má špatně modely apod.

Takže ještě jednou: nevyvíjime třídu Obrazek, jen chceme uložit odkaz na její instanci do static fieldu v Delphi.

Citujem msx:

Ja to napr. potrebujem na to, aby som si do tej statickej premennej ulozil rozmer obrazka, ktory sa nikdy nebude menit.

Takze nie on nechce staticky obrazek, on chcel staticke rozmery co je blbost.

Ano, statické rozměry té jedné konkrétní instance Obrazku, kterou si pak někde v programu vytvoří. Protože má obrázky jako resources, tak je jasné, že se jejich rozměry za běhu programu měnit neboudou. V podstatě tím docílí jenom toho, že nebude mít v programu magic values, ale bude mít zavedené konstanty na rozměry obrázku a statické je chtěl mít zřejmě proto, aby se na ně mohl odkazovat i bez toho, aniž by měl v ruce instanci té třídy, kde si ty konstanty deklaroval.

Tak toto co popisujes je IMHO ten bordelchaos o ktorom som pisal uz na zaciatku. Ale sak ok programujte jak chcete mne je to fuk, potom o pol roka sa vas opytam ci sa este v tom kode vyznate... Ja uz som napisal vsetko co som chcel, ja s tym proste nesuhlasim abudem programovat aj nadalej po svojom (a v drvivej vacsine pripadov potom program spustim a funguje na prvy krat 100% a idem domov nemusim 3dni a 4noci debugovat).

P.S. Rozmery obrazku su zasadne OBRAZOK.DajRozmery() nic ine neni u mna pripustne.

jaj ty myslis ako ze bude mat static ten OBRAZEK, my sa tu v tejto diskusii fakt nechapeme :D On pisal ze chce mat static velkost obrazka a nie ten obrazok samotny.

O tom co pises ty uz som pisal hore 3x, ano moze si ho urobit static v triede alebo proste urobit na zaciatku programu len jeden objekt a bez static, je to uplne fuk.
(P.S. a trvam na tom ze staticky zapuzdrena trieda moze byt za urcotych kolnosti problem v multithreadingu, podobne ako to co sa pise v linku ktory som uz daval vyssie http://blogs.msdn.com/b/oldnewthing/archive/2004/0 3/08/85901.aspx. Java to ma mozno osetrene ale vseobecne mimo javy to moze byt riziko).