Příspěvky

1441

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 04. 06. 2018, 15:30:33 »

Integrační testy testují pípady užití té třídy, ne Unit testy! Unit testy, o kterých je tu řeč, testují metody té třídy izolovaně od okolí, pitvají tu třídu!

Jednotkové testy testují jednotku. Pitvavé testy pitvají třídu.
Integrační testy testují integraci třídy do systému. Proto se jmenují integrační.
Netřeba v tom hledat nějakou složitost. Prostě jen se drž názvosloví a nevymejšlej blbosti.

Člověk, se kterým má smysl na tohle vést řeč, by to měl vědět.

Jsi si jist, že máš na to posuzovat znalosti někoho jiného? Vzhledem k tomu, co tu uvádíš za bludy?

Slovy klasika, že nezkušení jsou si tak jistí, a zkušení plni pochybností.

Přeji ti hodně štěstí, už se nebudu obtěžovat ti něco vysvětlovat.

1442

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 04. 06. 2018, 15:16:30 »

1. Třeba tohle je přesně ten shit, který nechci dělat:

Kód: [Vybrat]

	DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
	DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();
	Document doc = dBuilder.parse(xmlFile);

2. Proč, když to jde takhle jednoduše:

Kód: [Vybrat]

	XmlDocument doc = new XmlDocument();  
        doc.LoadXml(xmlFile);  

A že není 2 tak obecná? Dpč, 99,5% případů užití je jen pro ten příklad č. 2!

A co na tom nechceš dělat? Ty příklady jsou zcela zaměnitelný, použij co ti přijde hezčí. Neřeší to nic z toho, co popisuješ.

Případ, kdy objekt zpracovává soubor:

Kód: [Vybrat]

class A:
    private DocumentBuilder parser
    constructor():
         DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
         this.parser = dbFactory.newDocumentBuilder();

    parse(file):
         doc = this.parser.parse(file)
         -- další logika, kdy zpracovávám doc

Případ, kdy soubor konfiguruje objekt:

Kód: [Vybrat]

class B:
    private config
    constructor(configfile):
         DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance();
         parser = dbFactory.newDocumentBuilder();
         doc = parser.parse(configfile)
         this.config = unifiq(doc)

    foo(data):
         -- další logika, kdy zpracovávám config

1443

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 04. 06. 2018, 14:59:55 »

Tak DOPRČIC, přece nebudeš mít v konstruktoru třídy parametr BufferedWriter jenom proto, abys to potom mohl otestovat? To je úplná kravina, porušuje to zapouzdřenost, vystavuješ ven vnitřnosti třídy. Prostě uděláš to, že bufferedWriter reflexí namockuješ!

Jak to vyřešíš, je druhořadé. Jednotkové testování samo o sobě vede k tomu, že ti pomáhá s dobrým návrhem kódu.

Proč je reflexe nesmysl si dobře uvědomíš v okamžiku, kdy si uvědomíš, že testováním testuješ případy užití té třídy (a správné chování v nich). Případ užití pro reflexi nějakých interních atributů (jak můžeš v jedné větě s reflexí zmiňovat zapouzdřenost?!) není, tudíž ho ani netestuješ.

1444

Vývoj / Re:OOP a pravidla pro konstruktor

« kdy: 03. 06. 2018, 23:12:49 »

Konstruktor by nemel obsahovat zadnou logiku (prestoze obcas je jednodussi podlehnout lennosti a neco do nej dopsat). Od konstruktoru se ocekava, ze inicializuje objekt, tj. priradi objekty privatnim fieldum a zkontruluje, ze tyto fieldy nejsou null, kdyz byt nemaji.

Tomuto já říkám legaci kód :-)

1445

Vývoj / Re:OOP a pravidla pro konstruktor

« kdy: 03. 06. 2018, 21:30:09 »

Mám pocit, že se tu anonym poněkud nešťastně vyjadřuje. Takže jen uvedu, co si představuju pod logikou v konstruktoru:

Kód: [Vybrat]

class A:
    private engine
    constructor(strategy, opts):
        if strategy AND len(opts) > 1:
             this.engine = strategy.many(opts)
        elif strategy AND len(opts) = 1:
             parser = new Parser()
             this.engine = strategy.many(parser.parse(opts))
        elif strategy AND empty(opts):
             throw new Exception()
        else:
             this.engine = new D()

    invoke(args):
        this.engine.invoke(args)

Sorry, nenapadlo mě teď z fleku nic složitějšího. Ale třeba anonym uvede, co si představuje, že za logiku do toho konstruktoru nepatří.

1446

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 03. 06. 2018, 21:19:02 »

Když si v testu zavoláš new A(), jsi v zadeki, protože se ti zavolá B a ty to nijak nemůžeš ovlivnit.

Ano, protože voláš B když ho volat nechceš. S mockováním to nesouvisí s testováním také ne.

Proto už z hlediska testování je na nic, když se v konstruktoru spustí nějaký návazný proces - ten musí být v metodě.

Když bude v metodě, tak z hlediska testování bude úplně stejný problém. Z hlediska mockování taky. Vůbec nic jsi tím nevyřešil.

A než přemýšlet, co se stane, tak raději budu dávat do konstruktoru pouze inicializace objektu.

Je mi líto, ale programování je o přemejšlení.

Když objekt nejprve inicializuju, pak v něm můžu mockovat potřebné věci. A pak terpve spouštím metodu, kterou chci testovat.

Ne, nemůžeš. Tím, že jsi to přestěhoval z konstruktoru do metody jsi vůbec nic nevyřešil. Furt ti to vypálí díru do zdi, furt to nemůžeš mockovat, furt to nejde testovat. Ten problém je totiž jinde.


Jestli ty se jen blbě nevyjadřuješ.

Dávat logiku do konstruktoru je IMHO naprosto v pořádku. Samozřejmě je nesmysl, dát do konstruktoru logiku "pal", když tu logiku chceš vykonat až zavoláním metody inst.pal(). Ale to absolutně nijak nesouvisí s pravidlem, který jsi postuloval na začátku. To považuju za zcela chybné.

Podle mě nemáš pravdu a přijde mi dost podivné to, co píšeš - jako kdybys to nikdy nedělal. Třídu B, která vypálí díru do zdi, budu mít jako private field v A. V testu v konstruktoru dojde pouze k inicializaci třídy A. Následně si namockuju tu třídu B v A (vytáhnu si ten private field reflexí a dám mu tam namockovanou verzi). Až potom zavolám a.hvezdaSmrti321Ted();, která uvnitř zavolá fake objekt this.b.lazerPal();.

Už ti rozumím. K tomu ti mohu říct jediné - nedělej to tak.

Private field je private. Z pohledu zvenčí neexistuje. Tudíž se netestuje. Ani reflexí, ani nijak. Tudíž to co děláš je špatné, ne proto, že by byla špatná logika v konstruktoru, ale proto, že je špatné pokoušet se nějak nabourávat do privátních fieldů, které jsi jakkoliv nasetovat - ať už v konstruktoru, nebo jinak.

Vlastně máš pravdu - tohle jsem nikdy nedělal. Ani by mě to nenapadlo :-) (Dobře, kecám, určitě kdysi dávno mě to napadlo, a možná jsem to i zkusil, ale pak mě klusic sežrali, co že to dělám za prasečiny.)

1447

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 03. 06. 2018, 15:39:54 »

Došel jsem ze zkušeností k tomu, že konstruktor je třeba výlučně používat pouze k nasetování stavu objektu. Je chyba v konstruktoru provádět jakékoliv výpočty atp., vždycky jsem se tím dostal do problémů a musel jsem to refaktorovat. Máte stejný poznatek? A pokud ano, jak jste na to přišli? Nečetl jsem o tom nikdy v žádné literatuře a přitom mi to přijde jako důležité pravidlo.

Dospěl jsem ke stejnému závěru. Podobně jako jsem dospěl k eliminaci dědičnosti ve vlastním kódu a jejímu částečnému "nahrazení" pomocí skládání jednoduchých, jednoúčelových objektů. Přesné vysvětlení, jak jsem k tomu došel, bohužel nemám. Napadá mě jen:

Složitý konstruktor (vlastně jakýkoli neautomatický) konstruktor podle mě porušuje Single Responsibility principle, kdy každá třída by měla mít jen jeden účel, tedy umožnit konkrétní instanci dělat nějakou práci. Konstrukce objektu stojí v tomto pojetí jaksi mimo. Stejně mimo jako jakákoli (statická) metoda třídy, která nepracuje s konkrétním objektem.

Příčinou mnoha zbytečně složitých - a rádoby chytře děděných - konstruktorů, které jsem viděl, je pouze neschopnost najít místo zcela mimo třídu (najít jméno), kam by autor tento kód mohl umístit. Vznikají pak případy, kdy objekt pracuje s nějakou vlastností, ale parametrem konstruktoru je konfigurační soubor a konstruktor třídy vlastnost z konfiguračního souboru "šikovně" vytáhne a tato vytažení se pak "chytře" dědí, respektive sdílí přes nějaké role.

Na jedné staně extrém, kdy v konstruktoru jen nasetujeme atributy bez jakékoliv logiky.
Na druhé straně, logiku, kterou potřebujeme nemusíme nutně implementovat v konstruktoru. Můžeme ji mět v nějakých pomocných třídách, statických metodách - každopádně se ale provede v konstruktoru. Protože kdykoliv později je pozdě.

1448

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 03. 06. 2018, 15:36:44 »

Když si v testu zavoláš new A(), jsi v zadeki, protože se ti zavolá B a ty to nijak nemůžeš ovlivnit.

Ano, protože voláš B když ho volat nechceš. S mockováním to nesouvisí s testováním také ne.

Proto už z hlediska testování je na nic, když se v konstruktoru spustí nějaký návazný proces - ten musí být v metodě.

Když bude v metodě, tak z hlediska testování bude úplně stejný problém. Z hlediska mockování taky. Vůbec nic jsi tím nevyřešil.

A než přemýšlet, co se stane, tak raději budu dávat do konstruktoru pouze inicializace objektu.

Je mi líto, ale programování je o přemejšlení.

Když objekt nejprve inicializuju, pak v něm můžu mockovat potřebné věci. A pak terpve spouštím metodu, kterou chci testovat.

Ne, nemůžeš. Tím, že jsi to přestěhoval z konstruktoru do metody jsi vůbec nic nevyřešil. Furt ti to vypálí díru do zdi, furt to nemůžeš mockovat, furt to nejde testovat. Ten problém je totiž jinde.


Jestli ty se jen blbě nevyjadřuješ.

Dávat logiku do konstruktoru je IMHO naprosto v pořádku. Samozřejmě je nesmysl, dát do konstruktoru logiku "pal", když tu logiku chceš vykonat až zavoláním metody inst.pal(). Ale to absolutně nijak nesouvisí s pravidlem, který jsi postuloval na začátku. To považuju za zcela chybné.

1449

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 03. 06. 2018, 01:51:16 »

...

Hezky sepsáno.

1450

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 03. 06. 2018, 01:20:10 »

Viz to Unit testování: třída bude mít private metody a já je budu muset mockovat. Jak budeš mockovat, když už při zavolání konstruktoru se ti spustí výpočetní logika?

Jak chceš mockovat privátní metody?
Jak to souvisí s tím, že při konstruktoru se ti spustí výpočtení logika?
Jak to jakkoliv komplikuje jednotkové testování?

Nechápu.

1451

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 03. 06. 2018, 01:18:20 »

Došel jsem ze zkušeností k tomu, že konstruktor je třeba výlučně používat pouze k nasetování stavu objektu. Je chyba v konstruktoru provádět jakékoliv výpočty atp., vždycky jsem se tím dostal do problémů a musel jsem to refaktorovat. Máte stejný poznatek? A pokud ano, jak jste na to přišli? Nečetl jsem o tom nikdy v žádné literatuře a přitom mi to přijde jako důležité pravidlo.

Ano, setkal jsem se s tímto trvrzením. Za mě mohu říct, že není správně. A doufám, že se moc nerozšíří.

Já vždycky když jsem sloučil inicializaci a výpočet do konstruktoru, dostal jsem se do slepé uličky - jednak v kódu a jeho struktuře samotné, tak při unit testování. Ani validaci bych nedělal v konstruktoru, jak říká Kit. Když potřebuju validovat nějaká data, udělám z té třídy pojo a validaci té třídy dám bokem do jiné třídy.

Rozumím. Domnívám se, že ten problém bude jinde.

Inicializace a výpočet klidně do konstruktoru, pokud to zajistí, že ten objekt bude mět méně možnejch stavů.
To, zda budeš validovat nějaké data přímo, nebo si na to vytvoříš spešl objekt je fuk, ale stejně to hodím čím dřív tím líp, takže do konstruktoru.

Pokud máš pocit, že jsi se dostal do slepé uličky, tak si nějak poznamenej konkrétní případ, a nabídni to k diskusi, jak by to řešili ostatní. Pokud jde o mě, tak vyvozuješ zbrklej závěr, který nepovede k lepšímu kódu.

1452

Vývoj / Re:OOP a pravidla pro kontruktor

« kdy: 02. 06. 2018, 20:07:32 »

Došel jsem ze zkušeností k tomu, že konstruktor je třeba výlučně používat pouze k nasetování stavu objektu. Je chyba v konstruktoru provádět jakékoliv výpočty atp., vždycky jsem se tím dostal do problémů a musel jsem to refaktorovat. Máte stejný poznatek? A pokud ano, jak jste na to přišli? Nečetl jsem o tom nikdy v žádné literatuře a přitom mi to přijde jako důležité pravidlo.

Ano, setkal jsem se s tímto trvrzením. Za mě mohu říct, že není správně. A doufám, že se moc nerozšíří.

1453

Desktop / Re:Názor na Gnome Photos a Gnome Documents

« kdy: 28. 05. 2018, 00:06:03 »

Koukám, že tým kolem Gnome jde dobrou cestou. Kritici nemají než takovou blbost. Čerstvě vydaný software, feature zaznamenaná a vypadá to, že se na tom bude dělat, ale lidi stejně můžou umřít z toho, že Gnome Photos není dokonalé už od výroby.

1454

Odkladiště / Re:Vyplatí se koupit iPhone 6S?

« kdy: 27. 05. 2018, 18:40:44 »

proc se iphone nemuze pres usb pripojit jako mass storage s tim ze bude vyhrazen nejaky r/w adresar pro nakopirovani souboru ke kterym budou mit pristup aplikace dle pripony ktere umi spoustet ?

Protože by si musel vytvořit aplikaci která by toto poskytovala jako api. iMac má všechny aplikace sandboxovaný, ty žádné adresáře nemají. Takže není kam se připojit, není kam přistupovat.

1455

Studium a uplatnění / Re:Jak hodně jste specializovaní?

« kdy: 10. 05. 2018, 21:31:56 »

...tak je to tim, že na to nemáš.

Tak, jak toto poznat, na to máme jiné, osvědčené metodiky.