Srodne teme

08.06.2006. Osnove OOP-a
07.02.2004. Razlika izmedju Canona A60 i A70 ???
28.06.2004. Razlika izmedju Java i Java2
12.08.2004. koja je razlika izmedju EPOX-a 8RDA3+ i 8RDA3i
26.02.2005. OOP, kako elegantno izvesti komunikaciju izmedju ..
24.01.2006. Razlika izmedju SD i SD Ultra
28.02.2006. OOP Literatura...
19.05.2006. Problem kod grupisanja u Crystal Reportu
27.03.2007. Razlika izmedju Macintosh i obicnih racunara
12.09.2006. Razlika izmedju C++ i C#

Navigacija

Brisanje liste

Lista poslednjih: 16, 32, 64, 128 poruka.

Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

[es] :: PHP :: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

Strane: 1 2 3 4 5 ... Dalje > >>

[ Pregleda: 31010 | Odgovora: 101 ] > FB > Twit

Autor

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502

+49 Profil

Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{06.05.2010. u 08:14 - pre 181 meseci}

dakipro:Cesto se spominje OOP stil pisanja tako sto se u jednu klasu samo skupe funkcije koje imaju veze sa nazivom klase, i povede se diskusija oko toga da li je to OOP, u ovoj temi cemo pokusati da odrzimo on-topic diskusiju na tu temu, sa novim a i vec postojecim postovima na forumu.

Citat:

mitke013: Naravno, pravi OOP, ne situacije kad programer potrpa gomilu funkcija sa brdom ulaznih parametara u neku klasu.

Mozes objasniti sta znaci ova gore recenica? Klasa mora imati funkcije (metode) sa parametrima, a ti kazes da to nije 'pravi OOP'??

_{[Ovu poruku je menjao dakipro dana 06.05.2010. u 11:34 GMT+1]}

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Odgovor na temu

dakipro
Dalibor Jovic
Web Developer
Bergen, Norway

Moderator
Član broj: 31848
Poruke: 1792
109.106.236.*

Sajt: norway.dakipro.com

+190 Profil

Re: Da li je PHP trziste zasiceno

^{06.05.2010. u 08:28 - pre 181 meseci}

Postoji stil rada gde se recimo sve funckije vezane za usere ubace u users "klasu" nazovi ga tako, ali se svaka funckija koristi pojedinacno, sa ili bez pravljenja objekta. Sto ce reci, postoji objekat $users, i postoje "metode" u tom objektu, i koriste se sa $users->create(); ali se svaka metoda tretira kao funkcija, pa onda to izgleda ovako: $users->create($username, $password, $userId, $currentTime,...) sto se na kraju uopste ne bi razlikovalo od toga da se to poziva i ovako Users::create(...) a to je vec obicna funkcija, kao recimo users_create(...);

Tada je users.class.php samo kontejner za funkcije koje se koriste kao kvazi metode, nema pravog OOP-a, sta vise nema OOP-a uopste, samo postoji objekat i metode. Svaka metoda je nezavisna i uopste nema veze sa objektom (ili je veza veoma veoma mala).

_{[Ovu poruku je menjao Goran Rakić dana 17.06.2010. u 13:13 GMT+1]}

http://norway.dakipro.com/

Odgovor na temu

dakipro
Dalibor Jovic
Web Developer
Bergen, Norway

Moderator
Član broj: 31848
Poruke: 1792
109.106.236.*

Sajt: norway.dakipro.com

+190 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{06.05.2010. u 10:30 - pre 181 meseci}

Zeljkova poruka sa gore pomenutog linka, objasnjenje OOP http://www.elitesecurity.org/t396391-0#2569591

Citat:

mitke013:

OOP nije gomilanje funkcija na jedno mesto pa se to mesto nazove klasom. Objekat moze nesto da uradi, a ne samo da drzi funkcije; za tako nesto moze se koristiti i include fajla koji ce ih drzati. Najjednostavnije objasnjenje: tvoj program je komandir kasarne. Imas klasu vojnik, zastavnik, kapetan.... Tebi kapetan treba da organizuje jedan od visoko-intelektualnih zahteva tipicnih za vojsku; ciscenje piste, skupljanje lisca ili nesto slicno.

Code:

$captain = Captain::getAvailable() ;

Nema parametara. Klasa ce naci slobodnog kapetana tj. onaj koji je trenutno tu i nema zaduzenja.

Code:

$captain->cleanEverything() ;

Opet nema parametara. Kapetan ce dalje da organizuje taj posao. On ce naci slobodne vojnike na slican nacin i podeliti naredjenja. Pritom:

Code:

$soldier_1->cleanLeaves() ;
$soldier_2->cleanRanaway() ;
//itd

Vojniku treba metla; moglo je znaci i ovako:

Code:

$broom = Broom::getAvailable() ;
$soldier_1->cleanLeaves($broom) ;

Ali sto bi kapetan vojniku davao metlu; nije debil, moze i sam da je nadje. Pritom, ako jednog dana se kasarna modernizuje i dobije onaj kompresor sto oduva lisce, komanda vise nije validna. Ako se vratimo u programske vode, to znaci da bi svuda gde kapetan daje vojniku metlu ili nesto drugo, moralo da se promeni. Lakse je nauciti vojnika da se sam snadje:

Code:

class Soldier extends BasicMilitaryUnit
{
  public function cleanLeaves()
  {
    $cleaningDevice = $this->getCleaningDevice() ;
    // ocisti lisce koristeci $cleaningDevice
  }

  protected function getCleaningDevice()
  {
    return Broom::getAvailable() ;
  }
}

Static metode je uvek lakse prepraviti nego dinamicke. Uvek ih je manje, a ako je protected, automatski znas da se ta metoda ne poziva ni sa jednog drugog mesta i da ne treba da juris kroz ceo program da proveris pozive.

Sve ove klase nasledjuju BasicMilitaryUnit klasu jer je za svo vojnicko osoblje identicno da treba da jedu, srede ujutru, obuju se, izadju na smotru itd. Da ne bi to isto pisali za svakog, lakse je staviti na jedno mesto.

Jos jedan primer nasledjivanja; u vojsci se belezi skoro svaki obavljeni posao. Posto to programer zna od pocetka, u svakoj metodi koja zahteva izvestaj na kraju ce pozvati:

Code:
  public function cleanLeaves()
  {
    $cleaningDevice = $this->getCleaningDevice() ;
    // ocisti lisce koristeci $cleaningDevice

    $this->writeReport('Ocistio sam lisce') ;
  }

a BasicMilitaryUnit ima metodu:

Code:

abstract class BasicMilitaryUnit
{
  protected function writeReport($report)
  {
    $name = $this->getName() ;
    $rank = $this->getRank() ;
   // snimi izvestaj koristeci tekst raporta, za ime i cin se metoda sama snasla
  }
}

OK? Nije; na ovaj nacin klasa vojnik prosledjuje fixni tekst. Ako se taj tekst negde snima (baza) i jednog dana tekst promeni, baza ce imati razlicite tekstualne vrednosti za isti posao. Bolje je:

Code:
  public function cleanLeaves()
  {
    $cleaningDevice = $this->getCleaningDevice() ;
    // ocisti lisce koristeci $cleaningDevice

    $this->writeReport(Report::LEAVES_CLEANED) ;
  }

Sad se koristi konstanta iz klase Report. Neka je vrednost const LEAVES_CLEANED = 1 ; Mi ce tu vrednost da snimimo u bazu; na osnovu tog broja se tekst raporta moze menjati bez problema, lokalizovati itd.

Koliki posao oko obicnog lisca :)

_{[Ovu poruku je menjao Goran Rakić dana 17.06.2010. u 13:14 GMT+1]}

http://norway.dakipro.com/

Odgovor na temu

Miroslav Ćurčić
ex mVeliki
Novi Sad

Član broj: 19034
Poruke: 1118
*.dynamic.isp.telekom.rs.

+19 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{06.05.2010. u 11:16 - pre 181 meseci}

Citat:

Postoji stil rada gde se recimo sve funckije vezane za usere ubace u users "klasu" nazovi ga tako, ali se svaka funckija koristi pojedinacno, sa ili bez pravljenja objekta

Ovo se zove "enkapsulacija" ( ala mrzim ove komplikovane tudjice :) ) i ovo jeste vrsta OOP-a.

To sto smo time iskoristili samo 10% onoga sto OOP pruza je sasvim druga stvar. Ako mi neko pokaze svoj projekat koji koristi samo enkapsulaciju i tvrdi da je koristio OOP, necu mu nista prigovoriti, jednostavno nisam toliki cistunac.

_{"The quieter you become, the more you are able to hear."}
Blog | PowerCMS

Odgovor na temu

mitke013
As Divljine
Freelancer

Član broj: 231934
Poruke: 338
195.252.79.*

+34 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{06.05.2010. u 13:03 - pre 181 meseci}

Dakipro je u pravu. Dopunio bih njegov primer sledecom idejom; npr. klase IntField i TextField bi nasledjivale abstract class BaseField() . BaseField() bi imala metodu isValid() koja bi iz child elemenata pozivala protected metodu validate() i vracala odgovor da li je polje validno ili ne. BaseField() bi takodje imalo metodu

Code:

abstract class BaseField()
{
abstract protected function validate();
}

na taj nacin, ako je programer zaboravio da kreira metodu validate() u child klasi, PHP bi ga upozorio na to. Ovo je samo jos jedan primer zasto je OOP mnogo bolji od proceduralnog koda; nadogradnja je zaista izuzetno jednostavna.

Opet primer klasa mainDbObject() bi takodje imala metodu isValid() koja bi za sva polja skupljenih iz $this->initializeField metode, uradila validaciju i greske skupila u neki niz. Programer bi onda mogao sledece:

Code:

$user = new User() ;
$user->setValues($_POST) ;
if ( !$user->isValid() ){
    $errorStack = $user->getErrors() ;
    // ponovo prikazi formu zajedno sa greskama iz $errorStack niza
} else {
    $user->save() ;
    // prikazi poruku da je uspesno snimljen novi User
}

[offtopic]
Dakipro, da li koristis Doctrine ORM?

_{[Ovu poruku je menjao Goran Rakić dana 16.06.2010. u 01:33 GMT+1]}

Odgovor na temu

dakipro
Dalibor Jovic
Web Developer
Bergen, Norway

Moderator
Član broj: 31848
Poruke: 1792
109.106.236.*

Sajt: norway.dakipro.com

+190 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{06.05.2010. u 13:44 - pre 181 meseci}

Ne doctrine, ovako su me poducile starije kolege u firmi (Bratislav Dimitrijevic) kao jedan dobar pristup sa varijacijama na temu.
Do tada sam i ja radio sa "enkapsulacija" kako kaze Miroslav, tek sam onda uspeo da ustvari uvidim konkretnu upotrebu silne teorije oko nasledjivanja i ostalih oop ideja.
Sad, odakle je ideja, nisam siguran, i nije mi se svidela bila instant jer zahteva dooosta projektovanja u startu, pogotovu kad si ucio manje-vise proceduralno da razmisljas, ali sada kad pogledam prednosti, meni je ovo prava stvar.

http://norway.dakipro.com/

Odgovor na temu

Mister_rap
SE at Viacom

Član broj: 8822
Poruke: 2540
*.dynamic.sbb.rs.

Jabber: mister_rap@jabber.com

+21 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{06.05.2010. u 14:44 - pre 181 meseci}

Citat:

Naravno, pravi OOP, ne situacije kad programer potrpa gomilu funkcija sa brdom ulaznih parametara u neku klasu.

Aj prvo mali back na prethodnu temu...

Ko je programirao proceduralno, zna koje su mane i uslovno receno prednosti istog.
Ako nisi recimo sibao u C-u, nema smisla da previse pricamo o ovome.

Nego gomila softvera je napisana proceduralno, i to kao sto sam ranije rekako nikako ne znaci da je softver lose projektovan, necitljiv i tako dalje.
Treba u razmatranje u tim situacijama ukljuciti niz faktora, vrijeme kad se neka aplikacija razvijala prvenstveno, kao i sam PHP kao jezik posto je ovo PHP forum jelete a PHP ako se ne varam pocinje da uvodi OO od verzije 4.

Postoji citava oblast koja se bavi dizajnom softvera, i koja je prilicno interesantna, stoga koga zanima ako nije citao neke knjige na tu temu neka baci pogled malo...

Sto se tice enkapsulacije nema nista lose u istoj, NAPROTIV, ako je koristis normalno, dakle sasvim validna stvar i prilicno prirodno "razmisljanje" za neke jezike. Ideja iste je mnogo drugacija nego njena najcesca primjena u OOP-u.

OOP danas je uglavnom sveden na pravilnu upotrebu design patterna, jer je za web MVC recimo totalno prirodna stvar.
Sa druge strane postoji taj problem DBM sistema, koji jelte ne cuvaju objekte, pa otuda potreba za OR mapperima tako da po mom misljenju tu ima dosta mjesta za inovacije, tj. vec sam probao neke od "njih" i jako sam zadovoljan prvenstveno samom idejom.

U PHP-u ljudi na tom polju najcesce prave greske, a da je mozda u pozadini neka druga tehnologija mozda ne bi uopste gledali ovaj kod i spominjali Doctrine :)

Koga zanima neka baci malo pogled na MongoDB.

Ps.
Sto se tice Doctrine-a, ja ga koristim odavno, prirodno je kad koristis hibernate da i u php-u koristis nesto slicno. Ali ima dosta razloga, zasto u nekim situacijama koriscenje OR mappera nije dobra solucija bez obzira na to koliko pojednostavljuje zivot programeru :D

Odgovor na temu

kazil
Robert Bašić
Full time PHP dev :)
Bačka Topola - Novi Sad

Član broj: 120044
Poruke: 686
*.mbb.telenor.rs.

Jabber: robertbasic@elitesecurity.org
ICQ: 446475288
Sajt: robertbasic.com

+2 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{06.05.2010. u 23:20 - pre 181 meseci}

Zar nije umesto one abstract klase interface namenjen za takve stvari? :) http://php.net/manual/en/language.oop5.interfaces.php

_{[Ovu poruku je menjao Goran Rakić dana 16.06.2010. u 01:34 GMT+1]}

Odgovor na temu

kazil
Robert Bašić
Full time PHP dev :)
Bačka Topola - Novi Sad

Član broj: 120044
Poruke: 686
*.mbb.telenor.rs.

Jabber: robertbasic@elitesecurity.org
ICQ: 446475288
Sajt: robertbasic.com

+2 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{07.05.2010. u 00:05 - pre 181 meseci}

Malo da se nadovezem na onaj post sa vojnicima i liscem... Odmah u pocetku da razjasnim da ne smatram to losim nacinom, nego bih ja licno to drugacije napisao :)

Moj problem sa tim pristupom je $captain->cleanEverything(); meni ova metoda govori da ce kapetan da ocisti celu bazu, sto nije tacno. Kapetan moze da sakupi vojnike, da dodeli zadatke i da raspusti vojnike (je l' se tako kaze? sluzio sam civilno :P)

Na primer:

Code (php):

<?php

$captain = new Captain();

$duties = new Duties();

$soldier = new Soldier();

$captain->setServingSoldier($soldier); // ovo moze i drugacije, npr: new Captain(new Soldier());

$captain->assignTask($captain->getServingSoldier(), $duties->getNextTask());

$captain->getServingSoldier()->doTask();

while(!$captain->getServingSoldier()->isTaskFinished()) {

    $captain->yell();

}

$captain->releaseSoldier();

Tacno vidim ko je kome sta dodelio i ko je sta uradio - kapetan je postavio dezurnog vojnika, zadao mu zadatak, dok vojnik ne odradi zadatak, dotle se kapetan dere, posle je slobodan.

Opet napomena, na ovakav neki nacin bih ja licno resio problem ciscenja kasarne, nije jedini nacin, nije tacan nacin, svaki problem ima vise resenja, samo je potrebno naci najbolje resenje za dati problem (previse filozofiram za 1 ujutro, je l'? :P)

Odgovor na temu

mitke013
As Divljine
Freelancer

Član broj: 231934
Poruke: 338
195.252.79.*

+34 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{07.05.2010. u 00:55 - pre 181 meseci}

Citat:

kazil
Opet napomena, na ovakav neki nacin bih ja licno resio problem ciscenja kasarne, nije jedini nacin, nije tacan nacin, svaki problem ima vise resenja, samo je potrebno naci najbolje resenje za dati problem (previse filozofiram za 1 ujutro, je l'? :P)

Evo ti malo filozofije za pola dva ujutru :)

Stvar ukusa, ali mi se tvoje resenje ne svidja. Bez ljutnje. Linija

Code:
$captain->assignTask($captain->getServingSoldier(), $duties->getNextTask());

cini kod necitkim i ima 2 parametra. Ja zaista ne volim parametre; klasa se sama snalazi kako zna i ume.

Druga stvar:
tvoj program je komandant kasarne, bog i batina za sve. On kad kaze kapetanu da se sve ocisti, njega zaista ne zanima kako ce to biti uradjeno. Sto se komandanta tice, kapetan moze i sam da je ocisti, njega samo interesuje da posao bude obavljen. Detalji ga ne zanimaju; vojska (prava) zaista tako funkcionise i zato ima jako malo propusta. Zamisli da komandant brine o nabavci toalet papira (zadatak cate), emotivnim problemima Laze iz izvidjaca (zadatak psihologa), pokvarenoj hrani (dezurni oficir menze) i buvama iz cebadi (problem se ignorise)...

Ako ti u programu na isti nacin dodelis zadatke, program je daleko pregledniji. Dok tvoja verzija ima ~10 linija i tvoj komandant mora da se brine cak i o pojedinacnom vojniku (sto komandant NIKAD ne radi), moja verzija ima samo

Code:

$captain = Captain::getAvailable() ;
$captain->cleanEverything() ;

Sto je ipak daleko preglednije. Ili cak perverzija:

Code:

Captain::getAvailable()->cleanEverything() ;

Citat:

Tacno vidim ko je kome sta dodelio i ko je sta uradio - kapetan je postavio dezurnog vojnika, zadao mu zadatak, dok vojnik ne odradi zadatak, dotle se kapetan dere, posle je slobodan.

Tvoj kontroler (komandant) zaista nema potrebe da zna koji je vojnik ucestvovao u ciscenju; tvoj primer bi onda ukljucio da komandant licno mora da isporuci metlu tom vojniku. Ako bas mora da zna ko su oni kako bi ih nagradio, uvek mozes ovo:

Code:

$captain->awardBestSoldiers(2) ;

gde je parametar koliko vojnika da dobije nagradu, default vrednost je da kapetan sam odluci. Kapetan ce sam odluciti koliko nagradnih dana ce podeliti tim vojnicima na osnovu drugih parametara; aljkavosti, drzanju, izvrsavanju drugih zadataka itd...

Nadam se da me razumes. Ocekujem tvoj odgovor za moje jutarnje razgibavanje mozga :)

Citat:

Zar nije interface namenjen za takve stvari? :) http://php.net/manual/en/language.oop5.interfaces.php

Da, u pravu si, interface je najbolja stvar za ovako nesto.

Odgovor na temu

kazil
Robert Bašić
Full time PHP dev :)
Bačka Topola - Novi Sad

Član broj: 120044
Poruke: 686
*.static.kdsinter.net.

Jabber: robertbasic@elitesecurity.org
ICQ: 446475288
Sajt: robertbasic.com

+2 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{07.05.2010. u 09:09 - pre 181 meseci}

Po meni je ta linija bas zbog toga citkija, zato sto prima parametre :) tacnije, jer po imenu metode tacno znam sta ta metoda radi i nad kojim elementima radi to sto radi. 2-4 parametra je po meni jos ok, ako prima vise, mozda metoda zeli previse da uradi :)

Mozda moj nacin nije najbolje objasniti na primeru kasarne, jer u pravoj vojsci stvarno kapetana ne interesuje ko ce i kako da ocisti, vec samo da se sve cakli. Briga kapetana da li vojnik ima metlu ili nema. Moja metoda, ako joj treba nesto da izvrsi zadatak i to nesto joj nedostaje, baca Exception, a pozivajuci kod se stara da uhvati taj Exception i dalje odlucuje sta treba da se uradi. Vojnik ako baci Exception moze samo da nagrabusi :D

Uglavnom, idem principom da jedna metoda radi jedan zadatak (iako mi to ne polazi uvek za rukom, nisam ja tamo neki guru, jel, i dalje ucim :)). Ako vojnikova metoda clean() mora da se brine i o nabavku opreme za ciscenje, da odluci da li mu treba metla ili cetka za wc, da se raspita gde treba to da nabavi, eventualno da ceka dok se neka oprema ne oslobodi, pa tek onda da ocisti... Jeste kod koji to poziva citkiji, ali pozvani kod je vec... Ugh. Previse if-ova :)

Prednost ovog nacina: unit testing. Tacno mogu zasebno svaki deo koda da testiram bez da moram da brinem o jos malom milionu delova koda koji su zapravo samo sakriveni unutar metode koju testiram da bi test prosao ili pao i usput da testiram kako vojnik ocisti lisce ako mu dam metlu ili ako mu dam duvalicu za lisce.

Predlazem da se pogleda predavanje Miško Hevery-a, mnogo covek zna znanje: http://robertbasic.posterous.c...k-series-presents-oo-design-fo (mislim da bas u ovom videu prica o naplati sa kreditnim karticama, koji je odlican primer zasto treba napraviti separation of concerns).
Meni su licno njegova predavanja najvise promenili nacin razmisljanja i pisanja koda (ne zato sto je on rekao da tako treba da se radi, nego sam uvideo prednosti takvog nacina).

Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6340

Sajt: pedja.supurovic.net

+1585 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{07.05.2010. u 13:35 - pre 181 meseci}

@mitke013: Iako se generalno slazem sa tobom, ipak ne bih isao dotle da mi broj parameterab due kriterijum dali je neki OOP dobar ili nije. Odredjena funkcija da bi odradilaposao treba odredjen broj ulaznih parametara. Ako te parametre moze sama da procita, onda ih ne treba navoditi.

Ovaj primer sa $kapetan->ocistiSve() ne pokazuje da je broj parametara bitan faktor. To je funkcija koja samo maskira gomiluprocesa koji mroaju da se obave. ciscenej svega podrazuemva ciscenje mnogo cega a to ukljucuje i razlicita sredstva za ciscenje, broj ljudi koji treba da to rade, razlicite objekte ciscenja koji se ciste na siti nacin, i slicno. Za svaki taj razlicit posao ciscenja mora postojati neki poseban metod koji ga obavlja i svaki daj metod, opet, ima neke svoje ulazne parametre.

Sve u svemu, nakupi se tu mnogo ulaznih parametara, samo treba pameno proceniti do kojih metod moze sam da ddoje a koji mu se moraju proslediti spolja. Pri tom, broj parametara zavisiod funkcije koju metod obavlja a ne od toga dali se to nekome svidja, cini mu se citkijim ili smatra daje to OOP.

Upravo je moc OOP pristupa u parametrizaciji poslova tako da jedan isti metod moze da radi vise poslova na osnovu parametara koji mu se prosledi. Recimo u ovom primeru metod $kapetan->ocistiSve() bi recimo mogao da unutar sebe kreira objekat $cistac koji bi u stvari znao da cisti sve, a cisti ono sto mu se kaze - kroz parametre. $vojnik ne mora da zna da cisti, vec je dovoljno da zna da upotrebi $cistac pa ce ocistiti sve sto mu bude naredjeno a $cistac ume.

_{[Ovu poruku je menjao Goran Rakić dana 16.06.2010. u 01:37 GMT+1]}

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Odgovor na temu

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502

+49 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{08.05.2010. u 14:17 - pre 181 meseci}

Nisam neki guru OOP-a, koristim ga mozda i manje ,sticajem okolnosti, nego sto bih htio ali ne vidim i dalje opravdanje za koristenje metoda bez parametara zbog toga sto 'to nije pravi OOP'. Ne kazem da sam u pravu, ali bih htio dobiti kakve reference (uputstva, dokumente) gdje je receno da se to mora izbjegava.
Mislim da je OOP u Java jako dobro rjesen ali tako jako puno objekata ima more metoda koje su override-vane sa razlicitim parametrima i tako dozvoljavaju da zapravo jedan metod radi zapravo isti posao ali u razlicitim okolnostima.

To sto ce se metoda sama snaci moze znaciti i rasipanje resursa, u smislu gore pomenute vojske. Recimo:
- Kapetan trazi da je kasarna obrisana
- Klasa vojnik ima metod 'clean' ali ne zna cime (jer nema parametara.
- Vojnik instancira novu metlu (pod uslovom da postoji u bibliotekama)
- Ocisti, oslobodi metlu
- Kapetan pogleda i kaze 'nije dobro, ajd ponovo'
- Vojnik ponovo instancira metlu, ocisti , oslobodi
...

Ovde vidim nekoliko nedostataka:
- zar ne bi bilo bolje prije ciscenja instancirati metlu i drzati je postojecom dok ne budemo sigurni da nam vishe ne treba.
- metla negdje mora postojati definisana, sta se desava ako vojnik ne moze pronaci metlu - moras napraviti okruzenje, bez toga da znas sve detalje (jer nemas parametara) i nadati se da ce ta metoda raditi. Ne saljes joj parametre pa moras pratiti exceptione i gledati sta joj fali.

Mislim da je ovde i (moj, subjektivni) trip oko toga 'drzati stvari pod kontrolom'. Jer ako ja nekoj metodi posaljem 'ocisti' ja ne znam kako ce ona ocistiti i cime ce, ali znam/nadam se da ce posao biti zavrsen. Ali ako joj recimo posaljem 'ocisti metlom i vrati je kad zavrsis' znam da sam joj obezbjedio sve potrebno i da ce zavrsiti posao.
Kazem opet, to je sve IMHO, ucim i naucicu sta je bolje ali argument 'to ti nije pravi OOP jer ima 3 parametra' mi ne pije bas vodu.

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Odgovor na temu

mitke013
As Divljine
Freelancer

Član broj: 231934
Poruke: 338
195.252.79.*

+34 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{08.05.2010. u 16:43 - pre 181 meseci}

Citat:

misk0: Nisam neki guru OOP-a, koristim ga mozda i manje ,sticajem okolnosti, nego sto bih htio ali ne vidim i dalje opravdanje za koristenje metoda bez parametara zbog toga sto 'to nije pravi OOP'. Ne kazem da sam u pravu, ali bih htio dobiti kakve reference (uputstva, dokumente) gdje je receno da se to mora izbjegava.
Mislim da je OOP u Java jako dobro rjesen ali tako jako puno objekata ima more metoda koje su override-vane sa razlicitim parametrima i tako dozvoljavaju da zapravo jedan metod radi zapravo isti posao ali u razlicitim okolnostima.

Ne znam javu, samo sam vrlo malo citao o njoj, ali sam ukapirao da su sve te klase multi-praktik. Zato i moraju da imaju mnogo parametara jer ta klasa zaista ne moze da ti procita misli. Ok, ovo je neko moje vidjenje stvari, mozda gresim jer nisam radio u javi, ali me podseca na programiranje u c-u; svaka funkcija operativnog sistema, cak i ispis obicnog teksta, se prilicno zakomplikuje.

Kod php-a, ti znas unapred da ce vojnik da ocisti lisce, pusku, ponekad mozda i da puca... Da da, vojska nije samo ciscenje i pranje

Zato ti i nisu potrebni ulazni parametri; procitaj opet moje objasnjenje i vidi sa koliko malo linija koda ti zavrsavas posao. protected metoda je ta koja ce da se pobrine oko nabavke metle.

Vrlo je bitno da public metode nemaju parametre ili imaju jako malo. Odrzavanje i prosirivanje programa je mnogo lakse jer ce ti API biti nepromenjen. Zamisli da imas metodu sa npr. 3 parametra koja se poziva sa vise mesta; ti prosiris tu metodu, automatski moras da menjas kod SVUDA gde se ta metoda poziva. Da li me sad razumes?

Citat:

- Klasa vojnik ima metod 'clean' ali ne zna cime (jer nema parametara.

Ovo sam vec objasnio.

Citat:

- Vojnik instancira novu metlu (pod uslovom da postoji u bibliotekama)

Class Broom ce da postoji u svakom slucaju, bez obzira da li ce vojnik sam da je uzme ili kapetan da mu je da.

Citat:

- Ocisti, oslobodi metlu

I to vojnik sam radi. U pravoj vojsci (ne civilnoj) niko nikome nije mama pa da mu daje metlu, ciste carape, ociscenu pusku itd. Vojnik mora sam da se snadje, nema tamo mame koja ce sve da radi za njega. Zbog tog nacina rada, u vojsci skoro nikad nema ispada.
Drugo; tom podelom rada, tacno se zna ko je pogresio.

Citat:

- Kapetan pogleda i kaze 'nije dobro, ajd ponovo'
- Vojnik ponovo instancira metlu, ocisti , oslobodi
...

Kapetana samo interesuje da posao bude obavljen. Sto se njega tice, vojnik moze i cetkicom za zube da ocisti lisce. Ali.... ovo je ipak programiranje; ako ces ti u kontroloru/action klasama (prouci MVC) da radis sve to sto u stvari treba metode da rade... pa gde je tu onda OOP?

Citat:

Ovde vidim nekoliko nedostataka:
- zar ne bi bilo bolje prije ciscenja instancirati metlu i drzati je postojecom dok ne budemo sigurni da nam vishe ne treba.
- metla negdje mora postojati definisana, sta se desava ako vojnik ne moze pronaci metlu - moras napraviti okruzenje, bez toga da znas sve detalje (jer nemas parametara) i nadati se da ce ta metoda raditi. Ne saljes joj parametre pa moras pratiti exceptione i gledati sta joj fali.

Zasto vojnik ne bio nasao metlu? new Broom() ce uraditi to za tebe.

Citat:

Mislim da je ovde i (moj, subjektivni) trip oko toga 'drzati stvari pod kontrolom'. Jer ako ja nekoj metodi posaljem 'ocisti' ja ne znam kako ce ona ocistiti i cime ce, ali znam/nadam se da ce posao biti zavrsen. Ali ako joj recimo posaljem 'ocisti metlom i vrati je kad zavrsis' znam da sam joj obezbjedio sve potrebno i da ce zavrsiti posao.
Kazem opet, to je sve IMHO, ucim i naucicu sta je bolje ali argument 'to ti nije pravi OOP jer ima 3 parametra' mi ne pije bas vodu.

To i jeste poenta; tebe ne zanima kako ce stvar biti obavljena, sve dok je ona obavljena. Ako izbacimo vojsku iz price, razmisljaj ovako: tvoj program i njegove klase imaju neki API. Ako metode nemaju parametre, API se nece narusiti. Ako dodas brdo parametara, nikad neces zavrsiti program, API nije stabilan i niko ziv se nece snaci u tvom programu.

Ali ako dodajes samo protected metode, API je i dalje isti. Nadam se da me razumes; objekat moze nesto da uradi, ne samo da drzi metode. Enkapsulacija je i dalje proceduralni kod koji se ponavlja i ponavlja i ponavlja.... cemu to?

Ako ti ne ide ovo, probaj sledece; napisi neki program koji ce slediti moju logiku. Koliko god te vuklo, odupri se tome da metode imaju parametre. Kad zavrsis kod, videces da sam bio u pravu.

U medjuvremenu, pogledaj onaj video klip sto sam postovao; jeste kvalitet los, ali ces videti prednosti mog nacina rada.

Odgovor na temu

misk0
.: Lugano :. _.: CH :.

SuperModerator
Član broj: 634
Poruke: 2824
*.adsl.ticino.com.

ICQ: 46802502

+49 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{08.05.2010. u 23:47 - pre 181 meseci}

Citat:

mitke013:Ne znam javu, samo sam vrlo malo citao o njoj, ali sam ukapirao da su sve te klase multi-praktik. Zato i moraju da imaju mnogo parametara jer ta klasa zaista ne moze da ti procita misli. Ok, ovo je neko moje vidjenje stvari, mozda gresim jer nisam radio u javi, ali me podseca na programiranje u c-u; svaka funkcija operativnog sistema, cak i ispis obicnog teksta, se prilicno zakomplikuje.

Kod php-a, ti znas unapred da ce vojnik da ocisti lisce, pusku, ponekad mozda i da puca... Da da, vojska nije samo ciscenje i pranje Zato ti i nisu potrebni ulazni parametri; procitaj opet moje objasnjenje i vidi sa koliko malo linija koda ti zavrsavas posao. protected metoda je ta koja ce da se pobrine oko nabavke metle.

Vrlo je bitno da public metode nemaju parametre ili imaju jako malo. Odrzavanje i prosirivanje programa je mnogo lakse jer ce ti API biti nepromenjen. Zamisli da imas metodu sa npr. 3 parametra koja se poziva sa vise mesta; ti prosiris tu metodu, automatski moras da menjas kod SVUDA gde se ta metoda poziva. Da li me sad razumes?

Objektni pristup problemu u sustini ne bi trebao da se razlikuje od jezika do jezika. Bar mislim..
Java (a ne samo Java) radi method overloading, to znaci imas metode:
- clean()
- clean(metla)
- clean(aspirator)
...
Znaci na osnovu poslatih (ili ne) parametara poziva se razlicita metoda, a to je za korisnika te klase poprilicno transparentno. I uglavom unutrasnja struktura se svodi na jednu kljucnu metodu koja radi posao ali ima tone parametara i kad ti recimo pozivas clean() instancira metlu i zove clean(metla) metodu. Dobijas veliki code reusability, smanjujes greske i znas sta se radi.
Mozes clean metodu pozvati sa i bez parametara, mozes je sutra prosirivati sa novim parametrima recimo clean(metla, koliko_puta) i neces narusiti backward compatibility.
Moguce je to koristiti i u PHPu (od verzije 5), ali nije bas 'fino uradjeno' vec moras da malo 'pletes' i da koristis magic methods. Dinke je napisao dobar clanak o tome

Citat:

Class Broom ce da postoji u svakom slucaju, bez obzira da li ce vojnik sam da je uzme ili kapetan da mu je da.

Gdje postoji? U drugoj biblioteci. Sta ako je nisi stavio dostupnom i klasa clean je trazi i ne dobija i onda ti salje exception. Sta ako ja hocu crnu metlu a ne bijelu, ne zove se Broom, vec NewBroomUltra..? Ako metod clean(metla) dobija parametar kao alat, tu je moja odgovornost da m usaljem alat koji ima metod 'doCleaning', a od kojeg proizvodjaca, koje boje, ja mislim o tome.

Objekt Metla mora biti dostupan u okruzenju i ako ga nema metod clean nece moci uraditi nista. A ako ja, prije nego pozovem vojnik->clean(metla) instanciram objekat metla = new metla(); znacu sigurno da ce biti i cime ociscena kasarna.

I dalje mi nisi dao odgovor: gdje pishe da public metodi ne smiju imati (da nije preporucljivo) vishe od jednog parametra? PHP nije izmislio OOP pristup i uveo ga je tek prije par godina, tako da i nije neka referenca.

_{[Ovu poruku je menjao Goran Rakić dana 17.06.2010. u 13:19 GMT+1]}

:: Nemoj se svadjati sa budalom, ljudi cesto nece primjetiti razliku ::

Odgovor na temu

deerbeer
Beograd

Član broj: 174418
Poruke: 1189
*.mbb.telenor.rs.

+395 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{09.05.2010. u 08:55 - pre 181 meseci}

Citat:

Objektni pristup problemu u sustini ne bi trebao da se razlikuje od jezika do jezika. Bar mislim..
Java (a ne samo Java) radi method overloading, to znaci imas metode:
- clean()
- clean(metla)
- clean(aspirator)
...
Znaci na osnovu poslatih (ili ne) parametara poziva se razlicita metoda, a to je za korisnika te klase poprilicno transparentno. I uglavom unutrasnja struktura se svodi na jednu kljucnu metodu koja radi posao ali ima tone parametara i kad ti recimo pozivas clean() instancira metlu i zove clean(metla) metodu. Dobijas veliki code reusability, smanjujes greske i znas sta se radi.

Mozes cak da iskoristis polimorfizam , da clean metoda prihvata samo jedan parametar i da postignes isti efekat
a to je da metoda prihvati apstraktni ili bazni objekat alatke za ciscenje , tako da neka njena override metoda
ce odraditi posao za svaku vrstu alatke za ciscenje .

A kasnije je lakse odrzavanje koda , ne moras dodati novu overload metodu za ciscenje (clean() ),
vec napises novu klasu alatke sa override metodom koja nasledjuje baznu i prosledis je kao parametar clean metodi.
A dodatni parametri za ciscenje (ako su potrebni) mogu se proslediti konstruktoru tog novog objekta alatke .

Viva lollapalooza

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{09.05.2010. u 12:49 - pre 181 meseci}

Da probam da se dotaknem nekih stvari koje ste pomenuli u temi, dosta skacete naokolo pa mozda nisam stigao da pohvatam sve detalje:

- "Naravno, pravi OOP, ne situacije kad programer potrpa gomilu funkcija sa brdom ulaznih parametara u neku klasu."
Evolucijom programiskih jezika i sto je najgore apsrtakcijom dosta se zaboravilo "ZASTO" su uopste OOP jezici preuzeli primat nad proceduralnim. Back to the basics, OOP je dobar ne zato sto je dobar programerima vec zato sto je dobar projektantima, omogucava modelovanje entiteta i interakcija izmedju entiteta tokom vremena i omogucava projektantu da programeru prenese model u tom obliku koji ce bez velikih operativnih problema biti prenesen u kod. Bez OOPa skoro ceo UML mozes da bacis u kantu. U tom konceptu klasa kao drzac statickih metoda nije OOP jer ne predstavlja entitet, entitet istina definise klasa ali entitet moze da postoji samo kao instanca. Trpanje statickih funkcija u neku klasu moze da pomogne programeru za bolje citanje sorsa ili jednostavno mora da se uradi tako jer standalone funkcije nisu dozvoljene (kao u CLRu) ali nisu OOP jer nemas instancu (objekat). Isto tako pretvarati staticke metode u instance metode iako ne menjaju state instance samo da bi bilo OOP je "varanje"

i to nije enkapsulacija.

- Interfejs kao OOP
Zaboravljate da je spisak public elemenata klase UVEK default interfejs i kao takav ispunjava modelovani contract. Instanca klase je njen state + njen default interface stoga su interfejsi kao OOP pojam nezaobilazni. Medjutim, dodatni interfejsi kao interfejsi postoje da bi se omogucilo da jedna klasa apsktraktno servira vise contracta koristeci enkapsulaciju, nista manje, nista vise.

- parametrizacija metoda.
Ovo je malo tricky pitanje i vise je vezano za modeling nego za coding praksu. Vas primer sa kapetanom i vojskom je viseznacan iz prostog razloga sto vam je model nekompletan i zbog toga postoji ambiguity oko toga ko, kako i cime i treba da cisti (sto btw u vojsci predstavlja smrtni greh

). Ako biste recimo model poceli od kasarne i uveli sve zakljucno sa sredstvima u model onda bi kroz instancijaciju oficiria, vojske, prostorija, sredstava, itd u trenutku ciscenja ZNALI kroz objektnu hijerarhiju koji kapetan komanduje kojom vojskom, ko je zaduzen za sredstva i koja i koliko sredstava postoji. Onda moze da se uradi commander.getClosestCaptian().CleanAll() ili slicno i tu onda implementacija Clean() moze da enumerise raspolozive vojnike, delegira naredjenje za akvizicju sredstava i obavljanje posla. Sa druge strane implementacija CleanAll() ce verovatno morati u svom toku da koristi parametre u komunikaciji sa vojskom. Isto tako, vojna doktrina nalaze da se izdavaoc obavesti o izvrsenom naredjenju, ako kapetan ima vise nadredjenih kako ce znati ko je izdao naredjenje i kome da raportira? U realnosti identifikacija se obavlja implicitnim prepoznavanjem lika/glasa komandujuceg oficira, u OOP modelu nema implicitnog, tako da ostaje pitanje kako kapetan da zna i najlakse resenje bi bilo da CleanAll ima potpis CleanAll(Officer orderIssuingCommander)

Bez tog modela sve je podlezno razlicitim interpretacijama koje ste i izneli, moze ovako a moze i onako i po meni je rasprava koji je bolji bespredmetna jer nijedan ne valja zato sto model ne valja.

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

deerbeer
Beograd

Član broj: 174418
Poruke: 1189
*.mbb.telenor.rs.

+395 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{09.05.2010. u 13:25 - pre 181 meseci}

Citat:

Instanca klase je njen state + njen default interface stoga su interfejsi kao OOP pojam nezaobilazni.

E sad je skakljivo pitanje koliko je taj "state" objekata klase stvarno upotrebljiv u "stateless" protokolima

Viva lollapalooza

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{09.05.2010. u 13:38 - pre 181 meseci}

Ko jos pravi stateless web aplikacije :)
Protokol je stateless ali su web aplikacije itekako statfull, peko DOMa, state-a input polja do serijalizovanih server side stateova. To nije izgovor ;)

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

mitke013
As Divljine
Freelancer

Član broj: 231934
Poruke: 338
195.252.79.*

+34 Profil

Re: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

^{09.05.2010. u 13:47 - pre 181 meseci}

Citat:

misk0: Nije klasa clean, vec je metod clean koji trazi klasu /objekat Metla koja je definisana negdje van objekta vojnik. Objekt Metla mora biti dostupan u okruzenju i ako ga nema metod clean nece moci uraditi nista. A ako ja, prije nego pozovem vojnik->clean(metla) instanciram objekat metla = new metla(); znacu sigurno da ce biti i cime ociscena kasarna.

Ne bih htio da se ljutis i pizdis, nema potrebe, diskutujemo, ja mozda nesto ne znam i trazim da mi se objasni.

@deerbeer: da, i to je rjesenje recimo.

Ok, nisi me razumeo. Probaj ovo da zamislis:

u tvom programu, na 12 mesta se poziva metoda metoda $soldier->cleanLeaves($broom) ;
Ovo je samo primer i lako se moze desiti u normalnom programiranju da se toliko puta, pa i vise, pozove neka metoda.

Elem; umesto parametra $broom koji je instance NEKE metle (nije vazno koje), ti zelis da vojnik sada ocisti lisce koristeci kompresor. To znaci da ces 12 puta morati da menjas gornju liniju u $soldier->cleanLeaves($leafBlower) ;

Sporo suvise i veeeeoma lako moze da ti neki poziv promakne.

Al ajde da se primeni moja logika; vojnika naucis da uzme sam neophodni alat; jedna metoda se samo menja, ne 12++ poziva.

_{[Ovu poruku je menjao Goran Rakić dana 16.06.2010. u 01:41 GMT+1]}

Odgovor na temu

[es] :: PHP :: Razlika izmedju grupisanja funkcija u klasu i pravilnije OOP programiranje.

Strane: 1 2 3 4 5 ... Dalje > >>

[ Pregleda: 31010 | Odgovora: 101 ] > FB > Twit

Srodne teme

28.03.2007. Razlika izmedju C i C++
25.04.2007. Razlika Izmedju Jsp I PHP
27.08.2007. HITNO: Razlika izmedju RequestDispatcher i sendRe..
25.09.2007. Java pocetnik i unos podataka sa tastature
01.12.2007. OOP pitanje (Jel sad ima 15 karaktera?)
19.01.2008. Kakva je razlika izmedju Mikrotik rutera i rutera..
24.07.2009. Da li je pravilno izgovarati/pisati: SrBski ili S..
14.10.2009. Do koje granice nije previše objekata?

Navigacija

Lista poslednjih: 16, 32, 64, 128 poruka.