--

29.3.2008 00:45 | Londonix | poslední úprava: 3.11.2020 22:05

--        

Komentáře

[🇵🇸]

A co věta "Ich verstehe immer nur Bahnhof.", ta je naprosto klíčová, ne?

Jinak blahopřeju.

[ABCLinuxuIsAlive]

no nedokazu si predstavit, co to znamena (babelfish taky nic srozumitelneho)

[🇵🇸]

Znamená to: "Nerozumím."

[ABCLinuxuIsAlive]

tak takhle jsem na tom s tou svoji nemcinou

[melkors]

Co Nemci spolehlive postavi zbytek vlasu, je veta "Ich stehe nicht ver"

[depka]

jaký že je rozdíl mezi abstraktní třídou a interface? a za jakych podminek?

[Bluebear]

a za jakych podminek?

To je právě správná otázka - obávám se, že to dost závisí na jazyku. V C++ není ten rozdíl vůbec žádný, protože tam interface z hlediska syntaxe neexistuje a místo interface se používá abstraktní třída.

Popravdě řečeno, kdyby mi někdo při pohovoru položil takovouto otázku, v mých očích by dost klesl, protože to je otázka hnidopišská, která se týká jenom abstraktní terminologie a o znalostech programování nevypovídá vůbec nic.

abstraktní třída je obyčejná třída, která jenom nemá definované některé metody; předpokládá se, že nějaká jiná třída z ní bude dědit a tyto metody si doplní podle potřeby.

interface je seznam metod, které by měla nějaká třída podporovat, aby plnila nějaký účel. Jestliže se třída hlásí k tomu, že podporuje daný interface, musí definovat všechny metody, které předepisuje interface.

Z čistě formálního hlediska jsou to skutečně dvě zcela různé věci, ale v praxi jsou na jedno brdo.

[Filip Jirsák]

Vzhledem k tomu, že jde o J2EE, dá se předpokládat, že jde o rozdíl mezi abstraktní třídou a interfacem v Javě. A tam to není na jedno brdo, ale jsou to dvě naprosto odlišné věci. Abstraktní třída je předek v hierarchii tříd, který implementuje nějakou funkcionalitu společnou potomkům, ale sám nereprezentuje žádný reálný objekt – takže zpravidla některou funkcionalitu nemá vůbec implementovánu. Naproti tomu interface je kontrakt, smlouva, že třída implementující tento interface splňuje určité vlastnosti (takže interface nemusí mít ani žádnou metodu, pak je to jen „značkovací“ interface kterým programátor říká „ano, dohlédl jsem na to a moje třída se chová, jak je příslušným kontraktem požadováno“).

[Jary]

A to nejdůležitější asi je, že Interfacem se v javě dělá něco, co by se s přimhouřením oka snad dalo nazvat vícenásobná dědičnost.

[Filip Jirsák]

Neřekl bych, že je to to nejdůležitější. Vícenásobná dědičnost bývá často označována za záminku pro vznik interfaců, ale v Javě je interface dotažen dál, a s tím, co bylo možná na počátku (vícenásobná dědičnost), už nemá mnoho společného. Dnes se interface v Javě používá většinou právě jako kontrakt (do značné míry hlídaný překladačem).

[Daniel Kvasnička ml.]

Nejdulezitejsi funkci interfacu je IMHO odstraneni zavislosti na konkretni implementaci a tim padem maximalni flexibilita pro zmeny. Krasne je to videt napr. na JPA ci JAXP. Kdyz napisete napr. kod pro XSLT transformace v Jave proti rozhranim, staci vam pak pri zmene enginu zmenit jedinou factory.

[ABCLinuxuIsAlive]

Popravdě řečeno, kdyby mi někdo při pohovoru položil takovouto otázku, v mých očích by dost klesl, protože to je otázka hnidopišská, která se týká jenom abstraktní terminologie a o znalostech programování nevypovídá vůbec nic.

Minimalne podle odpovedi na tuhle otazku poznas, jestli pred tebou nahodou nesedi uplny lamoid (nerikam, ze by zrovna tohle musel vedet kazdy, ale kdyz uz se pohovor tyka J2EE ..)

Z čistě formálního hlediska jsou to skutečně dvě zcela různé věci, ale v praxi jsou na jedno brdo.

No jeste ze jsem neodpovedel takhle :)

[I love M$]

protože to je otázka hnidopišská , dokonce mi to prijde posledni dobou, co tak slycham, skoro takovy modni trend ptat se u pohovoru na tuhle otazku. Je asi dost popularni, az bych rekl proflakla. Souhlasim, ze vypovidaci hodnota je minimalni. Nekdo ma treba osvojene velice dobre ruzne programovaci techniky, ruzne konstrukce pro optimalizaci, ma naprosto perfektni binarni predstavu co se deje tehdy a onehdy, ale treba mu dela problemy mnohdy navrhnout jak to ma vlastne vypadat a jak se to bude "user friendly" ovladat a pak na schuzi rekne s davkou opovrzeni nad hloupym uzivatelem: "Dyt' to je prece jasny jak se ma ta operace udelat, normalne pres petihmat CTRL+&+INSERT+F1+F12 a pak kliknes mysi na tu ikonku, ktera tam este neni, ale dodelam ji, a pak dvakrat ENTER a je to". Nekdo ma osvojene rekneme "stredne pokrocile" techniky, se kterymi si vzdy tak nejak vystacil, a klade duraz na to aby to vypadalo, fungovalo a dalo se to nejak pouzivat a to ze to neni plne optimalizovany nakonec zakaznika stejne nezajima, kdyz to funguje jak ma a vyhovuje mu to. Pamatuju se, ze sem po jedne kolegyni z prace nasel kus kodu neco jako:

...bool b1;
...CallFunc(bool);

if (b1)
{
CallFunc(b1 == true);
}
else
{
CallFunc(b1 == false);
}

Nakonec nic vylozene spatne, aby to spravne fungovalo, na tom neni, jen kazdy citi, ze by to asi trochu zestrucnil. Pravda, ze kazdy se treba obcas nekde zapomene a pak se chyta za hlavu, "co sem to tady napsal za bejkarnu" . Sice ta kolegyne obcas napsala nejakou trochu vetsi bejkarnu, ale v navrhu vzhledu a ovladani aplikace se na to dycky dokazala podivat okem uzivatele z nas vsech tak nejak nejlip. Tezko potom rict, jestli je pro danou firmu lepsi najmout toho nebo toho. Na tuhle hnidopišskou otazku by treba odpovedet neumela, ale je to presne ten pripad, jak pisete, kdy skutecne schopnosti zustavaji skryty.

Jinak k tomu C++ bych odpovedel nejspis (pokud se mnou souhlasite), ze rozdil spociva spise v nepsanem pravidle, ze u interface (== struct) se predpoklada pouze pritomnost abstraktnich a ne jinych funkci a zrovna tak ze neobsahuje zadne datove polozky (kromne vftab_ptr ) , pokud tomuto neodpovida, v terminologii se z nej zpravidla stava obstraktni trida, ale je to pravda jen slovickareni, v praxi je to k nicemu.

[disorder]

v C by to vzdy zavolalo CallFunc(true), je to tak spravne?

[I love M$]

Ano, spravne, v tom kodu se to melo volat vzdycky s true, proto ten program fungoval, nikdo si nestezoval a tudiz to misto nikdo nezkoumal, ale kdyz jsme to jednou takle profilovali, tak sme na to narazili. Samozrejme, pokud by se to melo volat obcas i s false, potom ten kod je sematicky spatne.

[Bluebear]

Nekdo ma treba osvojene velice dobre ruzne programovaci techniky, ruzne konstrukce pro optimalizaci, ma naprosto perfektni binarni predstavu co se deje tehdy a onehdy, ale treba mu dela problemy mnohdy navrhnout jak to ma vlastne vypadat a jak se to bude "user friendly" ovladat

To je pravda, a právě takoví programátoři by se měli nechat hákovat kernel nebo jiné low-level záležitosti (což je stejně to, co chtějí dělat) a nepustit je k ničemu, co uživatel vidí. Na programování uživatelského rozhraní pak vezmeš někoho, kdo třeba není takový guru, ale dokáže myslet jako uživatel, a všichni budou spokojeni.

[Käyttäjä 11133]

To je pravda, a právě takoví programátoři by se měli nechat hákovat kernel

Nejlepší je takový GURU, který si myslí, že komentáře jsou jen plýtváním místa na disku a jeho času. To je pak radost se do jádra podívat proč mi ten driver hapruje Ale co... Už jsem si zvykl...

[Bluebear]

Nejlepší je takový GURU, který si myslí, že komentáře jsou jen plýtváním místa na disku a jeho času.

Tento názor se bohužel u guru programátorů občas objeví; někteří jsou opravdu tak dobří, že význam kódu vidí letmým pohledem, takže oni sami žádné komentáře nepotřebují, a zároveň mají poruchu osobnosti, takže se nedokáží vžít do role obyčejného smrtelníka, který je občas nucen to taky číst.

Na druhé straně, je lepší kód bez komentářů než kód s komentáři, které lžou.

Největší odvaz je, když na začátku programátor ty komentáře udělá, pak ten kód nějakých pár let žije vlastním životem, leckdo do něj přidá nějakou funkčnost, něco změní, opraví bugy, ale neobtěžuje se změnit ty komentáře. Pak k tomu přijde nějaký důvěřivý nešťastník, přečte si ty komentáře a protože vypadají velmi důvěryhodně, řídí se podle nich, a to je jeho konec.

[Bluebear]

Aha, musím se opravit, existuje ještě vyšší level průseru s komentáři. To když se někdo pokusí vyrobit dokumentaci podle kódu se lživými komentáři (protože u low-level věcí obvykle žádný jiný zdroj informací než samotný kód neexistuje). Chudák dokumentátor čte ty komentáře a píše dokumentaci podle nich; ti nejpečlivější si zkusí pár jednoduchých testů, aby si ověřili, že to píší dobře - ty testy samozřejmě budou fungovat, protože testují ty nejprimitivnější funkce a ty se většinou nezmění ani po letech. Tím obdržíme podrobnou, technicky detailní a velmi důvěryhodnou dokumentaci, která je úplně blbě.

[Käyttäjä 11133]

Jo.. Lživé komentáře jsou taky lahůdka

[Leoš Literák]

hezky, at to vyjde

[ABCLinuxuIsAlive]

Dik

[deda.jabko]

drzim palce... nicmene by me zajimalo, co cloveka tak primeje k tomu, aby to tu zapichl a jel makat nekam do zahranici.

[Daniel Kvasnička ml.]

Prachy?

[h.xman]

Nejen prachy, ale i řada praktických důvodů, jakože například jsou země kde věci jaksi líp fungujou než v ČR... ale stejně nejlepší důvod jsou prostě toulavé boty. To jste nikdy neměl? Tu intenzivní touhu po změně, po jiném světě, takový ten krásný pocit až se vám svírá břicho? Nejlepší chvíle v životě jsem zažil, když jsem byl najednou v cizí zemi, nic jsem neměl a všechny možnosti byly otevřené, nikdo mě neznal a najednou úlevně povolil ten drtivý tlak očekávání okolí, který jsem si přitom předtím vůbec neuvědomoval natož abych vnímal jak mě svazuje... prostě ten intenzivní pocit svobody a nového začátku, skoro jako znovuzrození... kdy všechno je nové a člověk najednou všechno tak intenzivně vnímá... to se ani nedá popsat, to se musí zažít.

Mimochodem, pro autora původního blogpostu - prima, moc pěkný. Gratuluju, držím pěsti a těším se na pokračování.

[ABCLinuxuIsAlive]

Presne tak, prachy jsou mily fakt tohodle presunu, ale jde mi hlavne o to, pohybovat se ve "funkcnejsim" prostredi (jestli to neni jen moje iluze bych mel pomerne brzo zjistit). Krome toho jsem to bral, jako sveho druhu vyzvu, objevit se v cizi zemi, s jednim kufrem (jeste sem potrebuju dostat vsechny svoje tucnaky), notebookem a nejakym pocket money

Dik :)

[Jary]

Taky jsem to zkusil a skončil jsem u umyvání nádobí. Ještě nemám titul, a práce nebyla sjednána dopředu, tak možná proto. Ale zkušenost dobrá a i ty peníze za nádobí jsou dobré. Zatím dobré.

[ABCLinuxuIsAlive]

nj. titul se celkem hodi .. sjednat praci dopredu je taky rozumne, ale jak jsem zjistil (necham to na pristim ublognuti), neni to uplne nejdulezitejsi :)

[David Ježek]

že by se navracely doby příjemných trained.monkeyho blogů z irska? držím palec!

[Aleš Kapica]

Krom obligátního, "Jaký je rozdíl mezi abstraktní třídou a interface?" si se mnou popovídal o spoustě prvků J2EE, mockování a JUnit testech ... problém jsem měl jenom, když mi stres nedovolil odpovědět na otázku, týkající se rozdílu mezi java.util.List a Set z téže package. Selhání u takto triviální otázky pro mě znamenalo jasnou překážku při potenciálním vstupu do řad zaměstnanců BMC.

Ano, stres je pěkné svinstvo. U každého vrcholí v jiný okamžik. U někoho před akcí u jiného po a u někoho - tak jako u mne - přesně v onen kritický okamžik kdy by se měl vzepnout k vrcholnému výkonu. Pro mne to byl primární důvod proč jsem ukončil svá vysokoškolská studia. Zatímco na FSS MUNI byla většina zkoušek prováděna formou písemných testů, na FF MUNI se zkoušelo klasicky formou pohovoru. Žádný teror, ale míra stresu prostě gradovala ve chvíli kdy jsem byl pozván dovnitř. V takovou chvíli mě vždy ovládne jediné přání - být někde úplně jinde.

Testování u pohovoru navíc nemá vůbec nic společného s reálnou prací, protože psát nějaké skripty či příkazy z hlavy vypovídá jen o paměťových schopnostech. Jenže člověk, který má zkušenosti s více distribucemi a verzemi nejen software, ale i OS ví, že syntaxe nemusí být vždy stejná, že stejnou věc lze dělat více způsoby a že před závažnější akcí je vždy lepší pro jistotu prubnout atribut help a prolézt trochu dokumentaci. Rutinně zvládá většinou to s čím zrovna dnes a denně dělá. Vývoj a změny v oblasti IT mají totiž takové tempo, že pokud by měl nosit v hlavě všechno nač se ho kdy kdo může zeptat, tak by měl hlavu jak balón. Bohužel to však na přesvědčivosti u pohovoru nepřidá.

Dobrý zaměstnanec většinu věcí dělá jen jednou za čas, protože to častěji není třeba, všechno mu funguje. V praxi je mnohem důležitější schopnost rychle se učit, přizpůsobit se možnostem a využít vzniklé situace pro maximálně optimální řešení.

[diverman]

Osobne preferuji radeji pohovor s clovekem z branze a vykonani testu na papire, nez s "personalistou", ktery se sice specializuje na IT profese, avsak vubec netusi, o cem je rec.

[xxx]

Ja si myslim, ze psani skriptu/prikazu z hlavy nejaky smysl ma. Podle me totiz ukaze jak moc opravdu clovek s nejakou veci pracuje. Navic muze pomerne dobre oddelit lepice kodu od tech kdo ho opravdu pisi.

[Roman Schulz]

Gratuluji k práci a doufám že budeš posílat nějaké informace jak se ti tam daří..

[arf]

Taky se pripojuju ke gratulaci.. kdy se chystas prijet domu? :)