Názory k článku Perličky: principy objektového programování
-
Samozrejme je to mozne, zalezi na Vasem stylu. Ja osobne, ac je to mozna trochu kacirske, nemam rad "idiomy". Idiomy byvaji casto krypticke a nekdy i delaji malinko neco jineho, nez si predstavujete. Navic v tomto konkretnim pripade jeste hraji svou roli dva dalsi faktory. Za prve, takoveto "pretezovani" konstruktoru doporuciji jen ve specialnich pripadech, jinak opet trpi prehlednost kodu. Za druhe, jak uvidime v pristim dile, na konstrukci trid se daji s uspechem pouzit moduly, cili k blessovani se jeden ani nedostane. -
paja (neregistrovaný)Pěkný úvod. Přimlouvám se za pokračování (po Inside::Out) o objektovém systému Moose. Ač nejmladší, je velmi populární a má pár vlastností které stojí za pozornost.
-
anonymníJak má někdo brát vážně Vaše názory, že nejlepší je programovat objektově.
Vždyť Vy ještě nejste schopen psát odpověď správně česky. Přečíst se to nedá (s promíchanými programovými výrazy).
Co kdybyste začal od kódů češtiny - a začněte studovat strukturovaně a objekově a uvidíte, že to pár let nebudete vůbec chápat. Myšlení totiž není ani strukturované a už vůbec není objektové. -
To neni muj nazor. Pochybuji, ze bych ho nekde takto prezentoval. Jak OO programovani, tak normalni (proceduralni) maji sve misto. Vlastne je mezi nimi celkem siroka seda zona, ve ktere se da volne pohybovat a programatori to tak i delaji.
Co se tyce zbytku Vaseho prispevku, nemohu si z nej vzit nic pro vylepseni sveho serialu. Zkuste to pojmout konstruktivneji. -
Rejpal (neregistrovaný)A zase ta terminologie. :-) Slovo "procedurální" je v dnešní době tak vágně definované, že bych s ním radši moc nemachroval. Za mých mladých let "neprocedurální" znamenalo v první řadě Prolog a všechny jazyky, kde člověk nepsal "procedury", tedy algoritmy, ale deklarativní pravidla a znalosti ("co" místo "jak").
-
Jistě, když porovnáváme jednotlivá paradigmata, může se ta odpověď lišit. Já ale spatřuji problém v tom, že třeba na rozdíl od Smalltalku, kde se pořád dokola posílají zprávy objektům, je například v Javě nebo v Perlu i přes použití OOP prvků programování pořád založené na strukturovaných základech - podmínky, cykly apod. Proto si myslím, že v kontextu Perlu není chybou mluvit o protikladu procedurálního a objektového přístupu.
-
Slovo "procedurální" je v dnešní době tak vágně definované, že bych s ním radši moc nemachroval.
Potazmo kazdy dalsi termin je definovan stejne vagne a vyjadrit svuj nazor byva cim dal tim tezsi. Zvlaste pak pokud nejsem zrovna expert v teorii o rozdeleni programovacich jazyku.
Odpovidal jsem spise na "nejlepsi je" nez na "programovat objektove" a chtel jsem vyjadrit starou znamou pravdu, ze nejlepsi neni nic, ale ze zalezi na ucelu.
-
wayan (neregistrovaný)
Rozumná praxe je přistupovat k objektům jako k objektům ("atributům" přes accessory) a mimo konstruktor zapomenout na implementaci, to znamená $self->kocka->jmeno místo $self->{kocka}->{jmeno}. Jistě namítnete, že by to na úvodní lekci bylo příliš, bohužel ze spousty programátorů v Perlu už rovnici objekt = hash nikdy nedostanete.
Hnida, nicméně nedá mi to. Považuji za dobrý zvyk na úvod metody vytáhnout a pojmenovat parametry:
sub new { my ($class, $jmeno, $kocka) = @_; my $self = $class->SUPER::new($jmeno); $self->{'kocka'} = $kocka; return $self; }Další hnida. Naučíte-li čtenáře používat and místo "normálního" &&, začnou psát věci jako:
my $is_between = $i >= $min and $i <= $max;
a budou se drbat na hlavě.Tohle je na flamewar, ale občas je na místě ternární operátor místo podmínky. Vy totiž nechcete rozvětvit běh programu, ale vyhodnotit výraz:
# mimochodem je-li v kocce neco, proc to jeste testovat na referenci? sub projev { my $self = shift; return $self->SUPER::projev() . ( ref $self && $self->kocka ? 'na kocku jmenem '. $self->kocka->jmeno : ', nejlepe na kocky' ); }Jaký smysl má test na objekt v DESTROY? Takový případ vznikne jen tehdy, pokud bude někdo destruktor volat explicitně jako metodu třídy. Nicméně, volá-li ho explicitně, pak mu není pomoci a je to špatně i když ho volá jako metodu objektu.
-
Rozumná praxe je přistupovat k objektům jako k objektům ("atributům" přes accessory)
To mate pravdu. Ale jelikoz toto jsou spise blessovane hashe nez objekty, tak je to zbytecna prace. Stejne bude nakonec na uzivateli, zda accessor pouzije, nebo ne. Jina je situace v inside-out objektech (viz dalsi clanek), kde accessory jsou nutnost, jelikoz primy pristup k polozkam neexistuje.
Považuji za dobrý zvyk na úvod metody vytáhnout a pojmenovat parametry
Opet mate pravdu, ale opet jsem tomu nevenoval velkou pozornost zejmena z duvodu ze se jedna o spise teoreticky clanek a skolni priklad. Uplne nejlepsi by bylo udelat to stylem
my ($class) = shift; my %args = (defaultni => hodnoty, @_)a pouzivat pojmenovane parametry, aby si nikdo nemusel pamatovat, co je prvni a druhej parametr konstruktoru.my $is_between = $i >= $min and $i >= $max;Takovouto botu by vychytal
use warnings. Pokud by se ctenar chtel odemne ucit konkretni praktiky psani kodu, tak at se radeji nauci prave pouzivat warningy a k tomu pouziva svuj vlastni styl (pokud mozno citelny).ternární operátor místo podmínky
Zde mate take pravdu a dokonce nemam ani namitek. Ve starsi verzi
projevto tak i je. Proc je tam pak dal if, to nevim, ale asi to bylo tak, ze jsem tam mel puvodne vice prikazu, ktere jsem casem smazal.Jaký smysl má test na objekt v DESTROY?
Ten pripadne muze byt vypusten, take pravda.
