Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: ITq 08. 09. 2015, 11:51:42
-
Zdravim,
myslim ze tato tema tu uz bola rozoberana vela vela krat. Ale neviem ju najst, a mozno sa odvtedy zmenilo par veci.
Tak podme na to :-)
TEMA: Co v IT dnes zacat, resp. o com sa da povedat ze ma najlepsiu buducnost?
Mam dve pravidla ale:
- praca z domu nutnost (je mozne robit aj remotely)
- praca je skor na "zakazky" ako na "stalu pracu"
Moje idey:
- android programator - hmm? To by slo nie?
V podstate je to urcene pre kazdeho kto sa rozhliada po niecom novom - napr ja :)
Dakujem
O
-
mainframy. ty mely budoucnost vzdy. Lenine!
-
mainframy. ty mely budoucnost vzdy. Lenine!
Dnes mainframe je mikroprocesor, když ho srovnáte se serverovnou. Výkon stejný, jen je mnohem menší :-)
-
Som pomerne silno presvedceny, ze velmi velmi slubnu buducnost ja funkcionalne programovanie.
-
Co tak focus na Security?
-
Som pomerne silno presvedceny, ze velmi velmi slubnu buducnost ja funkcionalne programovanie.
Třeba takový Haskell vznikl v roce 1990, Lisp dokonce už v 1958... a pořád nic.
-
budoucnost patří aluminiu.
-
Som pomerne silno presvedceny, ze velmi velmi slubnu buducnost ja funkcionalne programovanie.
Třeba takový Haskell vznikl v roce 1990, Lisp dokonce už v 1958... a pořád nic.
Smalltalk 1972 a teprve v devadesatkach bylo "OOP" velka vec.
Jeden z duvodu, proc ted bude FP dulezitejsi, je, ze mame hodne jader.
-
Kazdopadne bych se v dohledne dobe vyhybal pornoprumyslu, tam je ta budoucnost znacne nejista...
-
mobilni obsah
televizni aplikace
3d
-
Jeden z duvodu, proc ted bude FP dulezitejsi, je, ze mame hodne jader.
Kazdopadne bych se v dohledne dobe vyhybal pornoprumyslu, tam je ta budoucnost znacne nejista...
Pornoprůmysl bych rozhodně nepodceňoval, tam máme zase hodně ňader ;-)
Nicméně ohledně FP si myslím, že ani počet jader to nezvrátí, a přes dobrou myšlenku zůstane jako v mnoha jiných případech buď jen u okrajového využití (třeba jako Linux na desktopu), nebo skončí v propadlišti dějin (jako Betamax), nebo by muselo dojít k nějaké revoluční změně/novince, která by vyvolala "hype" (jako Linux ve formě Androidu).
-
Zdravim,
myslim ze tato tema tu uz bola rozoberana vela vela krat. Ale neviem ju najst, a mozno sa odvtedy zmenilo par veci.
Tak podme na to :-)
TEMA: Co v IT dnes zacat, resp. o com sa da povedat ze ma najlepsiu buducnost?
Mam dve pravidla ale:
- praca z domu nutnost (je mozne robit aj remotely)
- praca je skor na "zakazky" ako na "stalu pracu"
Moje idey:
- android programator - hmm? To by slo nie?
V podstate je to urcene pre kazdeho kto sa rozhliada po niecom novom - napr ja :)
Dakujem
O
Myslim, ze horizont 10 let nejsme schopni ani trochu odhadnout. Soucasne technologie budou urcite porad relevantni, ale co bude top a co bude nejvic cool to si myslim, ze je malokdo schopny trefit.
Moje osobni zkusenost:
1. cca 1995, Ze jdu studovat IT a chci byt programator? reakce lidi: A kolik myslis, ze tech pocitacu bude potreba? A to myslis, ze te to uzivi?
2. cca 2005 vsechnu praci, kterou delate budou outsourcovat do Indie, radeji delej spravce Oracle databaze
3. soucasnost No jo programator, bere hromadu prachu a skoro se nenadre ...
Dokazu si predstavit, ze IT za urcity cas nebude az tak cool, lidi a hlavne stroju, kteri zvladnou dnesni nejcastejsi praci IT specialistu bude mraky. Standardizace pokroci tak hodne, ze velka cast API a sluzeb (sw sluzby) vydrzi hodne dlouho a je mozne, ze IT bude fungovat jako automobilovy prumysl :)
Co nam zustane? Nekonecny prostor k realizaci napadu, ktere nejde zaskatulkovat a jedinym limitem bude jen a jen hardware a nase fantazie.
-
Myslím si, že je stále hodně prostoru v herním průmyslu. Budoucnost bych viděl i v herním průmyslu zaměřeném na seniory.
-
plastics
-
Kazdopadne bych se v dohledne dobe vyhybal pornoprumyslu, tam je ta budoucnost znacne nejista...
Ani jako herec?
-
Som pomerne silno presvedceny, ze velmi velmi slubnu buducnost ja funkcionalne programovanie.
Třeba takový Haskell vznikl v roce 1990, Lisp dokonce už v 1958... a pořád nic.
Ako pise Nekonala, vsetko ma svoj spravny cas. Dnes OOP naraza na svoje hranice, za ktore ist uz nevie. Nepomahaju ani navrhove vzory. Hovorim o velkych OOP molochoch, cca milion riadkov zdrojakov a viac. O uz ide iba patch na patch, workaround na workaround..
Odporucam nepremyslat nad konkretnymi jazykmi ale zacat premyslat nad platformami. Haskell a Lisp asi uz masovka nebudu nikdy ale uplne sa staci podivat na taky .NET
Vyhravaju platformy.. Iba python, perl, groovy mali stastie, ze sa presadili ako samostatne jazyky s uspesnou portaciou mimo unix..
Mimochodom, dostal som nedavno ponuku programovat funkcionale za nastupny plat prevysujuci seniora v Jave v Prahe. Je malo firiem, na ktore na to prichadzaju ale predpokladam, ze ich pocet bude casom rast.. Len sa musi vystriedat este jedna generacia programatorov. Dnesni typicky programator sa funkcionalnemu programovaniu brani vsetkymi pismenkami jeho klavesnice..
-
Ako pise Nekonala, vsetko ma svoj spravny cas. Dnes OOP naraza na svoje hranice, za ktore ist uz nevie.
Vyhravaju platformy
To jsou takové plané řeči. Před 15 lety se tvrdilo že všechno je objekt, tedy bude se programovat pouze OOP a progresivní analytici předpovídali programování pouze v Javě, kvůli tomu že Java je OOP a multiplatformní zároveň.
Dneska stejní darmožrouti pindají o zářných zítřcích funkcionálního programování a za 15 let na tomto místě budeme ze stejných úst slyšet že ani funkcionální programování nebylo to pravé a budou pindat zase o něčem jiném.
Vývoj naštěstí takhle nefunguje, většinou to dopadá tak, že ve stávajících jazycích a platformách se něco málo zakáže a něco málo přidá nového, klidně z oblasti funkcionálna.
-
Som pomerne silno presvedceny, ze velmi velmi slubnu buducnost ja funkcionalne programovanie.
Třeba takový Haskell vznikl v roce 1990, Lisp dokonce už v 1958... a pořád nic.
Ako pise Nekonala, vsetko ma svoj spravny cas. Dnes OOP naraza na svoje hranice, za ktore ist uz nevie. Nepomahaju ani navrhove vzory. Hovorim o velkych OOP molochoch, cca milion riadkov zdrojakov a viac. O uz ide iba patch na patch, workaround na workaround..
Odporucam nepremyslat nad konkretnymi jazykmi ale zacat premyslat nad platformami. Haskell a Lisp asi uz masovka nebudu nikdy ale uplne sa staci podivat na taky .NET
Vyhravaju platformy.. Iba python, perl, groovy mali stastie, ze sa presadili ako samostatne jazyky s uspesnou portaciou mimo unix..
Mimochodom, dostal som nedavno ponuku programovat funkcionale za nastupny plat prevysujuci seniora v Jave v Prahe. Je malo firiem, na ktore na to prichadzaju ale predpokladam, ze ich pocet bude casom rast.. Len sa musi vystriedat este jedna generacia programatorov. Dnesni typicky programator sa funkcionalnemu programovaniu brani vsetkymi pismenkami jeho klavesnice..
Spíše než FP bych řekl obecněji "post-OOP", protože OOP nezmizí, jen se trochu modifikuje, viz dnes Swift.
-
Spíše než FP bych řekl obecněji "post-OOP", protože OOP nezmizí, jen se trochu modifikuje, viz dnes Swift.
No rikaji tomu "multi-paradigm" ;)
-
Spíše než FP bych řekl obecněji "post-OOP", protože OOP nezmizí, jen se trochu modifikuje, viz dnes Swift.
No rikaji tomu "multi-paradigm" ;)
To jsem nemyslel. Nejde o mix, ale koherentní paradigma.
-
Dnes OOP naraza na svoje hranice, za ktore ist uz nevie. Nepomahaju ani navrhove vzory. Hovorim o velkych OOP molochoch, cca milion riadkov zdrojakov a viac. O uz ide iba patch na patch, workaround na workaround..
Odporucam nepremyslat nad konkretnymi jazykmi ale zacat premyslat nad platformami.
Ano, problém opravdu není v konkrétním jazyce, ale není ovšem ani v OOP. Problém je v tom, kdo ten kód píše.
-
Ano, problém opravdu není v konkrétním jazyce, ale není ovšem ani v OOP. Problém je v tom, kdo ten kód píše.
Souhlas. Aplikace jsou plné rádoby OOP, ale při bližším pohledu je to jen obyčejný imperativ. A ten naráží na své hranice. OOP ty hranice nemá.
-
Ano, problém opravdu není v konkrétním jazyce, ale není ovšem ani v OOP. Problém je v tom, kdo ten kód píše.
Souhlas. Aplikace jsou plné rádoby OOP, ale při bližším pohledu je to jen obyčejný imperativ. A ten naráží na své hranice. OOP ty hranice nemá.
A co je to přesně to OOP? Abysme věděli o čem se vlastně diskutuje
-
Ano, problém opravdu není v konkrétním jazyce, ale není ovšem ani v OOP. Problém je v tom, kdo ten kód píše.
Souhlas. Aplikace jsou plné rádoby OOP, ale při bližším pohledu je to jen obyčejný imperativ. A ten naráží na své hranice. OOP ty hranice nemá.
A co je to přesně to OOP? Abysme věděli o čem se vlastně diskutuje
To je zajímavá otázka.
A je zvláštní, že se tu tomu doposud nikdo nevěnoval ...
-
A co je to přesně to OOP? Abysme věděli o čem se vlastně diskutuje
Xerox OOP je asynchronní zasílání zpráv procesům.
C++/C#/Java OOP je sada členských proměnných a metod.
Dnes je cool navážet se C++/C#/Java OOP s tím že nepodporuje asynchronní zasílání zpráv, je to něco jako náboženství.
-
Vývoj naštěstí takhle nefunguje, většinou to dopadá tak, že ve stávajících jazycích a platformách se něco málo zakáže a něco málo přidá nového, klidně z oblasti funkcionálna.
To už se děje. Imutabilita, bezstavové komponenty, skládání, to všechno se v mainstreamových jazycích objevuje. Včetně věcí, které z FP přímo vycházejí (nejčastěji se uvádí LINQ). V Microsoft Research se motají velcí experti na FP.
Asi se nedá moc předpokládat, že z Haskellu apod. bude někdy mainstream, ale určitě bude čímdál populárnější a bude silně ovlivňovat ostatní jazyky.
-
A co je to přesně to OOP? Abysme věděli o čem se vlastně diskutuje
OOP je celé o "dependency managment", pomáha oddeliť oddeliť nízkoúrovňovú logiku aplikácie od tej vyššej úrovne ako je interakcia s užívateľom, umožňuje navrhovať systémy tak, aby boli ľahko rozšíriteľné. OO ponúka aj vysokú úroveň abstrakcie. Podľa môjho názoru, toto sú hlavné dôvody prečo je OOP v takej miere rozšírené a ešte veľmi dlho bude. Samozrejme sú tu aj iné prístupy ako napríklad FP, ale to je vhodné k iným účelom. Do istej miery sa dajú OO programy písať aj v jazykoch, ktoré OO nepodporujú, ako je napríklad C
-
Xerox OOP je asynchronní zasílání zpráv procesům.
Ne. Nic jsi nepochopil.
-
OOP je celé o "dependency managment", pomáha oddeliť oddeliť nízkoúrovňovú logiku aplikácie od tej vyššej úrovne ako je interakcia s užívateľom, umožňuje navrhovať systémy tak, aby boli ľahko rozšíriteľné. OO ponúka aj vysokú úroveň abstrakcie.
Hlavní smysl OOP v mainstream jazycích je ušetření práce a zvýšení přehlednosti. Nic víc za tím nehledej, není to tam.
Xerox OOP je asynchronní zasílání zpráv procesům.
Ne. Nic jsi nepochopil.
Nikdo mi to líp nevysvětlil, je to tedy na tobě.
-
OOP je celé o "dependency managment", pomáha oddeliť oddeliť nízkoúrovňovú logiku aplikácie od tej vyššej úrovne ako je interakcia s užívateľom, umožňuje navrhovať systémy tak, aby boli ľahko rozšíriteľné. OO ponúka aj vysokú úroveň abstrakcie.
Hlavní smysl OOP v mainstream jazycích je ušetření práce a zvýšení přehlednosti. Nic víc za tím nehledej, není to tam.
To je možná spíše jen hlavní způsob využití OOP většinou programátorů.
-
Hlavní smysl OOP v mainstream jazycích je ušetření práce a zvýšení přehlednosti. Nic víc za tím nehledej, není to tam.
To je možná spíše jen hlavní způsob využití OOP většinou programátorů.
Těžko se užívá něco co tam není :)
-
OOP je celé o "dependency managment", pomáha oddeliť oddeliť nízkoúrovňovú logiku aplikácie od tej vyššej úrovne ako je interakcia s užívateľom, umožňuje navrhovať systémy tak, aby boli ľahko rozšíriteľné. OO ponúka aj vysokú úroveň abstrakcie.
Tohle ale neříká nic o tom, co je a není OOP. Spíš to je hodně vágní popis dobrého návrhu a to bez ohledu na použité paradigma :)
-
Hlavní smysl OOP v mainstream jazycích je ušetření práce a zvýšení přehlednosti. Nic víc za tím nehledej, není to tam.
To je možná spíše jen hlavní způsob využití OOP většinou programátorů.
Těžko se užívá něco co tam není :)
Bylo by to tam, kdyby programátoři psali objektově. Obvykle je to jen obyčejné strukturované programování zabalené do objektů.
-
OOP je celé o "dependency managment", pomáha oddeliť oddeliť nízkoúrovňovú logiku aplikácie od tej vyššej úrovne ako je interakcia s užívateľom, umožňuje navrhovať systémy tak, aby boli ľahko rozšíriteľné. OO ponúka aj vysokú úroveň abstrakcie.
Hlavní smysl OOP v mainstream jazycích je ušetření práce a zvýšení přehlednosti. Nic víc za tím nehledej, není to tam.
A jakým způsobem se té přehlednosti podle tebe dosáhlo? Třeba vylepšeným editorem kódu, rozčleněním kódu do odstavců, dokumentačními komentáři nebo čím?
A co je to přesně to OOP? Abysme věděli o čem se vlastně diskutuje
S jistotou to neví nikdo. Ani ti největší odborníci v oboru se nejsou schopni dohodnout co to vlastně znamená. V knize Základy objektově orientovaného návrhu v UML autor popisuje tuto historku:
Když jsem poprvé vstoupil do království OOP, rozhodl jsem se vytvořit definici OOP jednou pro vždy. Sehnal jsem tucet chlapíků z OOP světa a zamkl je v pokoji bez jídla a vody. Řekl jim, že je pustím až poté, co se dohodnou na definici, kterou bych mohl předat žádostivě čekajícímu publiku.
Po hodině křiku a rachotu v pokoji následovalo ticho. Protože jsem se bál nejhoršího, opatrně odmkle dveře a nahlédl na potenciálně krvavou scénu. Všichni guru byli naživu, seděli však samostatně a nikdo s nikým nemluvil.
Zřejmě každý začal sezení tím, že se snažil ustanovit definici OOP pomocí časem dobře prověřené vědecké praxe hlasitého a neustálého opakování svého tvrzení. Když tento postup nikam nevedl, všici souhlasili s vytvořením seznamu vlastností OOP prostředí a 6-10 bodech, které sami jednotlivě považovali za nezbytné.
Měli 2 volby, vytvořit jeden dlouhý seznam, který byl souhrnem všech jednotlivých seznamů, nebo vytvořit krátký seznam, který by byl průsečíkem jejich jednotlivých seznamů.
Zvolili druhou možnost a výsledkem byl krátký seznam vlastností, které se nacházely na všech jednotlivých seznamech.
Ten seznam byl opravdu krátký. Obsahoval jedno slovo - "zapouzdření".
Problém spočívá v tom, že termín OOP postrádá smysl, takže jeho definice je libovolná. Přesto se vrhám do propasti a nabízím svůj seznam vlastností, které tvoří základ OOP.
Zapouzdření - sseskupení souvisejících idejí do jedné jednotky, na kterou se lze odkazovat názvem. Takovým zapouzdřením může být i obyčejný podprogram.
Objektově orientované zapouzdření - zabalení operací a atributů představující nějaký stav do jednoho typu objektu. Daný stav je přístupný či upravitelný pouze skrze rozhraní.
Skrývání informací a implementace - omezení externí viditelnosti určitých informací nebo implementačních detailů, která jsou pro strukturu zapouzdření interní. Jinými slovy, nikomu nic není do toho jak dělám to co dělám, v krajním případě ani do toho co dělám. Něco jako černá skříňka se vstupy a výstupy.
Z další vlastností to mohou být:
zachování stavu, identita objektů, zprávy, třídy, dědičnost, mnohotvarost, obecnost.
-
S jistotou to neví nikdo. Ani ti největší odborníci v oboru se nejsou schopni dohodnout co to vlastně znamená.
S každým oborem lidské činnosti, který se přehnaně, neplodně a zcela zbytečně zabývá sám sebou, není něco v pořádku.
-
Problém spočívá v tom, že termín OOP postrádá smysl, takže jeho definice je libovolná. Přesto se vrhám do propasti a nabízím svůj seznam vlastností, které tvoří základ OOP.
Zapouzdření - sseskupení souvisejících idejí do jedné jednotky, na kterou se lze odkazovat názvem. Takovým zapouzdřením může být i obyčejný podprogram.
Objektově orientované zapouzdření - zabalení operací a atributů představující nějaký stav do jednoho typu objektu. Daný stav je přístupný či upravitelný pouze skrze rozhraní.
Skrývání informací a implementace - omezení externí viditelnosti určitých informací nebo implementačních detailů, která jsou pro strukturu zapouzdření interní. Jinými slovy, nikomu nic není do toho jak dělám to co dělám, v krajním případě ani do toho co dělám. Něco jako černá skříňka se vstupy a výstupy.
Z další vlastností to mohou být:
zachování stavu, identita objektů, zprávy, třídy, dědičnost, mnohotvarost, obecnost.
Pro nás, co se v této oblasti pohybujeme už trochu déle ale tyhle vlastnosti nejsou ničím speciální, pokud zaměníme slovo objekt za modul tak tohle plně podporovala už třeba Modula-2 před 30 lety, která objekty v dnešním slova smyslu vůbec neměla. V podstatě je to popis modulárního programování...
-
Problém spočívá v tom, že termín OOP postrádá smysl, takže jeho definice je libovolná. Přesto se vrhám do propasti a nabízím svůj seznam vlastností, které tvoří základ OOP.
Zapouzdření - sseskupení souvisejících idejí do jedné jednotky, na kterou se lze odkazovat názvem. Takovým zapouzdřením může být i obyčejný podprogram.
Objektově orientované zapouzdření - zabalení operací a atributů představující nějaký stav do jednoho typu objektu. Daný stav je přístupný či upravitelný pouze skrze rozhraní.
Skrývání informací a implementace - omezení externí viditelnosti určitých informací nebo implementačních detailů, která jsou pro strukturu zapouzdření interní. Jinými slovy, nikomu nic není do toho jak dělám to co dělám, v krajním případě ani do toho co dělám. Něco jako černá skříňka se vstupy a výstupy.
Z další vlastností to mohou být:
zachování stavu, identita objektů, zprávy, třídy, dědičnost, mnohotvarost, obecnost.
Pro nás, co se v této oblasti pohybujeme už trochu déle ale tyhle vlastnosti nejsou ničím speciální, pokud zaměníme slovo objekt za modul tak tohle plně podporovala už třeba Modula-2 před 30 lety, která objekty v dnešním slova smyslu vůbec neměla. V podstatě je to popis modulárního programování...
On hlavne v tom seznamu chybi polymorfismus.
A ze neco Modula umela je prima, ale dalsi otazka je jak to umela. V tomhle ohledu je prima mit zelene fajfky v checklistu vlastnosti, ale nakonec pri prgani hraji roli i detaily provedeni...
-
..
Obcas ctu forum na root.cz a myslim, ze velkou budoucnost ma psychologie, pripadne psychiatrie zamerena na pracovniky v IT.
-
Zapouzdření - sseskupení souvisejících idejí do jedné jednotky, na kterou se lze odkazovat názvem. Takovým zapouzdřením může být i obyčejný podprogram.
Objektově orientované zapouzdření - zabalení operací a atributů představující nějaký stav do jednoho typu objektu. Daný stav je přístupný či upravitelný pouze skrze rozhraní.
Skrývání informací a implementace - omezení externí viditelnosti určitých informací nebo implementačních detailů, která jsou pro strukturu zapouzdření interní. Jinými slovy, nikomu nic není do toho jak dělám to co dělám, v krajním případě ani do toho co dělám. Něco jako černá skříňka se vstupy a výstupy.
Z další vlastností to mohou být:
zachování stavu, identita objektů, zprávy, třídy, dědičnost, mnohotvarost, obecnost.
Hmm jenže to například znamená, že tuto kategorii splňují FP jazyky a naopak takový Python ne :-)
-
Zapouzdření - sseskupení souvisejících idejí do jedné jednotky, na kterou se lze odkazovat názvem. Takovým zapouzdřením může být i obyčejný podprogram.
Objektově orientované zapouzdření - zabalení operací a atributů představující nějaký stav do jednoho typu objektu. Daný stav je přístupný či upravitelný pouze skrze rozhraní.
Skrývání informací a implementace - omezení externí viditelnosti určitých informací nebo implementačních detailů, která jsou pro strukturu zapouzdření interní. Jinými slovy, nikomu nic není do toho jak dělám to co dělám, v krajním případě ani do toho co dělám. Něco jako černá skříňka se vstupy a výstupy.
Z další vlastností to mohou být:
zachování stavu, identita objektů, zprávy, třídy, dědičnost, mnohotvarost, obecnost.
Hmm jenže to například znamená, že tuto kategorii splňují FP jazyky a naopak takový Python ne :-)
Často mám pocit, že většina programátorů nezná význam slova "zapouzdření" a pod záminkou zapouzdřování narvou do třídy hromady nesmyslných getterů a setterů. A přitom systematicky nabourávají zapouzdření, protože tím odhalují její vnitřní strukturu do rozhraní - ať pravou či falešnou.
-
On hlavne v tom seznamu chybi polymorfismus.
To jsem myslel, že je právě ta mnohotvarost, esli to teda dobře chápu.
Často mám pocit, že většina programátorů nezná význam slova "zapouzdření" a pod záminkou zapouzdřování narvou do třídy hromady nesmyslných getterů a setterů. A přitom systematicky nabourávají zapouzdření, protože tím odhalují její vnitřní strukturu do rozhraní - ať pravou či falešnou.
Já bych řekl, že největším narušitelem zapouzdření a skrývání implementace je dědičnost. Ale jinak máš asi taky pravdu. Dycky to bude o nějakém kompromisu.
-
Často mám pocit, že většina programátorů nezná význam slova "zapouzdření" a pod záminkou zapouzdřování narvou do třídy hromady nesmyslných getterů a setterů. A přitom systematicky nabourávají zapouzdření, protože tím odhalují její vnitřní strukturu do rozhraní - ať pravou či falešnou.
Já bych řekl, že největším narušitelem zapouzdření a skrývání implementace je dědičnost. Ale jinak máš asi taky pravdu. Dycky to bude o nějakém kompromisu.
Ona i ta dědičnost se dá uchopit správně. Všechny atributy si držím private (a zásadně k nim nepíši gettery ani settery). Skoro jsem zapomněl, že nějaký protected existuje - do něj se vejde hromada porušení zapouzdření.
-
Linux admin se jiste free uzivi, ale neni to prace uplne naporad a pro kazdeho. Prece jen je treba zastupitelnost a pro vetsi firmy je one-man-show problem. Ono casem i proto toho admina je dobre, pokud ma zastup a muzu v klidu odjet na dovolenou ci mit vecer "hotovo" ;)
No a kdyz uz se otom pise tak pokud by nekdo z diskutujicich o takovem prerodu uvazoval - tedy z free byt zamestnanec, ale dale resit zajimave projekty v Linuxu a pocitacovych sitich, akorat hledame nove kolegy na pozice Linux Administrator a nove i sitovy specialista, takze se muzete na prace@adminit.cz ozvat a zkusit to i z druhe strany a treba byt i rootem na Rootu ...
-
Všechny atributy si držím private (a zásadně k nim nepíši gettery ani settery).
Ako ich potom inicializujes? Napada ma ze jedine cez konstruktor ale rovno pri deklaracii. Ked pri deklaracii tak potom to nie je vlastne konstanta? Ked cez konstruktor, ak dedis z tej triedy, musis v zdedenej triede volat jej nadtriedu kam musis opat prepasirovat tie agrumenty.
S gettrami nemam problem, settre by mali mat co najmensiu viditelnost z vonka a gettre by mali vratit unmodifiable veci
-
kit o getteroch klasicky trepe, uz pol roka nedal ziadny konkretny priklad
(http://i.imgur.com/d0DasZq.png)
-
kit o getteroch klasicky trepe, uz pol roka nedal ziadny konkretny priklad
(http://i.imgur.com/d0DasZq.png)
Ten "trepe" o všem.