Delphi - nastavenie statických premenných v triede

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?

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...

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.

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 :)

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.

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.

... 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.

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