OOP noe vits i å lære seg?

[jorgis]

At en side laster et par millisekunder  tregere synes jeg egentlig er et dårlig argument. Hadde det vært flere sekunder ville saken vært en annen.

5761461[/snapback]

 

Godt poeng. Noen få millisekunder er noe en kan ofre, da det som regel er andre, langt større flaskehalser å håndtere.

 

Men uansett om du velger å bruke OOP eller prosedyrell kode, vil sluttresultatet avhenge i største grad av hvor god kode du skriver. OOP er bare i stand til å øke kvaliteten på koden noen hakk i forhold til det du kan klare med prosedyrell kode. Skriver du dårlig kode generelt sett, er det liten vits med OOP, men i de rette hender er OOP et utrolig kraftig verktøy, uansett om det er PHP eller C++.

[trondes]

Er det noen som har en liten kode snutt å komme med.

 

Som viser at OOP faktisk kan spare programmering tid? Der du bruker samme classen to ganger?

[jorgis]

Er det noen som har en liten kode snutt å komme med.

 

Som viser at OOP faktisk kan spare programmering tid? Der du bruker samme classen to ganger?

5761497[/snapback]

 

Gidder ikke å komme med et konkret kodeeksempel (klokken er mange ), men om du for eksempel trenger å lage et databaseabstraksjonslag, vil det være enormt mye lettere i OOP, da du kan la databaseklassens constructor sette opp databaseinterfacet, velge hvilken database du kobler til, og la den velge hvilken databasemotor den bruker. Da kan du i hele resten av applikasjonen din bare kjøre $db->get_userid_from_name($name), istedenfor å måtte kjøre SQL-spørringer direkte eller manipulere funksjonsnavnene direkte for hver nye databasemotor (mysql_get_userid_from_name($name) kontra pgsql_get_userid_from_name($name) o.l.).

 

Enkelt og greit er OOP et verktøy for å abstrahere. Du slipper å måtte tenke på ting du ikke trenger å tenke på. Om du skriver en DB-klasse som håndterer DB av seg selv, slipper du å måtte tenke på det hver gang du skal bruke DB. Spørsmålet blir bare hvor stor grad av abstrahering du faktisk trenger, og det er mange som ikke liker abstrahering i det hele tatt, siden det kan føles som om du mister litt kontrollen selv. Om du skal lage et 100-linjers flatfil-CMS trenger du ikke det, men om skriver 20 000+ linjer, er det utrolig greit å kunne overlate deler av jobben til en klasse du har skrevet før. Det gir en mye større ryddighet i koden, og det er mye lettere å debugge senere.

[trondes]

Enkelt og greit er OOP et verktøy for å abstrahere. Du slipper å måtte tenke på ting du ikke trenger å tenke på. Om du skriver en DB-klasse som håndterer DB av seg selv, slipper du å måtte tenke på det hver gang du skal bruke DB. Spørsmålet blir bare hvor stor grad av abstrahering du faktisk trenger, og det er mange som ikke liker abstrahering i det hele tatt, siden det kan føles som om du mister litt kontrollen selv. Om du skal lage et 100-linjers flatfil-CMS trenger du ikke det, men om skriver 20 000+ linjer, er det utrolig greit å kunne overlate deler av jobben til en klasse du har skrevet før. Det gir en mye større ryddighet i koden, og det er mye lettere å debugge senere.

5761508[/snapback]

 

hmm.. tror jeg forstår, men holder meg til funksjoner en stund til.

Enkle å flytte med seg de også ( db_hent, db_hent_query og db_hent_key må jeg ha med meg til alle program )

 

bakdelen med class/funksjoner som du bare skriver en gang er at du glemmer hvordan de virker, selv om jeg kan ganske godt med database, queryer osv. så hadde jeg sikkert måtte slått opp hvordan jeg skulle opprette kontakt med mysql db.

 

Men fordelen med classer er at de ikke har så stor innvirkning på mulijøet rundt seg, feks hvis det alt skulle finnes en class med samme navnet er det vel bare å rename den så vil alt virke som normalt inni den?

[Ernie]

Jeg har allerede gitt et veldig godt, etter min mening, eksempel på hvor OOP er bra (database). Jeg mener fortsatt at det er bedre egnet å bruke OOP islike tilfeller, enn å lage prosedyriske funksjoner som sjekker konstanter for å bruke den ene eller andre funksjonen. At en side laster et par millisekunder  tregere synes jeg egentlig er et dårlig argument. Hadde det vært flere sekunder ville saken vært en annen.

5761461[/snapback]

Makan til trangsynthet. Hvor vanskelig kan det være å ha funksjoer ala database_query($query, $link)? Skrekkelig så vanskelig folk skal ha det

 

At en side laster et par millisekunder  tregere synes jeg egentlig er et dårlig argument. Hadde det vært flere sekunder ville saken vært en annen.

5761461[/snapback]

 

Godt poeng. Noen få millisekunder er noe en kan ofre, da det som regel er andre, langt større flaskehalser å håndtere.

 

Men uansett om du velger å bruke OOP eller prosedyrell kode, vil sluttresultatet avhenge i største grad av hvor god kode du skriver. OOP er bare i stand til å øke kvaliteten på koden noen hakk i forhold til det du kan klare med prosedyrell kode. Skriver du dårlig kode generelt sett, er det liten vits med OOP, men i de rette hender er OOP et utrolig kraftig verktøy, uansett om det er PHP eller C++.

5761479[/snapback]

OOP øker ikke kvaliteten på noen som helst kode. I C++ er dette selvsagt et svært hendig verktøy, men i PHP har man kort og greit ikke bruksområder for OOP enten du vil det eller ei.

 

Er det noen som har en liten kode snutt å komme med.

 

Som viser at OOP faktisk kan spare programmering tid? Der du bruker samme classen to ganger?

5761497[/snapback]

 

Gidder ikke å komme med et konkret kodeeksempel (klokken er mange ), men om du for eksempel trenger å lage et databaseabstraksjonslag, vil det være enormt mye lettere i OOP, da du kan la databaseklassens constructor sette opp databaseinterfacet, velge hvilken database du kobler til, og la den velge hvilken databasemotor den bruker. Da kan du i hele resten av applikasjonen din bare kjøre $db->get_userid_from_name($name), istedenfor å måtte kjøre SQL-spørringer direkte eller manipulere funksjonsnavnene direkte for hver nye databasemotor (mysql_get_userid_from_name($name) kontra pgsql_get_userid_from_name($name) o.l.).

5761508[/snapback]

Her sier du indirekte at man skal hardkode config inn i constructor. Dette er grusomt stygt! Forøvrig, hvor mange ganger har du bruk for en tilkobling til en postgresql-db samtidig med en mysql-db? Nei, riktig det, du får aldri bruk for det. Derfor går det fint med database_query($query, $link) som jeg skrev over.

 

Enkelt og greit er OOP et verktøy for å abstrahere. Du slipper å måtte tenke på ting du ikke trenger å tenke på. Om du skriver en DB-klasse som håndterer DB av seg selv, slipper du å måtte tenke på det hver gang du skal bruke DB. Spørsmålet blir bare hvor stor grad av abstrahering du faktisk trenger, og det er mange som ikke liker abstrahering i det hele tatt, siden det kan føles som om du mister litt kontrollen selv. Om du skal lage et 100-linjers flatfil-CMS trenger du ikke det, men om skriver 20 000+ linjer, er det utrolig greit å kunne overlate deler av jobben til en klasse du har skrevet før. Det gir en mye større ryddighet i koden, og det er mye lettere å debugge senere.

5761508[/snapback]

Overlate deler av jobben til en klasse? Dette var da litt av noen ord. Når fikk klassen/objektet magiske evner og kunne forutse hva du skal? Ærligtalt, hva er det funksjoner ikke kan som klassefunksjoner kan? Dessuten, $link = database_connect(...) går minst like bra som $db = new database(...). Det er bare det at du klør etter å bruke -> ...

 

Er det noen som har en liten kode snutt å komme med.

 

Som viser at OOP faktisk kan spare programmering tid? Der du bruker samme classen to ganger?

5761497[/snapback]

Vel, du får ingen eksempler på det er fordi det ikke stemmer. En klasse SKAL brukes flere ganger, men det skjer aldri i PHP. Dessuten kan også funksjoner brukes flere ganger.

 

 

 

Utfordring til alle pro-OOP i PHP: Finn minst et eksempel på når man reelt har mange objekter å holde styr på i PHP. Med mange mener meg minst 2 og helst vesentlig mer 2.

Endret 16. mars 2006 av Ernie

[Paull]

Utfordring til alle pro-OOP i PHP: Finn minst et eksempel på når man reelt har mange objekter å holde styr på i PHP. Med mange mener meg minst 2 og helst vesentlig mer 2.

5761973[/snapback]

 

Er målet å vise at man kan gjøre det samme uten OOP ?

[Ernie]

Utfordring til alle pro-OOP i PHP: Finn minst et eksempel på når man reelt har mange objekter å holde styr på i PHP. Med mange mener meg minst 2 og helst vesentlig mer 2.

5761973[/snapback]

 

Er målet å vise at man kan gjøre det samme uten OOP ?

5762054[/snapback]

Nei, målet er å finne ut om OOP faktisk trengs i PHP. Kommer ingen opp med noe så kan jeg enten konkludere med at de som skriker høy om OOP her rett og slett ikke gidder å komme med gode eksempler hvor OOP trengs, eller at OOP rett og slett ikke trengs i PHP. Kommer derimot noen opp med eksempler så kan det kanskje hende jeg ser at man faktisk har en liten bruk for det i PHP.

 

Edit: Poenget er at jeg tror man i PHP bare har den ene database, den ene templaten, den ene ditten, den ene datten, men aldri 2 eller flere av noe.

Endret 16. mars 2006 av Ernie

[Paull]

Vel, jeg mekket en OOP-basert sak for ikke så lenge siden. Skulle tegne en graf med verdier for en haug med websites.

Var veldig enkelt å kunne gjøre det på denne måten (pseudokode):

$db = new database();
$sites = $db->getAllSites();

$graph = imagecreate();
foreach($sites as $site)
{
 imagerectangle($graph,$site->getValueA(),$site->getValueB(),$site->getValueC(), $site->getValueD(),$blackcolor);
}


echo createpngfromimage($graph);

 

(Vet at dette ikke er gyldig, og at verdiene ikke sier så mye, men det er bare for et enkelt eksempels skyld).

Det fine er at graf-modulen ikke trenger å gjøre noen som helst antakelser om hvilken database som benyttes, tabellnavn etc. Den ser bare sites, og vet at hver site har noen metoder som returnerer data om den aktuelle siten. Skal databasen byttes ut fra f.eks mysql til postgres, så trenger man bare gjøre endringer i database-klassen, for graf-modulen er det knekkende likegyldig hva som ligger i bunnen.

 

Dette går jo selvsagt an å gjøre sekvensielt også, men det er en annen sak..

[Ernie]

Jøss, det der er jo faktisk i nærheten i det minste Databasen kunne jo fint vært vanlige funksjoner, og site kunne man jo sikkert funnet en ikke-OOP-måte å løse det på. Dog, prinsippet er jo faktisk her. Du bruker jo faktisk litt av fordelen av OOP, nettopp det at man lettere kan modelere mange "fysiske" objekter av samme type.

[Paull]

Ja, det fine er at selve site-objektene ble brukt andre steder også (for å kunne endre på verdiene og sånt), og da var det bare å bruke de samme måtene ala $site->setValueA(123); og $db->storeSite($site); eller $db->updateSite($site);

[blackbrrd]

Jeg kan ikke php, men det spiller vel egentlig ikke noen rolle.

 

La oss si at du har en tabell med kunder. Disse kundene skal du vise på diverse html sider.

 

Du lager en klasse som enkapsulerer henting av kundedata og holder på kundedataene.

 

Samme klasse kan du bruke til å lagre kundedata.

 

Hvis du bruker en ORM (Object Relation Mapper) så trenger du ikke skrive noe av koden selv heller.

[jorgis]

Er det noen som har en liten kode snutt å komme med.

 

Som viser at OOP faktisk kan spare programmering tid? Der du bruker samme classen to ganger?

5761497[/snapback]

 

Gidder ikke å komme med et konkret kodeeksempel (klokken er mange ), men om du for eksempel trenger å lage et databaseabstraksjonslag, vil det være enormt mye lettere i OOP, da du kan la databaseklassens constructor sette opp databaseinterfacet, velge hvilken database du kobler til, og la den velge hvilken databasemotor den bruker. Da kan du i hele resten av applikasjonen din bare kjøre $db->get_userid_from_name($name), istedenfor å måtte kjøre SQL-spørringer direkte eller manipulere funksjonsnavnene direkte for hver nye databasemotor (mysql_get_userid_from_name($name) kontra pgsql_get_userid_from_name($name) o.l.).

5761508[/snapback]

Her sier du indirekte at man skal hardkode config inn i constructor. Dette er grusomt stygt! Forøvrig, hvor mange ganger har du bruk for en tilkobling til en postgresql-db samtidig med en mysql-db? Nei, riktig det, du får aldri bruk for det. Derfor går det fint med database_query($query, $link) som jeg skrev over.

 

Om du skriver en applikasjon i PHP som er ment å kjøre på alle mulige kombinasjoner av PHP, en eller annen httpd, samt en relasjonell database kan du ikke hardkode inn spørringene dine direkte i databasen. Det er nemlig enda mer horribelt!

 

Min bruk av OOP til å gjøre dette, har vært å ha en databaseklasse med en default constructor. Første parameter til default constructor er hvilken DBMS jeg vil bruke. Videre kan jeg da kjøre en spørring som f.eks: $db->update_user_info($username, $avatar, $signatur), uten at jeg trenger å tenke på om jeg jobber mot PostgreSQL, MySQL, MSSQL eller Oracle. Den henter selv hvilken spørring update_user_info() peker på, og utifra hva jeg har sagt når jeg konstruerte objektet velger den hvordan den skal formatere den.

 

Dette er ikke bare nyttig når en skal ha flere forskjellige databaser å jobbe mot (jeg har aldri hatt behov for det), men når du trenger å kunne sette applikasjonen ut i mange forskjellige miljøer, og ikke vil la brukeren måtte manuelt gå inn i koden og endre en include.

 

Enkelt og greit er OOP et verktøy for å abstrahere. Du slipper å måtte tenke på ting du ikke trenger å tenke på. Om du skriver en DB-klasse som håndterer DB av seg selv, slipper du å måtte tenke på det hver gang du skal bruke DB. Spørsmålet blir bare hvor stor grad av abstrahering du faktisk trenger, og det er mange som ikke liker abstrahering i det hele tatt, siden det kan føles som om du mister litt kontrollen selv. Om du skal lage et 100-linjers flatfil-CMS trenger du ikke det, men om skriver 20 000+ linjer, er det utrolig greit å kunne overlate deler av jobben til en klasse du har skrevet før. Det gir en mye større ryddighet i koden, og det er mye lettere å debugge senere.

5761508[/snapback]

Overlate deler av jobben til en klasse? Dette var da litt av noen ord. Når fikk klassen/objektet magiske evner og kunne forutse hva du skal? Ærligtalt, hva er det funksjoner ikke kan som klassefunksjoner kan? Dessuten, $link = database_connect(...) går minst like bra som $db = new database(...). Det er bare det at du klør etter å bruke -> ...

 

Se over. Halve poenget med OOP er at en kan abstrahere vekk mye av det som gjøres i applikasjonen, og "overlate deler av jobben" til en klasse. Ta eksempelet med klassen min over. Det er mye mer praktisk, og gir en mye lettere utvikling om jeg kan skrive en databaseklasse én gang, og deretter nesten bare glemme den, slik at jeg kan kjøre $db->get_all_recent_comments() fremfor å selv måtte konstruere samme SQL-spørringen flere ganger og kjøre mysql_query().

 

Selvfølgelig, du kan konstruere en enorm fil med funksjoner (get_all_recent_comments(), update_user_info() m.m.) som gjør samme jobben, men det er uhyre rotete, og du vil ende opp med at bruker/admin vil bli nødt til å gå inn i koden og endre includes eller i verste fall alle funksjonene om en vil heller bruke Oracle eller pgsql.

 

Du prøver å si at OOP er meningsløst i PHP, men det virker som om du ikke helt forstår et av de viktigste poengene med OOP; abstrahering. Abstrahering gjør det mulig at en av dine medutviklere sier "jeg skrev en nyttig klasse i dag, du bruker den slik:", og så trenger ikke du bry deg mer med hvordan den fungerer. Det gjør også portabiliteten enormt mye bedre, da du kan f.eks. hente ned en klasse fra phpclasses.org eller andre steder.

 

Kanskje du ønsker å vite og kontrollere hva absolutt alle aspekter av din applikasjon gjør mens du utvikler, men det blir utrolig mye tyngre og når du nærmer det store prosjektstørrelser vil du få trøbbel. Abstrahering lar deg bare skubbe vekk databasebiten, og si at "jeg trenger egentlig ikke vite hvordan den fungerer eller hva den gjør. Jeg sender den en spørring, og den gir meg dataene. Ferdig pakke". Om en er mange utviklere på samme prosjekt er det et must, siden det ikke er mulig for en enkelt utvikler å forstå kodeflyten gjennom all koden. Det krever en god del tillit til den som har skrevet klassen, og det kan kanskje være vanskelig for mange.

 

Er det noen som har en liten kode snutt å komme med.

 

Som viser at OOP faktisk kan spare programmering tid? Der du bruker samme classen to ganger?

5761497[/snapback]

Vel, du får ingen eksempler på det er fordi det ikke stemmer. En klasse SKAL brukes flere ganger, men det skjer aldri i PHP. Dessuten kan også funksjoner brukes flere ganger.

 

Skill mellom klasse og objekt, takk.

 

Utfordring til alle pro-OOP i PHP: Finn minst et eksempel på når man reelt har mange objekter å holde styr på i PHP. Med mange mener meg minst 2 og helst vesentlig mer 2.

5761973[/snapback]

 

Hvorfor snakker du om objekter her, når du snakker om klasser rett over?

 

Anyhoo, paull hadde vel et greit eksempel som jeg benytter meg av ofte ved gjennomgang av flere rader i databasen. Hver rad er et objekt, slik at du behandler hvert innlegg i et forum som et objekt, eller hver kommentar i en blog. Største antallet objekter jeg har måttet holde styr på da har vel vært rundt 1500, etter en liten stresstest.

 

blackbrrd har vel flere ganger nevnt ORM som en kjekk bruksmåte for OOP i PHP.

[Peter]

Det slår meg at du enten ikke har drevet noe sårlig med OOP, eller så forstår du ikke prinsippet rundt det, Ernie. Her mener jeg ikke å være frekk eller insinuerende på noen måte, men du har fått flere mulige funksjonalitetseksempler med OOP, og det eneste du sier er at det kan man gjøre med prosedyrisk programmering også. Man kan gjøre nesten alt med begge metoder, men hver leir har sine fordeler og ulemper.

 

Det er veldig synd jeg ikke husker navnet på firmaet som utviklet siden for firmaet der jeg jobbet før, for jeg fikk sett noe av koden de lagde, og den var objektorientert så det sang. Jeg tviler sterkt på at et seriøst firma bruker OOP dersom det er så dårlig som du skal ha det til.

 

Jeg lurer fortsatt på hvorfor de er så opptatt av å implementere OOP i PHP dersom det er helt ubrukelig?

[Ernie]

Det slår meg at du enten ikke har drevet noe sårlig med OOP, eller så forstår du ikke prinsippet rundt det, Ernie.

5762732[/snapback]

Jasså ja, da lurer jeg skrekkelig på hvordan og hvorfor jeg fikk en B objekt-orientert programmering. Jeg kan jo iallfall ikke ha forstått det

[Paull]

Nei, for da ville du fått en A

[allyse]

Det slår meg at du enten ikke har drevet noe sårlig med OOP, eller så forstår du ikke prinsippet rundt det, Ernie. Her mener jeg ikke å være frekk eller insinuerende på noen måte, men du har fått flere mulige funksjonalitetseksempler med OOP, og det eneste du sier er at det kan man gjøre med prosedyrisk programmering også. Man kan gjøre nesten alt med begge metoder, men hver leir har sine fordeler og ulemper.

 

Det er veldig synd jeg ikke husker navnet på firmaet som utviklet siden for firmaet der jeg jobbet før, for jeg fikk sett noe av koden de lagde, og den var objektorientert så det sang. Jeg tviler sterkt på at et seriøst firma bruker OOP dersom det er så dårlig som du skal ha det til.

 

Jeg lurer fortsatt på hvorfor de er så opptatt av å implementere OOP i PHP dersom det er helt ubrukelig?

5762732[/snapback]

 

 

Hehe. Et profft, stort firma har laget et saksbehandlingssystem her. Nå er det slik at det er det jeg har hatt mest problemer med her på husket. woha,. det beviser da at de store veit hva de gjør. mange mill i dass for et "profft" resultat av proffe er det bevis for.

 

Problemet er ikke at OO er ubrukerlig, det er å finne bruksområdet som er problemet med de fleste. Som et eksempel nevt over begynner vi å nærme oss en mulig bruk av OO, men dette er et eksempel som skiller seg fra mengen. Det er den mengden (flertallet) jeg og Ernie stiller oss mot.

Endret 16. mars 2006 av allyse

[Peter]

Gratulerer, Ernie, da synes fortsatt at du har så vanskelig for å se bruksområder for OOP I PHP. Du avskrev f.eks. mitt eksempel ovenfor, og kalte det trangsynt, når du tydeligvis ikke forstod poenget.

Å kunne skrive et helt skript, og gjøre en eneste minimal endring for at skriptet skal bruke en helt annen databasemotor, synes jeg i største grad er relevant og nyttig.

F.eks. for de som sitter og skriver skript andre skal kunne bruke, så kan de gjøre det mye mer brukervennlig ved å støtte mysql, mssql, postgresql osv. Dette kan, som nevnt tidligere, gjøres både med og uten OOP, men OOP gjør det penere etter min mening.

[trondes]

Hmm.. er vel greit å kunne.

Url til en plass jeg kan lese litt mer om dette, forklaringer på hvordan det hele virker.

[blackbrrd]

Hibernate er en ORM for java, og du finner all informasjon på www.hibernate.org

 

Har drevet endel testing selv og ettersom jeg bruker reverseengineering av databasen så trenger jeg ikke skrive en linje kode for å ha klasser jeg kan bruke istedetfor å skrive INSERT og UPDATE setninger. For SELECT setninger så er det ofte det er lurt å bruke et query language av noe slag, sql eller hql fungerer fint, hql er sql varianten som gir deg klasser utfra datamodellen.

 

Jeg vet desverre ikke om noen ORM for php.

 

Jeg bruker personlig Postgres som database, de har nå også en fullt fungerende windows versjon. Brukte ca 2 minutter på å sette den opp på min egen pc.. www.postgres.org

 

.. også bruker jeg Eclipse sammen med Hibernate tools, og JBuilder til generell utvikling.

 

På jobben bruker vi tomcat for jsp/servlets.

[existemi]

PHP eller ikke PHP; OOP i prinsippet arv og kontrakter. Generalisering og spesialisering.

 

Kode-eksempler, for- og motargumenter for OOP jeg har sett i dette tråden viser lite til arv og kontrakter. Av den grunn vil jeg ikke kalle denne tråden noen diskusjon om objektorientert programmering, men heller objektbasert programmering(OBP).

 

Utvikler man klasser med arv, vil gjenbruk av kode nå en ny høyde.

 

Eksempel:

Si man vil lage et register over ansatte i en bedrift.

I dette tilfellet lager man en klasse for en ansatt.

Denne klassen er en generalisert og abstrakt klasse.

 

Deretter lager man klasser for hver type anstall i bedriften, som har anstatt-klassen som superklasse, og arver metoder fra denne. Disse klassene blir spesialiserte for hver type ansatt og inneholder forskjellige spesifikasjoner.

 

Ved utvikling av diverse klienter, kan det opprettes objekter over alle ansatte ut ifra informasjon hentet fra en datakilde. Klienten trenger derfor ikke ta hensyn til hvilke type ansatt den skal behandle, da klassene sammen med informasjon fra datakilden står for håndteringen av dette.

 

Kildekoden for behandling av data, blir da begrenset til minimalt. Og implimenteringen av klienter for et større system, blir delt opp i små problemer. Gjenbruk når nye høyder. Dette scenarioet passer godt inn i PHP5.

 

Ved utvikling uten bruk av arv og kontrakter, som da er objektbasert programmering, vil jeg si meg helt enig i at funksjoner gjør akkurat samme nytten.