Java a statické metody

[Kit]

Používání standardních typů jako například String nebo int vám nevadí?

Docela mi vadí, že třídy String a Integer jsou final. Nemohu je tedy dědit, ale musím je obalit. Snad k tomu měli tvůrci nějaký závažný důvod.

[Reklama]

[Filip Jirsák]

Třeba že je najednou ten Transformer součástí rozhraní i když by nemusel? Někdy je to ok, ale na to aby to byla obecná best-practice je tam až moc podmínek.

Nevidím žádný přínos v tom, že to bude Transformer používat tajně – zato spoustu nevýhod. A když už bych měl pocit, že existuje jenom jediná správná implementace Transformeru, můžu udělat druhý bezparametrický konstruktor, který sám získá tu jedinou správnou implementaci.

[JSH]

Nevidím žádný přínos v tom, že to bude Transformer používat tajně – zato spoustu nevýhod. A když už bych měl pocit, že existuje jenom jediná správná implementace Transformeru, můžu udělat druhý bezparametrický konstruktor, který sám získá tu jedinou správnou implementaci.

Zádný přínos? Takže to že tímhle vytažením zviditelním a tím zabetonuju kus vnitřností nějaké třídy ničemu nevadí? Já si naopak nepamatuju situaci, kdy bych měl potřebu nějaké třídě kecat do toho, jak si uvnitř transformuje data.

[Viky]

Tohle je fakt legrační. Jak hádání se, jestli je lepší psát 5-5 nebo -5+5. Pak někdo přijde s tím, že lepší je 5+(-5) a další, že všichni jsou lamy, jedině ln(1) je správně. Pak někdo opáčí, že nejčistší je to udělat jako ln(-exp(i*pi)).

[Ondra Satai Nekola]

Tohle je fakt legrační. Jak hádání se, jestli je lepší psát 5-5 nebo -5+5. Pak někdo přijde s tím, že lepší je 5+(-5) a další, že všichni jsou lamy, jedině ln(1) je správně. Pak někdo opáčí, že nejčistší je to udělat jako ln(-exp(i*pi)).

Ne, tady jde o to, jak lepit dohromady programy, co nechavat napevno, co menitelne a jak to testovat.

[Reklama]

[BoneFlute]

Zádný přínos? Takže to že tímhle vytažením zviditelním a tím zabetonuju kus vnitřností nějaké třídy ničemu nevadí? Já si naopak nepamatuju situaci, kdy bych měl potřebu nějaké třídě kecat do toho, jak si uvnitř transformuje data.

No, tohle je za celé vlákno jediná zajímavá poznámka.

Je pravda, že do toho mohu vstříknout objekt, který bude mět sice naprosto stejnou signaturu, ale zcela jiné chování. Jenže, opravdu?

Funkce sin() vždycky vrátí číslo. Můžu nějak záviset na tom, zda to číslo bude platné? (Skutečnost, že díky neplatnému sin() nemůžu očekávat platné hodnoty volajícího je samozřejmá.)
Když mi bude funkce vracet pole, a to pole nebude obsahovat správné hodnoty, tak by mi signatura měla zajistit, že to celé nerozbije, ale, že to bude počítat špatně, to je očekávatelné. Součást signatury je neurčitelnost, kolik návratových hodnot mi to v tom poli vrátí. Takže to musím doladit ifama.

Na druhou stranu, pokud defaultní implementace je řešená s chybou, tak tu chybu nemohu opravit, protože tato třída na tom závisí, a já nemohu vědět, zda o té chybě volající ví, nebo ne.

Zajímavé.

[zboj]

Tohle je fakt legrační. Jak hádání se, jestli je lepší psát 5-5 nebo -5+5. Pak někdo přijde s tím, že lepší je 5+(-5) a další, že všichni jsou lamy, jedině ln(1) je správně. Pak někdo opáčí, že nejčistší je to udělat jako ln(-exp(i*pi)).

Ta poslední varianta je nejhezčí, říkal to nějaký Euler

[balki]

Pridam sa aj ja k mudrovaniu. Toto bola, jedna z otazok, co som si kladol. Ci je vyhodnejsie pouzivat singleton, alebo staticke metody.

Nevyhoda je statickych metod je v tom, ze ich nejde prekonavat (override), a viazu sa na triedu, nie na instanciu. Pokial viem, ze pouzijem vsate rovnaku implementaciu,  staticka metoda staci. Singleton je sikovnejsi, ked som si nie celkom isty, ci nebudem potrebovat viac instancii nabuduce, pripadne pozmenit spravanie.  Proste  prepisem factory method a instancujem tak ako zrovna potrebujem. Pripadne, ak viem, ze mozno budem tu metodu predavat ako parameter. (Presnejsie povedane, objekt, ktoremu patri)

Vhodne pouzitie statickych metod su bezstavove metody, ktore proste zoberu vstup, daju vystup.   

[Filip Jirsák]

Vhodne pouzitie statickych metod su bezstavove metody, ktore proste zoberu vstup, daju vystup.

Podle mne je tam ale velmi podstatné to „prostě“. Pokud ta statická metoda má triviální kód a je v podstatě náhradou céčkového makra, není důvod nepoužít statickou metodu. Pokud je ten kód složitější nebo se tam volají jiné služby, nedá se vyloučit, že ten kód někdy bude potřeba pozměnit. Aby to nedospělo k tomu, že ta statická metoda bude v různých variantách rozkopírována po celém programu.

[Franta <xkucf03/>]

Používání standardních typů jako například String nebo int vám nevadí?

Docela mi vadí, že třídy String a Integer jsou final. Nemohu je tedy dědit, ale musím je obalit. Snad k tomu měli tvůrci nějaký závažný důvod.

Co třeba STFW? :-) Hned první odkaz: Why is String class declared final in Java?

Neměnné objekty mají řadu výhod a dost usnadňují práci. Naopak kdyby šlo obsah Stringu měnit, tak by to vedlo k dost nevyzpytatelnému chování a programy by byly dost nespolehlivé – resp. musel by sis všechny vstupní parametry okopírovat do vlastního objektu, abys měl jistotu, že ti nikdo nebude měnit ty hodnoty pod rukama. Hodně lidí by se střelilo do nohy (asi jako v případě statických lokálních proměnných).

Pokud chceš obsah měnit, tak používej StringBuilder/StringBuffer. Pokud chceš přidávat chování, obal to vlastní třídou. Pro čísla platí totéž.

[zboj]

Používání standardních typů jako například String nebo int vám nevadí?

Docela mi vadí, že třídy String a Integer jsou final. Nemohu je tedy dědit, ale musím je obalit. Snad k tomu měli tvůrci nějaký závažný důvod.

Co třeba STFW? :-) Hned první odkaz: Why is String class declared final in Java?

Neměnné objekty mají řadu výhod a dost usnadňují práci. Naopak kdyby šlo obsah Stringu měnit, tak by to vedlo k dost nevyzpytatelnému chování a programy by byly dost nespolehlivé – resp. musel by sis všechny vstupní parametry okopírovat do vlastního objektu, abys měl jistotu, že ti nikdo nebude měnit ty hodnoty pod rukama. Hodně lidí by se střelilo do nohy (asi jako v případě statických lokálních proměnných).

Pokud chceš obsah měnit, tak používej StringBuilder/StringBuffer. Pokud chceš přidávat chování, obal to vlastní třídou. Pro čísla platí totéž.

Stačilo by mít něco jako MutableString. Měnitelnost instancí hezky řeší ObjC. V C++ to mají podobně, sice třeba std::string se dá měnit, ale při práci s kolekcemi se na klíče dělá standardně CoW.

[Ondra Satai Nekola]

Stačilo by mít něco jako MutableString. Měnitelnost instancí hezky řeší ObjC. V C++ to mají podobně, sice třeba std::string se dá měnit, ale při práci s kolekcemi se na klíče dělá standardně CoW.

Nemas snad StringBuilder? Nastesti se neda moc dobre pouzivat tam, kde String.



Btw: nemichal bych tu moc final ve smyslu "nelze podedit" s immutable objekty. To spolu souviset muze a nemusi.

[zboj]

Stačilo by mít něco jako MutableString. Měnitelnost instancí hezky řeší ObjC. V C++ to mají podobně, sice třeba std::string se dá měnit, ale při práci s kolekcemi se na klíče dělá standardně CoW.

Nemas snad StringBuilder? Nastesti se neda moc dobre pouzivat tam, kde String.



Btw: nemichal bych tu moc final ve smyslu "nelze podedit" s immutable objekty. To spolu souviset muze a nemusi.

StringBuilder je něco úplně jiného, odpovídá stringstream a používá se v jiných případech než měnitelný řetězec.

[Kit]

Docela mi vadí, že třídy String a Integer jsou final. Nemohu je tedy dědit, ale musím je obalit. Snad k tomu měli tvůrci nějaký závažný důvod.

Neměnné objekty mají řadu výhod a dost usnadňují práci.[/url]).

Neměl jsem na mysli finální objekty (ty mi naopak vyhovují), ale finální třídy. Nemohu například napsat

Kód: [Vybrat]

class Jmeno extends String { ...

[perceptron]

Neměl jsem na mysli finální objekty (ty mi naopak vyhovují), ale finální třídy. Nemohu například napsat

final String znamena ochranu pred Kitom ktory oddedi od zakladnej immutable datovej struktury, urobi z nej mutable a zachrani projekt