OOP i PHP (overgang fra Java)

[kjey]

Hei.

 

Begynte min "programmeringskarriere" med PHP, før jeg begynte på Java. Nå er jeg igjen på PHP'en og skal nå, med en kamerat, begynne å lage et meget stort nyhetsscript/system (noe ala Wordpress, bare mye mindre selvfølgelig!). Vi er nå i planlegginsfasen og prøver derfor å få ned noe på papiret (UML klassediagrammer, funksjonelle krav mm.).Det jeg fort oppdaget da jeg skulle sette meg ned med UML var at PHP er en del forskjellig fra Java. Altså, jeg synes så mange av metodene til de forskjellige klassene kunne være static i og med at funksjonene ikke hadde noe særlig med klassene å gjøre. F.eks. jeg har en klasse som heter User som holder all informasjon om en bruker. Så ville jeg ha en klasse UserManager som inneholder all funksjonalitet som kan utføres på brukeren. F.eks. registrering, sletting osv. Men disse funksjonene har jo ikke noe med UserManager å gjøre, så derfor ble alle metodene static. Er det egentlig noe vits å ha en egen klasse som håndterer brukerne da, når jeg like så greit kan klare meg med gode gamle funksjoner?

 

Som dere sikkert skjønner er det design av klassene jeg synes er vanskeligere i PHP. Da jeg programmerte med Java var det veldig mye arv og bruk av interface rett og slett fordi det fikk alt til å stemme, men foreløpig har jeg ikke sett ett tilfelle hvor disse kraftige verktøyene kan brukes Da får jeg rett og slett en følelse av at jeg tenker helt feil, og det gjør jeg nok!

 

Håper noen har noen kloke ord!

Endret 22. mars 2009 av kjey

[DeadManWalking]

Du kan jo implementere UserManager funksjonaliteten som statiske metoder i user klassen som tar en array av user objekt.

(Dog har jeg ingen peiling på PHP, kun java. Men det burde gå dette vel ?)

Endret 22. mars 2009 av data_jepp

[kjey]

Ja, det går jo det. Problemet er at jeg ikke ser noe vits i å gjøre det, kan jo heller bare lage metodene i User uten å implementere et interface. Slik jeg har forstått det skal jo interface brukes for sikre at klassene som implementerer dem har samme metoder som i interfacet. Men når jeg bare har én klasse som får bruk for UserManager ser jeg ikke helt vitsen.

[Edorph]

Jeg tror det du ser på som vanskelig er at du ikke har et objektorientert rammeverk i bunnen som tvinger deg til å arve eller implementere klasser og interfaces som er definert av rammeverket selv. Med andre ord, arbeider mer fra "scratch" enn du er vant med i Java (på godt og vondt).

 

I begynnelsen av prosjektet kan de kanskje virke fåfengt å objektifisere alt mulig - Keep It Simple, Stupid, og alt det der. Personlig tror jeg du vil se nytten av det etterhvert som prosjektet vokser og utvider seg, særlig når det gjelder vedlikehold.

 

Sett at du f.eks. i fremtiden vil bruke kodebasen din sammen med f.eks. et LDAP-system eller Facebook Connect, og dermed trenger funksjoner som registrerer brukere, sletter etc på en annen måte enn når du hadde native brukere. Hvis den tid kommer vil du antagelig se nytten av å ha brukt et UserManager interface, som du så lager system-spesifikke implementasjoner av (f.eks. NativeUserManager, LdapUserManager, FacebookUserManager osv.). Kanskje ikke et relevant eksempel i ditt tilfelle, men du skjønner sikkert tegninga.

 

En annen fordel med objektorientert kode er at det som oftest øker testbarheten til koden din betraktelig. Du kan f.eks. lage mock-objekter (dummy-implementasjoner) som du bruker mens du tester andre klasser, sålenge de implementerer samme interface som de reelle klassene. Husk at du mister mye av denne fordelen og den forrige hvis klassen din rett og slett bare er en abstrakt klasse med statiske metoder, siden du ikke kan ha de i interfacet eller overstyre dem i implementasjonene. Bruk i så fall heller et singleton eller factory pattern.

 

Mulig jeg gikk litt utover og bort fra det du faktisk lurte på nå.. fikk skrivedilla.

[luxus]

(Veeeeeldig på siden av temaet her:

Dersom dere står fritt til å velge språk/ rammeverk vil jeg sterkt anbefale at dere tar en titt på Ruby on Rails. Jeg har aldri vært så fornøyd med et rammeverk og språk før og jeg har vært innom Java og PHP (som jeg benytter på jobben), og nå har jeg lagt min elsk på RoR (som jeg leker litt småseriøst med hjemme). Har du litt erfaring med for eksempel dynamiske språk som JavaScript vil det kanskje være enklere å vri hodet sitt rundt noen av konstruksjonene i Ruby.)

[OIS]

bla bla rails

PHP har mange rammeverk som ligner på Rails, og noen bedre imo. Blir kvalt av Rails. Mange som sammenligner PHP med RoR får ikke med seg at PHP er et språk og RoR et rammeverk, så sammenligningen er ikke helt korrekt.

 

Ruby ser ut som det har en del features PHP kunne ha godt av, men er ikke noe bedre språk å utvikle i så vidt eg vet. Vet om en del på internett som gikk fra PHP til RoR, så tilbake til PHP. De har da med seg bedre vaner som du får av å kunne flere språk, ikke nødvendigvis Ruby. De som går fra PHP som første språk til sitt neste språk vil ofte hate PHP fordi de selv var dårlige programmerere på den tiden.

[kjey]

Edorph: Har tenkt på noe av det samme som du eier, og er helt klart enig!

 

Jeg snublet også over OIS sin signatur, "7 gode PHP OO vaner", som jeg synes forklarte litt

 

Men et spørsmål angående planlegging av systemet: Er det nødvendig å planlegge hele systemet med én gang, eller holder det å ta del for del underveis? Synes det ihvertfall er litt vanskelig å visualisere alle klassene osv i systemet når jeg ikke har laget et lignende system før.

 

Ihvertfall, takk for gode svar!

[luxus]

Det var kun et forslag - ingen vits å starte PHP vs Ruby on Rails da smaken er som baken; vi hadde antageligvis aldri blitt enig (...med mindre du faktisk hadde vært igjennom et par prosjekter på Rails ;-) ).

[OIS]

Men et spørsmål angående planlegging av systemet: Er det nødvendig å planlegge hele systemet med én gang, eller holder det å ta del for del underveis? Synes det ihvertfall er litt vanskelig å visualisere alle klassene osv i systemet når jeg ikke har laget et lignende system før.

Du tenker på poeng 7? Det som står på den siden er noe du bør ha i tankene, men ikke trenger å følge religiøst imo. Det er veldig greit å ikke skrive HTML eller drive annen formatering i et objekt for personer, ordre eller databaser. Men du må ikke planlegge hver detalj i mindre prosjekt, da er det gjerne bedre å ta noen få ting om gangen.

Ha i bakhodet at den klassen/metoden du skriver gjerne skal brukes mot og med andre klasser i fremtiden, men ikke implementer for mye med en gang. Det du trenger en dag er gjerne ikke det du tror du vil trenge i dag. Eller kanskje du må gjøre om/splitte klassen, og da var all den ubrukte koden bortkastet.