vai leitot RETURN vai tomēr ne (diskusijas turpinājums)

[codez]

Neviens no linkiem nav ne tuvu līdzīgs tavai interpretācijai. Atkal. Visi 4 pirmie linki validē argumentu atbilstību prasībām. Javapractice topiki vēlreiz pasaka to pašu, ko es tev esmu centies ieskaidrot visa topika garumā. Par PHP linkiem - tu nolinkoji zend validatoru? un? Tu redzi, ka no visām šīm klasēm tikai 6 ir izņēmumi? Un pārējās met izņēmumus tad, kad ir anomālas situācijas, piemēram, mēģina izvilkt neesošu db instanci. Tas pats ar Symfony un Kohanu. Da i bļin palasi taču, kur šie izņēmumi tiek lietoti un kam viņi tiek lietoti.

 

Tad izsaki savu versiju, kur, piemēram, Kohanā ir paredzēts lietot Validation_Exception, na ne pie gadījuma, kad validācija nogājusi greizi?

 

 

P.S. Man patiešām žēl, ka pat savai sievai esi pamanījies iestāstīt, ka neviens bez tevis nu nekur un nekā, nevienu soli. Also, mana sieva ir tikai par to, lai es visu visiem "teiktu priekšā", tā pat, kā es. Zini, tā tēze par "noķer cilvēkam zivi, viņš būs paēdis dienu. Iemāci viņu makšķerēt - viņš būs paēdis visu mūžu" un tamlīdzīgi, nekam nederīgi morāles principi. :)

Whats your problem? Tev pat jāpierāda, ka tev sieva labāka?

Par to tavu kodu - apsvēri domu izmantot divas getAuth() metodes - getAuthUser() un validateGetAuth() kur getAuthUser atgriež kontu vai null (null - nav konta), kur nepieciešams un validateGetAuth() pārbauda lietotāju un ja lietotāja nav, saglabā esošo soli un nosūta lietotāju autorizēties?

Nerakstīšu to, ko Kavacky jau paspēja, tik piebildīšu, ka nebūtu pareizi validateGetAuth funkcijai piešķirt FC kompetenci - tas ir nodot aplikācijas vadību kāda kontrolera (konrkēti šijā gadīumā login kontrolera) pārraudzībā.

Par to, kuram kontrolerim tiek nodota vadība atbild FC un neviens cits, un noteikti ne kaut kāda validateGetAuth funkcija.

Es darītu vēl vairāk - kontrolierī, kur nepieciešams auth invokētu validateGetAuth konstruktā vai pirms action invokēšanas pret ACL. Šādi

1. Viss, kas ir ACL atzīmēts kā aizsargāts ir aizsargāts bez liekas koda bakstīšanas katrā vietā un autorizācijas metodika ir pārizmantojama

Ko darīsi, ja viena kontrolera, vai pat viena ekšana ietvaros būs paredzēti abi gadījumi. Gan, kad lietotājs ir autorizējies, gan, kad lietotājs nav autorizējies.

Piemēram addComment, kur komentārus var pievienot, gan neautorizēti, gan autorizēti lietotāji?

Taisīsi 2 atšķirīgus kontrolerus? klienta pusē būs 2 case, kuru kontroleri izsaukt?

[codez]

Konstrukcijā būtu tikai viens ifs - validateGetAuth metodē. Neviena ifa vai izņēmuma kontrolierī. Papildus visam šim, netiek lieki invokēts kontroliera actions jo precondition nav izpildīts.

Toties pamatīgi lieki tiks darbināts viss ACL, gan tur, kur vajag, gan tur, kur nevajag, jo jāpārbauda jau ir.

Es tomēr pieturos pie filozofijas: "It's easier to ask forgiveness than it is to get permission."

Bez tam autorizācija ir tikai viens no neskaitāmiem izņēmumiem. Katram būvēsi savu priekšapstrādes sistēmu? Vai tad tiešām nebūtu ērtāk izmantot vienu vienotu izņēmumu/speciālgadījumu apstrādes mehānismu - pie tam vienkāršāku.

Pie tam, kamēr tu pārrakstīsi visus savus līkos kontrolierus lai pamainītu autentifikācijas rutīnas ar saviem izņēmumiem un ifiem, es to izdarīšu vienā vietā - kontroliera bāzes failā.

Kurā piemēra ar eksepšanu kotrolerī ir kaut viena autentifikācijas rutīna?

Atbildēšu tev priekšā - nevienā.

Vēlviens codez, kas nejēdz lasīt, to kas rakstīts, bet no pirksta izzīž kaut kādus pieņēmumus.

Jā, jā, visi muļķi, tik tu tāds stalts un gudrs padevies. Edited March 12, 2013 by codez

[F3llony]

Whats your problem? Tev pat jāpierāda, ka tev sieva labāka?

Mana sieva ir vislabākā. Visi, kas apgalvo pretējo tiks nežēlīgi sadedzināti elles liesmās. :)))

Par to, kuram kontrolerim tiek nodota vadība atbild FC un neviens cits, un noteikti ne kaut kāda validateGetAuth funkcija.Ko darīsi, ja viena kontrolera, vai pat viena ekšana ietvaros būs paredzēti abi gadījumi. Gan, kad lietotājs ir autorizējies, gan, kad lietotājs nav autorizējies.

Loģiski.  Bet neviens netraucē kontrolierim ekstendot citu kontrolieri, kurā šī validateGetAuth tiek invokēta. Ja vienā būs paredzēti abi, nohandlēšu ar ifu, kur getjuzers ir/nav null.

Piemēram addComment, kur komentārus var pievienot, gan neautorizēti, gan autorizēti lietotāji?

Taisīsi 2 atšķirīgus kontrolerus? klienta pusē būs 2 case, kuru kontroleri izsaukt?

Ja jūžers nav null, tad juzers ir juzers. Neredzu vajadzību pēc exceptioniem.

Toties pamatīgi lieki tiks darbināts viss ACL, gan tur, kur vajag, gan tur, kur nevajag, jo jāpārbauda jau ir.

Es tomēr pieturos pie filozofijas: "It's easier to ask forgiveness than it is to get permission"

Nafig? Tur, kur nav plānots Auth - neextendo AuthKontroliera bāzi, bet gan parasto. WTF. 

 

Par taviem piemēriem neizteikšos. Ja neproti savilkt paralēles starp vieniem un tiem pašiem principiem, nav mana problēma.

Edited March 12, 2013 by F3llony

[codez]

Okay, pieņemsim, ka validāciju tu atrisinātu ar ACL, ko es personīgi vērtēju, ka pietiekami derīgu risinājumu, lai gan tik un tā palieku pie tā, ka ar eksepšoniem ir ērtāk un ir noteikti gadījumi, kur ar ACL var nepietiek, bet tas būs reti un var jau arī ACL pielāgot, ja rodās šāda vajadzība.

Bet tagad paņemsim vēl dažus speciālgadījumus no mana piemēra:

1)Nav iespējama db konekcija. Kurā vietā tas tiks pārbaudīts, kā tas tiks pārbaudīts un kas tiks darīts tādā gadījumā?

2)Lietotājam nepietiek naudas virtuālajā maciņā, lai nopirktu itemu. Skaidrs protams, ka klienta pusē to var pārbaudīt, bet pieņemsim, ka kāds scriptkidijs tomēr izdomājis apiet klienta puses pārbaudi un nosūtīt pieprasījumu pirkt par vairāk naudu, kā ir makā?

Ideāli, ja spētu atbildēt ar kaut cik jēdzīgu pseidokodu.

 

 

P.S. Bez tam neatbildēju uz svarīgu, bet tev neizdevīgu jautājumu:

Tad izsaki savu versiju, kur, piemēram, Kohanā ir paredzēts lietot Validation_Exception, ja ne pie gadījuma, kad validācija nogājusi greizi?

Edited March 12, 2013 by codez

[F3llony]

1. Atkarīgs no tā, kurā solī DB konekcija nepieciešama - ja sistēma ir DB atkarīga (lapas koks, settingi, vēl kaut kas), DB būs nepieciešams vēl pirms kontroliera un attiecīgi jāpārbauda pirms tam. Taču šajā gadījumā, es nekur neesmu teicis, ka DB konekcijas neesamība tad, kad tā nepieciešama nav anomālija. Šeit viennozīmīgi jālieto exception, ar atšķirību, ka catch nepieciešams kods, kas mēģinātu rekonektēt DB. Handlētu pati DB abstrakcijas klase, kas attiecīgi arī izsauktu kļūdu izvadi vai generic kļūdu un logotu eventu caur FC. 

2. Klienta pusē pārbaude nenotiek, notiek servera pusē, kur nepietiekoša funda gadījumā vienkārši atslēdz iespēju doto ītemu pirkt brutāli aizvācot pogu vai kaut ko no šīs sērijas. Normāli lietotāji to necentīsies apiet, nenormāliem smukus kļūdu paziņojumus nevajag :). Šo protams var apiet, tāpēc fundi jāpārbauda pirms tranzakcijas un to var izdarīt ar vienkāršu ifu. if funcdi pietiek do tranzakcija else HOW the f did you get here. Visi citi gadījumi - vairāki tabi etc etc ir anomālas situācijas un normālā gadījumā ir feilojamas ar kļūdas paziņojumu. 

 

Iztiksi bez pseidokoda.

Edited March 12, 2013 by F3llony

[Mr.Key]

Vai arī tu varētu izbeigt būt daunis, jo ņehuj kaut ko pārbaudīt pa vidu visās reizēs, kad tiek izsaukta metode, ja var pārbaudīt tikai vienreiz - pašā metodē?

 

Ar tādu centību un tieksmi vairāk darīt tev grāvji jārok, nevis jāprogrammē. Jo no minētajiem tikai grāvju rakšanā ir svarīgs izraktā grāvja garums; jo garāks, jo labāk.

Tu piedāvā visās metodēs "pārbaudīt tikai vienreiz - pašā metodē"?

 

Kāpēc tik ļoti centies regulēt, kuram nebūt programmēt? Varbūt Tu pats zemapziņā baidies no atklāsmes, ka esi izvēlējies neīsto jomu un tāpēc centies atgrūst citus? Dīvaini...

[Mr.Key]

Bet tieši šāda izmantošana man nepatīk

Man nepatīk, ka uz darbu jāiet 9-18. Ļoti nepatīk. Bet, iespējams, ir iemesls, kāpēc pasaule tā iekārtota. Tas pats attiecas uz programmēšanu.

[php newbie]

Man nepatīk, ka uz darbu jāiet 9-18. Ļoti nepatīk. Bet, iespējams, ir iemesls, kāpēc pasaule tā iekārtota. Tas pats attiecas uz programmēšanu.

 

nu tad pastāsti kāpēc?

[F3llony]

Tāpēc, ka pasaulē tu neesi vienīgais. 

[Mr.Key]

Tāpēc, ka pasaulē tu neesi vienīgais.

Izcili!

 

Neesmu darbojies citās jomās, varbūt tur tas nespēlē tik ļoti lielu lomu, nekā programmēšanā, tāpēc nekrīt acīs tik ļoti, ja šo faktu ignorē. Varbūt citās jomās tos, kuri negrib pieņemt šo faktu, vienkārši izgrūž. Piemēram, atnāk celtnieks uz darbu un pasaka, ka viņam nepatīk standarta ķieģeļi, viņam gribas katru ķieģeli savādāku un tie pamati arī, nu priekš kam tie vajadzīgi... Domāju, ka tur ar tādiem nediskutē, kā programmētāju vidū - mēģina pārliecināt, ka, redz, vajadzētu tā kā ievērot labās prakses, derētu tā kā patternus pielietot utt.

 

Tad tādi izgrūsti, "neviena nesaprasti", šie cilvēki pamana, ka varbūt varētu programmēt - maldīgi pieņemot, ka tur var darīt visu tā, kā gribās pašam.

Edited March 12, 2013 by Mr.Key

[codez]

1. Atkarīgs no tā, kurā solī DB konekcija nepieciešama - ja sistēma ir DB atkarīga (lapas koks, settingi, vēl kaut kas), DB būs nepieciešams vēl pirms kontroliera un attiecīgi jāpārbauda pirms tam. Taču šajā gadījumā, es nekur neesmu teicis, ka DB konekcijas neesamība tad, kad tā nepieciešama nav anomālija. Šeit viennozīmīgi jālieto exception, ar atšķirību, ka catch nepieciešams kods, kas mēģinātu rekonektēt DB.

Es, piemēram, savā freimworkā izmantoju Lazy Loading principu un esmu realizējs tādu struktūru, ka db klase tiek ielādēta un db tiek inizializēt tieši pie pirmā kverija izsaukšanas.

Teiksim, ja viena kontrolera ietvaros var būt abas situācijas - db tiek izmantots, db netiek izmantots, tad db tiks inicializēta tikai tad, ja db tiks izmantots un tas notiks automātiski izsaucot pirmo kveriju.

Tāds gadījums var būt, piemēram, ja dati tiek paņemti no keša un db nav nepieciešams.

Kāpēc Lazy Loading ir labs un ērts, tā varētu būt atsevišķa diskusija, bet kontekstā ar to, nav iespējams strikti definēt vietu, kur tiks izsaukta db inicializācija.

Bet šeit par eksepšaniem šķiet īpaši mūsu domas neatšķirās.

Handlētu pati DB abstrakcijas klase, kas attiecīgi arī izsauktu kļūdu izvadi vai generic kļūdu un logotu eventu caur FC.

Varbūt tā ir neprecīza iteikšanās vai mana interpetācijas, bet šis variants, kur DB klase izsauc kļūdu izvadi man strukturāli pareizs, jo kļūdas izvade nozīmē aplikācijas kontrolers nodošana kļūdu izvades kontrolerim un šī nodošana nav jādara db abstrakcijas klasei, bet gan FC.

2. Klienta pusē pārbaude nenotiek, notiek servera pusē, kur nepietiekoša funda gadījumā vienkārši atslēdz iespēju doto ītemu pirkt brutāli aizvācot pogu vai kaut ko no šīs sērijas.

Ajaxīgās aplikācijās, kur vairāki pirkumi var notikt vienas lapas ielādes ietvaros, šādu pārbaudi lietotāja ērtības dēļ varētu veikt (būtu jāveic) arī klientu pusē, bet ne tas šeit svarīgs.

Normāli lietotāji to necentīsies apiet, nenormāliem smukus kļūdu paziņojumus nevajag :). Šo protams var apiet, tāpēc fundi jāpārbauda pirms tranzakcijas un to var izdarīt ar vienkāršu ifu. if funcdi pietiek do tranzakcija else HOW the f did you get here. Visi citi gadījumi - vairāki tabi etc etc ir anomālas situācijas un normālā gadījumā ir feilojamas ar kļūdas paziņojumu.

Patiesībā vairāki tabi nav tik nereāla situācija. Es zinu pietiekami daudz cilvēkus, ka vienlaiku vienu web aplikāciju lieto vairākos tabos. Pat šim forumam man pašlaik ir atvērti vairāki tabi. Tā ka tā ir pietiekami reāla situācija, kur lietotājam būtu jāparāda smuks kļūdas ziņojums.

 

Tātad, mēģināšu uzrakstīt tavu teikto pseidokodā, ja kļūdos kaut kur principiaļi palabo:

if ($account->isEnoughMoney($total) and
    $account->isEnoughSpace($amount)) {
  $account->decMoney($total);
  $account->addItems($itemid, $amount);
} else {
  $response->addError('How da hell you get there!');
}
 

Tagad jautājumi:

Vai tavā variantā $account->$decMoney() iekšēji vēlreiz pārbauda, vai pietiek vietas?

1)ja jā, tad kāpēc 2 reizes jāpārbauda viens un tas pats.

2)ja nē, tad kā nodrošināties pret to, ka kāds (cits developers, kurš izstrādā kādu aplikācijas vietu FW un jau uzbūvēdo modeļu API ietvaros) kādā no situācijām aizmirst pārbaudīt, vai pietiek nauda pirms decMoney izsaukšanas.

 

Tālāk, teiksim tagad ir vajadzīgs vēlviens pirkuma veids. Lietotājs par naudu var nopirkt vairāk space savā inventorijā. Balstoties uz tiem pašiem principiem, būs tavā gadījumā vajadzētu būt šādam pseidokodam: (palabo, ja es kaut kur interpretēju tavu variantu nepareizi)

if ($account->isEnoughMoney($total) and
    $account->canIncreaseSpaceBy($amount)) {
  $account->decMoney($total);
  $account->increaseSpace($amount);
} else {
  $response->addError('How da hell you get there!');
}
 

Tātad, atkal kontrolerī ir jāraksta pārbaudes rutīna, kur parādās jau iepriekš kodā redzēts paterns, attiecīgi jau vismaz divās vietās tiek pārbaudīts, vai nauda pietiek, pirms tā tiek samazināta:

 

if ($account->isEnoughMoney($total)) {
  $account->decMoney($total);
}

Tātad jau netiek ievērtos DRY princips.

 

Tagad mans variants ar eksepšaniem, ir strādājoša sistēma ar kores funkcionalitātes api. Atnāk jauns developers un viņam ir jāuzraksta abas šīs darbības. Lūk kā alternatīvais posms izskatīsies manā variantā, pie tam ar mazāku iespēju kādu speciālgadījumu izlaist:

nopirkt itemu:

 

$account->decMoney($total);
$account->addItems($itemid, $amount);

nopirkt vairāk space:

 

$account->decMoney($total);
$account->increaseSpace($amount);

Manā variantā nepārādās atkarots koda paterns.

Manā variantā nav iespējams palaist garām izņēmumus: pietrūkst nauda, pietrūkst space, nevar nopirkt vairāk space, kā maxspace un visus citus, kuri šai gadījumā netiek apskatīti un pārbaudīti, bet varētu rasties.

 

 

Vēl viena lieta par uzturēšanu:

Piemēram, sākotnēji izstrādājot aplikāciju nebija paredzēts, ka būs kaut kādi ierobežojumi itemu daudzumam un nekādas pārbaudes netika veiktas, visās vietās rakstīja $account->addItem(), vai tā būtu itemu pirkšana, maiņa, vinnēšana loterijā, utt.

Aplikācija attīstās un tiek nolemts, ka vajag limitu tomēr.

Tavā gadījumā visās vietās ir jāraksta pārbaudes. Tas protams nav nekas nereāls un IDĒ izmantojot find usage var atrast visas vietas, kur ir izmantots addItem(), bet tomēr, eksepšanu gadījumā pārbaudi uzraksta pašā addItem funkcijā un viss pārējais turpina strādāt pareizi, jo pie mēģinājuma palielināt items virs atļautā limita, tiks izsaukts eksepšans, kuru visdrīzāk pārķers FC un nodos aplikācijas kontroli kļūdu paziņošanas kontrolerim.

 

 

 

[Mr.Key]

 

$account->decMoney($total);$account->increaseSpace($amount);

Manā variantā nepārādās atkarots koda paterns.

Manā variantā nav iespējams palaist garām izņēmumus: pietrūkst nauda, pietrūkst space, nevar nopirkt vairāk space, kā maxspace un visus citus, kuri šai gadījumā netiek apskatīti un pārbaudīti, bet varētu rasties.

Var gan, skat. kā:

 

$account->increaseSpace($amount);

 

Ja var aizmirst biznesa loģiku, tad to var aizmirst arī šādi - aizmirstot noņemt naudu. ;)

[rpr]

Neesmu te iebraucis šajā topikā, kaut kā palaidu garām, bet vai tik te neiet runa par solid un srp jeb single responsibility principles.

Edited March 13, 2013 by rpr

[Mr.Key]

Pirmo reizi dzirdu šādus principu nosaukumus, bet, pēc tā, ko tie izsaka - es teiktu, ka jā! :-)

[Kavacky]

Tu piedāvā visās metodēs "pārbaudīt tikai vienreiz - pašā metodē"?

Jā.

Man nepatīk, ka uz darbu jāiet 9-18. Ļoti nepatīk. Bet, iespējams, ir iemesls, kāpēc pasaule tā iekārtota. Tas pats attiecas uz programmēšanu.

Kas ta' nu? Saimnieks "aizmirsa" pateikt, ka darba dienas garums nu jau kādu laiku ir samazināts līdz 8 stundām, bet nabaga Mr. Key joprojām rauj 9. 

 

Tāpēc, ka pasaulē tu neesi vienīgais.

Citēšu Mr. Key, jo viņa novērtējums pilnībā sakrīt ar manējo: "Izcili!"

Tikai, lai nevērīgāks lasītājs nepārprastu, precizēju - jo pasaulē ir ļoooti daudz vergu, atliektiem galiem.

 

Bet par to darba laiku ir arī viena cita problēma, kāpēc jāstrādā 8 stundas dienā, 5 dienas nedēļā. Redz, agrāk viss bija normāli un cilvēki strādāja vismaz 16 stundas dienā 7 dienas nedēļā, par vēdera tiesu un ar tieši tik daudz brīva laika, lai saražotu čupu ar sava DNS replikācijām, plus vēl nedaudz kapeiku, lai varētu mazliet patērēt saražoto.

 

Un šāda idille arī turpinātos mūsdienās, ja vien neuzrastos bariņi ar pasistiem hipijiem, kuru krājumā nez kur uzradās visādi debili postulāti par cilvēktiesībām, paverdzināšanu, utml. muļķībām. Sacēla tādu haju, ka krietnajiem saimniekiem tur pa bišķītim, pa bišķītim vajadzēja tās darba stundas apīsināt.

 

 

Neesmu darbojies citās jomās, varbūt tur tas nespēlē tik ļoti lielu lomu, nekā programmēšanā, tāpēc nekrīt acīs tik ļoti, ja šo faktu ignorē. Varbūt citās jomās tos, kuri negrib pieņemt šo faktu, vienkārši izgrūž. Piemēram, atnāk celtnieks uz darbu un pasaka, ka viņam nepatīk standarta ķieģeļi, viņam gribas katru ķieģeli savādāku un tie pamati arī, nu priekš kam tie vajadzīgi... Domāju, ka tur ar tādiem nediskutē, kā programmētāju vidū - mēģina pārliecināt, ka, redz, vajadzētu tā kā ievērot labās prakses, derētu tā kā patternus pielietot utt.

 

Tad tādi izgrūsti, "neviena nesaprasti", šie cilvēki pamana, ka varbūt varētu programmēt - maldīgi pieņemot, ka tur var darīt visu tā, kā gribās pašam.

Mr. Key atkal kaut ko runā paralēli patiesībai. Salīdzinājums pašā saknē ir greizs, jo Mr. Key ar celtniekiem modelē situāciju, kur atnāk jauns programmētājs un piedāvā, piemēram, strukturēta MVC koda vietā sākt rakstīt spageti. Kamēr tas, ko šeit daram mēs ar codez - mēs nākam pie celtniekiem, kuri lietusmežos būvē mājas no kartona kastēm, lai parādītu, cik labs izejmateriāls slapjā vidē ir ūdensizturīgs dzelzsbetona bloks.