Jump to content
php.lv forumi

Recommended Posts

Nevajag aizmirst, ka cilvēkam ir tikai dabiski kļūdīties. Un ja tu savā koda uzbūvē ļauj iespēju programmētājam kļūdīties, tad viņš noteikti vismaz vienreiz arī kļūdīsies. Tāpēc labāk būvēt kodu tā, lai tādu iespēju ir pēc iespējas mazāk.

Link to post
Share on other sites
  • Replies 33
  • Created
  • Last Reply

Top Posters In This Topic

andrisp, nu nē, oop ļoti pieradina pie sistēmas darbā :) Bez tam sistemātiskums iekš oop ļoti nāk par labu galvenajam programmista tikumam - slinkumam. Esi kārtīgi visu pārdomājis - uzrakstīsi ātri, un bez hemoroja :) Nemaz nerunājot, cik laik ietaupīsi uz vēlāku modificēšanu un fīču pielikšanu...

Link to post
Share on other sites

john.brown, protams, es jau nesaku pretējo, bet gan vai sistēmu nevajadzētu plānot tā, ka nemaz nepastāv iespēja aizmirst vai arī inicializēt otrreiz datubāzes klasi ? Tad pazudīs vajadzības pēc tā singleton patterna.

Link to post
Share on other sites
Tad pazudīs vajadzības pēc tā singleton patterna.

Bet tas singletone jau kā reizi ir tā sistēmas struktūras daļa, kura neļauj vairākas reizes inicializēt to klasi :D Tas ir apmēram tā pat, kā teikt "vai nevajadzētu autiņā ierīkot tā, lai iesēžoties motors pats palaižas? Tad arī pazudīs vajadzība pēc motora"...

 

P.S. piemērā steigā bik piemirsu, bet korekti būtu konstruktoram jābūt private, un nekā citādi, kā caur ClassName::instance() pie klases vairs tikt nevarētu...

Edited by john.brown
Link to post
Share on other sites

john.brown, tas piemeers raksturo tieshi singletone patternu. Es tieshi apgalvoju, ka nevajag sisteemu taisiit taa, ka developerim nav jaadomaa par to vai db ir inicializeeta vai nav. Jaabuut taa, ka izmetas kljuuda gan tad kad meegjina inicializeet db otreiz, gan tad, kad meegjina izmantot neinicializeetu db.

 

Bet nu es oop iipashi nepaarzinu :)

Link to post
Share on other sites

Bet varbūt vajag tā, ka tā vienkārši nevar uzrakstīt, tb skripta parsēšanas (jeb ja ir programma, tad kompilēšanas) laikā tiek parādīta kļūda. Un nevis runtaimā mests exceptions/errors.

PHP veida (tb skriptu) valodām tas varbūt tik labi neizpaužās, taču kompilējamām (C/C++/Pascal/...) valodām tas ļoti labi izpaužas, tb ka vajag pēc iespējas vairāk kļūdu noķert kompilēšanas laikā, nevis runtaimā.

Link to post
Share on other sites
Es tieshi apgalvoju, ka nevajag sisteemu taisiit taa, ka developerim nav jaadomaa par to vai db ir inicializeeta vai nav. Jaabuut taa, ka izmetas kljuuda gan tad kad meegjina inicializeet db otreiz, gan tad, kad meegjina izmantot neinicializeetu db.

 

Tu tieši jauc 2 gadījumus, kad ir webs, kas lieto vienu konekciju, un ir kas lietos 2 un N konekcijas.

Ja gribi lai strādā webs optimāli, tad ir jātaisa tā kā nepieciešams.

 

U kāpēc uzreiz jālieto singletoni, ja var to visu globāli nodefinēt ? (tipa globāla konekcija)... Pie katra Query nebūs papildus instrukcijas PHP korei. Varbūt izklausās smieklīgi, bet high-load gadījumā katrs IF un f-jas izsaukšana patērē resursus.

 

Te nu man nāk atmiņā fakts, ka 10% enerģijas pasaulē patērē tieši ierīces kas atstātas nevajadzīgajā "stand-by" režīmā ... Programmatūrā katrs 1% perfomance ir zelta vērts.

Kāpēc nevar izdarīt to, kas ir jādara, un kāpēc ir jādara tas, kas nav vajadzīgs (es neesmu pret OOP)

Link to post
Share on other sites
Programmatūrā katrs 1% perfomance ir zelta vērts.

 

Tā nu gan nav tiesa. 80/20 likums - 20% koda patērē 80% laika (citi saka, ka precizāki skaitļi ir 90/10).

Nav vērts optimizēt lietas, kas tikai 1% laika vairāk iedos. Šādas lietas optimizēt prasīs tikai lielu laiku no developera, kura viņam tāpat vienmēr jau trūkst.

Vairums laika tiek patērēts kodā, kurš ir ļoti neliela daļa no visa. Lūk tā vieta ir jāoptimizē un jādomā, kā izvairīties no tās izpildīšanas. Tas dos nevis 1% performances pieaugumu, bet gan 2x vai 10x ātrāku programmu.

Optimizēk kodu par 1.01x nav vērts. Bet par 2x gan ir vērts pacīnīties. Optimizējot kodu par 1.01x vairākas reizes neko daudz neiegūsi - (1.01)^n ir mazs skaitlis. Taču 2^n ir liels!

Agrāk es arī cīnījos par katru 1% vai 2% optimizācijas. Tagad esmu sapratis, ka tā ir tikai lieka laika izšķiešana - nav vērts. Labāk ir vairāk veltīt laika struktūras pārdomāšanai un algoritmu optimizācijai nevis nieka vienu procentu optimizēt.

Link to post
Share on other sites

Bubu, ja pasūtītājs negrib atkāpties no savas specifikācijas, ka visi algortmi pat neiziet 10h... tad nu tie 1% ir būtiski.

Pats pašlaik esmu tādā projektā un nākas pa `matiņam plēst ārā`.

 

Cita runa, ja izstrādātājam ir tiesības mainīt šo-to pasūtītaja specifikācijā vai pat biznesā (kopējā procesā).

Link to post
Share on other sites
Nevajag aizmirst, ka cilvēkam ir tikai dabiski kļūdīties. Un ja tu savā koda uzbūvē ļauj iespēju programmētājam kļūdīties, tad viņš noteikti vismaz vienreiz arī kļūdīsies. Tāpēc labāk būvēt kodu tā, lai tādu iespēju ir pēc iespējas mazāk.

 

Nu paga.. Arī ar visu singletonu tāpat var kļūdīties. Var kaut vai aizmirst to instanci paprasīt, un tad brīnīties, kapēc kveriji neiet. Ir visādi "frukti". Ir tādi, kuri uzliks pilnīgu pofigu uz OOP vispār un taisīs paši savas konekcijas, kā sagribēsies. Manuprāt, ka tādiem, kas pamanās saveidot vairākas konekcijas/neizveidot ne vienu vispār nav ko lielos php projektos darīt.

Link to post
Share on other sites
Ir tādi, kuri uzliks pilnīgu pofigu uz OOP vispār un taisīs paši savas konekcijas, kā sagribēsies.

Tādi ir uz līdzenas vietas jāatlaiž :) No galīgiem muļķiem tik tas var glābt...

Var kaut vai aizmirst to instanci paprasīt, un tad brīnīties, kapēc kveriji neiet.

Ja aizmirsīsi, tad dabūsi Fatal error:Call to a member function query() on a non-object in ... line xx. Tā ka ilgi brīnīties nenāksies :)

Link to post
Share on other sites

Tad ir iespējami varianti, atkarībā kā būs realizēta tā db padarīšana :) Godīgi, nesaprotu tavu attieksmi pret paterniem - imho, tie atvieglo dzīvi un stipri palīdz sistematizēt kodu.

P.s. es gan esmu katastrofāls oop piekritējs :D Varbūt tāpēc nesaprotu...

Edited by john.brown
Link to post
Share on other sites

john.brown, nenjem veeraa :), man nav nekas pretii. Vienkaarshi sakairinaaja manus receptorus tas bubu teikums par to, ka shis patterns ljauj developerim neuztraukties vai db ir inicializeeta vai nav. Vaardu sakot - developeris driikst palikt neuzmaniigaaks. Un tad tas visticamaak uz paareejo kodu arii atsauktos.

Link to post
Share on other sites

×
×
  • Create New...