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