Diskuze: Výhody objektů
Snorlax:14.8.2013 18:15
ok to cos mi řekl mi dalo stejně jako to motto pod komentářem 
. Pokud jsem to tedy dobře
pochopil, tak se to pak lépe edituje, když to chci na novou věc?
Luboš Běhounek Satik:14.8.2013 18:33
Výhoda objektů je přehlednost.
Třídy ti pomáhají členit celý problém do menších logických celků.
Projekt s 100 třídami, kde každá má 10 metod se udržuje lépe než
projekt, kde máš jen 1000 metod za sebou.
Nevýhoda OOP je ta, že to má nějakou režii, takže je to mírně pomalejší.
Ale to je i funkcionální programování oproti pouhému seznamu instrukcí,
protože musíš ukládat před voláním funkce stavy registrů, pushovat na
zásobník parametry funkcí (místo toho, abys na ně šahal přímo) apod.
OK takže tu máme 2 programy co dělaj naprosto tu samou věc ale jeden je
přes fce a druhý přes OOP. teď mi tedy dejte příklad, kdy budu funkce
proklínat a OOP uctívat. věřím že přeci nějaký rozdíl tam MUSÍ být
Snorlax:14.8.2013 18:51
tak podle mě se dá všechno napsat jak přehledně i nepřehledně. v tom
teda výhodu necítím. možná ta univerzálnost jak tady se zmiňovala. ale
upřímě nevím, co si mám pod tím přímo představit
Neaktivní uživatel:14.8.2013 18:56
Ano, psal jsem, že vše se dá napsat procedurálně i objektově.
Nezaručuju, že budeš OOP uctívat, ale zkusím to.
Vezmu si třeba tento řádek:
$sql = Database::oneResult("SELECT ... WHERE `NICK`=? and `PASS`=?", array($nick, $password);Zapomněl jsi na ošetření proměnných. PDO ti to udělá automaticky. Asi
jsi si všiml i větší přehlednosti jakožto "knihovny". Všechny třídy se
také dají použít později v jiných projektech. Můžeš použít třídy
jiných a snadno je zakompentovat do své aplikace, to by asi v procedurálce
nešlo. Máš tu také už
zmíněnou snadnou údržbu a rozšiřování do budoucna. Můžeš si napsat
třídu na tvorbu miniatur obrázku s obrovským množstvím možností a zbytek
aplikace ani nemusí vědět, co se vlastně děje. Nemusíš znovuvytvářet
kolo, prostě použiješ to, co už existuje.
Chce si to pořádně ohmatat, pak by jsi si našel svoje vlastní výmluvy
proč používat OOP a nutil je ostatním.
Snorlax:14.8.2013 19:02
. Já to stejně
vyzkouším ale vždy je boj když se zkouší něco nového že?... tak až
budu vymýšlet nějakou věc, zkusím to udělat pře OOP. starý zdroje
rozhodně přepisovat nebudu
Snorlax:14.8.2013 19:15
Pánové, pánové, přestaňte se hádat, dokud vám nebudu rozumět a
hádat se s váma .
Snorlax:14.8.2013 19:18
ok tak jsem si to v rychlosti proletěl a zjistil jsem jaký jsou výhody,
ovšem mám pocit že stále se to dá nahradit funkcí (doufám že nevyhraju
nějakýho machra, jelikož jakmile by jste se dozvěděli adresu tak by jste
mě asi ukamenovali ). snad
někdy OOP přijdu na chuť. chce to jen čas a zkušenosti. až to nastane tak
vám napíšu
Snorlax:14.8.2013 19:21
vždyť to řikám že mě ukamenujete . prostě to snad časem
pochopím. je to stejný jako když jsem se učil v PHP pracovat se
soubory...
Neaktivní uživatel:14.8.2013 19:23
Akimi bude teďka terčem Kitových kamenů, a pak se nemůžeme divit že ty
kostkový chodníky v Hradci nikdy hotový nebudou
Neaktivní uživatel:14.8.2013 20:13
Já jenom celou dobu přemejšlel, proč by sakra grafik měl lízt do
jakýhokoliv kódu, zmát jsi mě
Neaktivní uživatel:14.8.2013 20:30
K tomu přístupu k databázi - bezpečnost. Není nijak extra bezpečné,
když můžeš přistupovat do databáze odkudkoliv a dělat s ní cokoliv
Neaktivní uživatel:14.8.2013 20:32
Stačí to mít ošetřený. No nic, já už jsem z unavený z pořád té
samé konverzace...
Neaktivní uživatel:14.8.2013 20:35
Bral jsem to spíše jako ukázku, ale budiž. Však od toho jsou modely, který
jsem sem teď nechtěl přidávat, akorát by to zesložitilo to, co jsem chtěl
vysvětlit.
Neaktivní uživatel:14.8.2013 20:59
Tak tak. Docela se těším na PHP6. Jsem zvědavý na goto, i když zatím
nevím, nevím, přide mi to divný v PHP goto.
Neaktivní uživatel:14.8.2013 21:09
Neříkám, že to není riziko. Je to ale riziko zevnitř, které se při použití statických tříd musí podstoupit. Není to ale vhodné použití u citlivých dat, zvlášť, když na tom pracuje více programátorů.
(Ještě jen tak mimochodem: Kit: že zrovna ty se zajímáš o práci více
vývojářů. , sdraco: fajn
avatar.
David Čápka Hartinger:14.8.2013 21:21
Co třeba taková třída Math v Javě? Budeš si předávat všude instanci
abys udělal mocninu? 
Neaktivní uživatel:15.8.2013 10:34
Taky mě jeho odpovědi na objektivitu matou.
Luboš Běhounek Satik:15.8.2013 11:58
No, asi by to šlo, ale taky si to musíš posílat celou hierarchií, což
je otravné, ale jeden parametr už by se snad dal překousnout .
Nebo by se to dalo udělat tak, že by sis udělal statickou třídu, která by měla odkazy na instance všech těch objektů (takže ty objekty jako TextureManager apod. by statické nebyly), nějak takto:
public static class ResourcesAndSimilarStaticUglies
{
public static TextureManager TextureManager;
public static SoundManager SoundManager;
public static FontManager FontManager;
public static ScreenInfo ScreenInfo;
public static MouseState MouseState;
public static KeyboardState KeyboardState;
}Lukáš Hruda:15.8.2013 12:29
Ještě by bylo možná ideální udělat Manager jako šablonu (generickou
třídu) a dodávat typ (Manager<Animation>, Manager<Font>...)
rozdíly v rozhraní a datových položkách bych vyřešil ve specifikacích,
což v C# asi neuděláš, tam bys mohl oddědit pak jednotlivé Managery.
Uplně ideální by bylo kdyby tam žádné rozdíly nebyly
Luboš Běhounek Satik:15.8.2013 13:26
Objekt Game, objekt Map, objekt Texture... tak jak je to tedy objektově,
když ne takhle?
TextureManager nekreslí, ten jen udržuje u sebe seznam textur.
Vytvoříš nový GameObject, třeba tank -> načte si z manažeru
texturu.
Ne, GameObject má metodu Draw(), která podle jeho pozice a fáze animace vykreslí správnou texturu na správné místo.
Petr Nymsa:15.8.2013 14:05
Já to dělám stejně jako Luboš Běhounek Satik a přijde mi to přehledné . Do managerů si načtu všechny
potřebné texturu a poté různé GameObjecty si načítájí texturu jakou
chtějí.
Luboš Běhounek Satik:17.8.2013 1:34
To je celkem relativní, záleží na tom, co bereš jako centrum vztažné
soustavy
TomBen:17.8.2013 9:14
Na tom nic logického není.
Země je placatá, nesou ji čtyři sloni,
kteří stojí na zádech obrovské želvy.
To ví přece každý.
programování přes funkce i OOP má svá plus i své proti.
Já jsem s OOP začal víceméně letos a tak se jej stále snažím
pochopit.
A můj pohled na OOP je asi tento:
OOP je takové nástavba "funkcionálního" programování. Pamatuji si na své začátky s programováním v Basicu. O funkcích jsem nevěděl a tak něco jako funkce jsem používal příkaz GOTO, kde jsem měl určité řádky věnované konkrétní činnosti.
Funkce, pak tento proces nahrazovaly s tím, že se navíc předávali
parametry. Ale asi každý kdo napsal "větší" program, dostane se do stavu,
že má 387funkcí, kde mnoho z nich dělá podobné věci, ale jsou určeny ke
konkrétní práci. A zde přichází kouzlo OOP, kde části programu
zastupují objekty, kterým se dají upravit parametry, rozšířit, vzájemně
propojit.
Zkrátka klady a pozitiva.
OOP je potřeba před používáním pochopit. Chápu, zde píšící
"machry", kteří už OOP vidí za vším. Ale my ostatní musíme prostě pro
OOP ještě dozrát. A těm zkušenějším velké díky za trpělivost a pomoc
David Hynek:17.8.2013 19:25
omlouvám se za svůj češtin... takže z pohledu gramatiky pro prosím neposuzujte.
Luboš Běhounek Satik:18.8.2013 0:34
S tebou se nedá normálně diskutovat, pořád jen slovíčkaříš a stáčíš diskuzi jinam, i s Matesaxem ta diskuze měla vyšší úroveň...
"Co je to "Pole tříd"? V OOP, pokud vím, nic takového není."
- Víš moc dobře, že tím bylo myšleno pole instancí tříd...
"Do vlastností tříd nikdy nic nepřiřazuji."
- Tak možná používáš settery, to je fuk, vyjde to nastejno.
"Vytváření třídy dělá JIT kompilátor. To je pouze při spouštění."
- Zase slovičkaření.
"Třídu nikdy daty neplním, protože by to bylo pomalé."
- Tak to jsi asi výjimka, 99% lidí třídy nějakými daty plní, protože
třída bez dat je většinou jaksi k ničemu
"Efektivita a rychlost je v OOP ukryta jinde."
Kde?
Tak já se taky zapojím. V OOP je objekt složitým datovým typem, tím nejsložitějším. Proto bude vždycky pomalejší. Taky bere ohromné množství paměti. Ale OOP se kvůli rychlosti nevyužívá. Určitě není nutné bát se OOP kvůli rychlosti, protože v lidském vnímání je rozdíl opravdu minimální. Také záleží na návrhu aplikace. Já se vždycky snažím držet podle citátu:
Vždy pište kód tak, jako by ten chlapík, co ho po vás bude udržovat, měl být násilnický psychopat, který bude vědět, kde bydlíte.
Když máš v aplikaci 500 objektů, z čehož v dobrém návrhu užíváš najednou jen 10 a ve špatném všech 500, je to rozdíl.
Jak už jsem psal, OOP se kvůli rychlosti neužívá, užívá se kvůli rozdělení aplikační části a kvůli přehlednosti, znovupoužitelnosti a obecnosti.
Snorlax: Věř, že kdyby to v OOP bylo pomalejší a zároveň horší jako
návrh, nikdo by to nepoužíval. Ovšem OOP používá každý druhý programátor (nepočítám ty,
kteří pracují v plně objektových jazycích nebo neobjektových jazycích),
takže si můžeš být jistý tím, že sám narazíš na výhody, které OOP
přináší.
Zobrazeno 112 zpráv z 112.