Java projekt co vás bavil

[Kit]

Bez použití dědičnosti by sis v Javě ani neškrtl...

To je problém Javy, ne můj.

Když nepoužíváš Javu a neprogramuješ objektově, tak tě to nemusí trápit.

[Reklama]

[zboj]

vícenásobná dědičnost v C++ je píčovina

To je dědičnost obecně.

P.S. Dědičnost dobře odhaluje trotly, jakmile někdo tvrdí, že obdélník má dědit ze čtverce, je jasný. Dědičnost má opodstatnění v některých speciálních případech, ale v podstatě vždy stačí protokoly/rozhraní. Jiná otázka je implementace, proměnné typu protokol mají jistý overhead.

[zboj]

Bez použití dědičnosti by sis v Javě ani neškrtl...

To je problém Javy, ne můj.

Když nepoužíváš Javu a neprogramuješ objektově, tak tě to nemusí trápit.

Píšu objektově, ale ne v Javě. Tož tak.

[Kit]

vícenásobná dědičnost v C++ je píčovina

To je dědičnost obecně.

P.S. Dědičnost dobře odhaluje trotly, jakmile někdo tvrdí, že obdélník má dědit ze čtverce, je jasný. Dědičnost má opodstatnění v některých speciálních případech, ale v podstatě vždy stačí protokoly/rozhraní. Jiná otázka je implementace, proměnné typu protokol mají jistý overhead.

Každý, kdo dělá OOP, ví, že čtverec nemůže dědit z obdélníku, natož naopak. Zahodit kvůli jednomu chybnému užívání celou dědičnost je blbost a ty to dobře víš. Jenom trolíš.

[Kit]

Když nepoužíváš Javu a neprogramuješ objektově, tak tě to nemusí trápit.

Píšu objektově, ale ne v Javě. Tož tak.

V tom případě běžně používáš dědičnost, jen o tom možná nevíš.

Častý bývá také případ, že někdo si jen myslí, že programuje objektově, ale ve skutečnosti jen zabaluje kusy kódu do tříd.

[Reklama]

[zboj]

vícenásobná dědičnost v C++ je píčovina

To je dědičnost obecně.

P.S. Dědičnost dobře odhaluje trotly, jakmile někdo tvrdí, že obdélník má dědit ze čtverce, je jasný. Dědičnost má opodstatnění v některých speciálních případech, ale v podstatě vždy stačí protokoly/rozhraní. Jiná otázka je implementace, proměnné typu protokol mají jistý overhead.

Každý, kdo dělá OOP, ví, že čtverec nemůže dědit z obdélníku

A je to tady  Tuto debatu nehodlám opakovat, přečti si nějakou matiku pro ZŠ a pak se vrať k PHP...

[Kit]

vícenásobná dědičnost v C++ je píčovina

To je dědičnost obecně.

P.S. Dědičnost dobře odhaluje trotly, jakmile někdo tvrdí, že obdélník má dědit ze čtverce, je jasný. Dědičnost má opodstatnění v některých speciálních případech, ale v podstatě vždy stačí protokoly/rozhraní. Jiná otázka je implementace, proměnné typu protokol mají jistý overhead.

Každý, kdo dělá OOP, ví, že čtverec nemůže dědit z obdélníku

A je to tady  Tuto debatu nehodlám opakovat, přečti si nějakou matiku pro ZŠ a pak se vrať k PHP...

Aha, takže ty bys v tomto případě dědičnost použil. Nebo snad ne?

[javaman ((]

... a pak se vrať k PHP...

+1

[Ondra Satai Nekola]

vícenásobná dědičnost v C++ je píčovina

To je dědičnost obecně.

ale, ale, ale...

Na to jak je hloupý, tak v tomhle má pravdu. Dědičnos v Javě je superprasárna. Samozřejmě asi nemyslí implementace rozhraní, které jsou jediné použitelné a do dědičnosti se můžou počítat.

Az do 7 rozhrani byla problematicka soucast API, protoze blokovala moznost rozsireni v budoucnu a tak davalo velmi casto smysl vsadit na abstraktni tridy. Napriklad.

Ja bych hlavne nemotal dve veci - dedicnost byva naduzivana (ano) a dedicnost je spatna (ne)

To máš sice pravdu, ale bohužel to nijak nepomůže a radši jsem vždy dělal nekompatibilní změny. Stačí na to dobrý návrh a nebo se s klienty dohodnout. Dědičnost v Javě je fakt hnus.

To je roztomile, ale "dohodnout se s klienty" si muzes dovolit, kdyz patlas nejaky korporatni software s ostatnimi lopatami.

[javaman ((]

Prostě buď si verzi nech a nebo uděláš upgrade. Hlavně není až tak časté, že by se veřejné API mělo měnit. Pokud máš nelopatí návrh, tak víš předem, co bude potřeba. Jen patláci dělají "agilně" a vše pořád mění.

[Ondra Satai Nekola]

Prostě buď si verzi nech a nebo uděláš upgrade. Hlavně není až tak časté, že by se veřejné API mělo měnit. Pokud máš nelopatí návrh, tak víš předem, co bude potřeba. Jen patláci dělají "agilně" a vše pořád mění.

Ony jsou u API dva svety - jeden, kdy sve klienty znas (idealne je mas o kancl vedle) a pak je to ta situace, kdy nemas sanci tusit, kdo to je. Jak to vypada, kdyz jsi pak "odvazny", jsme videli trebas u pridani metod do interfacu v JDBC (problem by nenastal, byt tam abstraktni tridy nebo pokud by se to stalo v JDK 8+). Ze nevis predem, co je potreba, je pravda. V zavislosti na metodice to nevis hodne nebo trochu. Prave proto je dobre se zamyslet nad tim, jak udelat ten navrh flexibilni (coz je casto kompozici, ale neni to pravidlo).

Az se naucis programovat, tak zkus kouknout trebas do Practical API design, neni to spatne cteni, pokud uz nejsi zacatecnicka lopatka.

[javaman ((]

Mně nevadí, že neumíš programovat. Prostě abstraktní třídy jsou prasárna a třeba to jednou pochopíš. Jasný, nezapomínejme na generika, která celou dědičnost ještě vylepšují. 8 naštěstí už má i nové možnosti, ale dědičnost fakt používat nezačnu. To radši fakt jiný jazyk

Nějaké knížky o API si nech pro Kita, aby je pak dogmaticky mohl používat.

[Kit]

Prostě buď si verzi nech a nebo uděláš upgrade. Hlavně není až tak časté, že by se veřejné API mělo měnit. Pokud máš nelopatí návrh, tak víš předem, co bude potřeba. Jen patláci dělají "agilně" a vše pořád mění.

Pokud dodržuješ OCP, nemusíš se upgrade API bát.

[Ondra Satai Nekola]

Mně nevadí, že neumíš programovat. Prostě abstraktní třídy jsou prasárna a třeba to jednou pochopíš. Jasný, nezapomínejme na generika, která celou dědičnost ještě vylepšují. 8 naštěstí už má i nové možnosti, ale dědičnost fakt používat nezačnu. To radši fakt jiný jazyk

Nějaké knížky o API si nech pro Kita, aby je pak dogmaticky mohl používat.

Vypravej nam jeste chvili o svych bohate placenyh zkusenstech, lopatko...