OOP og MVC - nødvendig?

[simenss]

Planlegger et større prosjekt med et budsjett på ca. 20.000 - 30.000 kroner. For å ha mest mulig igjen til markedsføring, har jeg planer om å ta meg av programmeringen selv. Har jobbet med PHP og mySQL i noen år nå, men er fortsatt på «hobbystadiet». OOP og MVC er helt nytt for meg, og etter å ha lest en del forum og artikler forstår jeg at dette er temaer man ikke kan sette seg inn i over natten. Klarer rett og slett ikke forstå logikken.

 

Til nå har jeg plassert kode som benyttes ofte i filen functions.php. Denne har jeg inkludert på toppen av index.php, som forøvrig inneholder et include-script. På den måten har jeg hele tiden hatt tilgang til den mest brukt koden (funksjonene), og det har fungert helt fint.

 

For mitt nye prosjekt håper jeg på mer enn 100-400 besøk daglig, og må derfor tenke litt mer «proft» enn tidligere. Det store spørsmålet er derfor: Med tanke på at jeg alene skal stå for all programmering og design, vil jeg ha stort utbytte av å bruke flere måneder på å sette meg inn i OOP og MVC?

 

Om noen uker er forretningsplanen min klar, og jeg vil ikke vente unødvendig lenge før jeg starter på produktutviklingen.

[serrghi]

du kan jo leige inn litt ekstra hjelp, selv om du skal gjøre alt selv. Det kan fort lønne seg om du ikke vil lese i et par mndr

[simenss]

du kan jo leige inn litt ekstra hjelp, selv om du skal gjøre alt selv. Det kan fort lønne seg om du ikke vil lese i et par mndr

Det er to grunner til at jeg ikke ønsker å leie inn noen:

1. Profesjonell hjelp koster, og det vil tære på markedsføringsbudsjettet
   
2. Jeg vil ikke lenger være i stand til å endre koden selv, da jeg rett og slett ikke vil forstå den delen som er skrevet som OOP. MVC-strukturen er jeg heller ikke kjent med. Da er jeg nødt til å betale for hjelp dersom jeg vil gjøre endringer.
   

[allyse]

Kan ikke se noen særlig bruk for MVC bruk hvis du skal lage et greit prosjekt. Jeg er klar over MVC er et ganske moteriktig begrep nå til dags, men folk må lære seg at å introdusere nye begreper ikke automatisk gjør kode bedre, ei heller brukbarhet.

 

Jeg har over de siste årene vært en motstander mot f.eks OOP i PHP, av den grunn folk nærmest voldtar prinsippet, uten den eneste tanke på at de ødelegger PHP sitt rykte. OOP har sine fordeler (dog få av dem er særlig brukbare innen PHP - PHP er og forblir statisk last (nå glemmer vi AJAX i denne diskusjonen med vilje), og mye av klasseprinsippet forsvinner. Dog OOP har dine positive sider, men alt med måte, alt med måte. Lær å bruke det, ikke bruk det fordi det høres så fint ut med objektorientert kode.

 

Tilbake til MVC. Mitt råd er å droppe hele MVC - fint å ha i bakhodet for å lære seg, men det blir en ny tankegang på hele kodekommunikasjonen, så for mange vil det kunne rote opp koden og gjøre den strukturelt og kvalitetsmessig svært dårlig.

[Ernie]

Slenger meg på allyse her. Selv om OOP har sine fordeler (og ulemper) er det langt fra noe «must». Endel bruker nok OOP fordi det er enklere å forholde seg til enn vanlige funksjoner. Det gjelder langt fra alle. Tross alt overlever man lenge med funksjoner etc. (C anyone?). Kan ting bli bedre med OOP? Vel, hvis du lærer deg det ordentlig? Ja, men det er absolutt ingen automatikk i det, og det er langt på vei avhengig av hva du faktisk skal lage. Uannsett vil god programmering med funksjoner alltid være bedre enn dårlig objekt-orientert programmering. Så lenge 99% av bruken av klasser i PHP vil være å aldri opprette mer enn et objekt av det er det absolutt ingen problemer å gå nærmest direkte over til funksjoner.

 

MVC ser jeg ikke poenget i. For meg blir det rett og slett for mye oppdeling. Å skille mellom business- og presentasjonslogikk holder lenge, og er (i mine øyne) et ubestritt «must» for større prosjekter.

[simenss]

Kan ikke se noen særlig bruk for MVC bruk hvis du skal lage et greit prosjekt. Jeg er klar over MVC er et ganske moteriktig begrep nå til dags, men folk må lære seg at å introdusere nye begreper ikke automatisk gjør kode bedre, ei heller brukbarhet.

 

Tilbake til MVC. Mitt råd er å droppe hele MVC - fint å ha i bakhodet for å lære seg, men det blir en ny tankegang på hele kodekommunikasjonen, så for mange vil det kunne rote opp koden og gjøre den strukturelt og kvalitetsmessig svært dårlig.

Med dine gode argumenter dropper jeg å sette meg inn i MVC. Det kan alltids læres senere dersom behovet dukker opp. For meg er det viktigste å få opp en nettside som fungerer godt med et greit antall brukere. Dersom tjenesten skulle bli svært populær vil også inntektene øke. Da vil jeg kunne overlate kodingen til en profesjonell.

 

 

Jeg har over de siste årene vært en motstander mot f.eks OOP i PHP, av den grunn folk nærmest voldtar prinsippet, uten den eneste tanke på at de ødelegger PHP sitt rykte. OOP har sine fordeler (dog få av dem er særlig brukbare innen PHP - PHP er og forblir statisk last (nå glemmer vi AJAX i denne diskusjonen med vilje), og mye av klasseprinsippet forsvinner. Dog OOP har dine positive sider, men alt med måte, alt med måte. Lær å bruke det, ikke bruk det fordi det høres så fint ut med objektorientert kode.

Jeg har på følelsen av at jeg vil bli en av de som "nærmest voldtar prinsippet" med OOP. Som jeg skrev over har jeg som mål å etter hvert overlate kodingen til en profesjonell. Økonomi, administrasjon og markedsføring er nemlig mer min greie. Men begrenset kapital tvinger meg til å ta meg av den første kodingen.

[simenss]

Slenger meg på allyse her. Selv om OOP har sine fordeler (og ulemper) er det langt fra noe «must». Endel bruker nok OOP fordi det er enklere å forholde seg til enn vanlige funksjoner. Det gjelder langt fra alle. Tross alt overlever man lenge med funksjoner etc. (C anyone?). Kan ting bli bedre med OOP? Vel, hvis du lærer deg det ordentlig? Ja, men det er absolutt ingen automatikk i det, og det er langt på vei avhengig av hva du faktisk skal lage. Uannsett vil god programmering med funksjoner alltid være bedre enn dårlig objekt-orientert programmering. Så lenge 99% av bruken av klasser i PHP vil være å aldri opprette mer enn et objekt av det er det absolutt ingen problemer å gå nærmest direkte over til funksjoner.

 

MVC ser jeg ikke poenget i. For meg blir det rett og slett for mye oppdeling. Å skille mellom business- og presentasjonslogikk holder lenge, og er (i mine øyne) et ubestritt «must» for større prosjekter.

Flere argumenter mot uprofesjonell bruk (les: min bruk) av OOP. Det liker jeg Det med business- og presentasjonslogikk hørtes interessant ut. En enkel innføring i form av et innlegg eller en link?

[RipeX]

Jeg bruker bare OOP på større prosjekter. Kun for at jeg synes det er mer oversiktlig.

Endret 15. april 2008 av RipeX

[Ernie]

Det med business- og presentasjonslogikk hørtes interessant ut. En enkel innføring i form av et innlegg eller en link?

Vel, har ingen link på det akkurat nå så jeg skal forsøke å forklare det her. Litt unøyaktig går det ut på å skille ut utseende fra programkode. Det er unøyaktig fordi man strengt tatt kan, og i mange tilfeller må, ha programkode i presentasjonslogikken. Uansett, business-logikk er det applikasjonen faktisk skal gjøre. Altså opprette noe, endre noe eller hente ut data om noe. Et viktig moment er at business-logikken aldri skal bry seg døyten om hvordan ting blir seendes ut. Dvs. HTML og utskrift generelt skal aldri noen gang forekomme i businesslogikken (til nød hvis alt krasjer). Det er forbeholdt presentasjonslogikken. Den skal ta dataene fra businesslogikken og vise det frem, og aldri noen gang bry seg om hvor de dataene kom fra. Endel vil si at du da bør bruke et template-system som f.eks Smarty, men dette er absolutt ingen nødvendighet. Faktisk er det tidvis en begrensning å gjøre det slik selv om det gir endel gratis funksjonalitet i forhold til HTML-generering (dropdown-bokser er f.eks lekende lett å generere med Smarty), men det betyr dog ikke at man ikke har bruk for det (det er litt smak og behag). Derimot betyr det at det er absolutt ingenting i vegen for å bruke PHP til den delen også (Smarty vil jo lage en PHP-versjon av det uansett), du må bare huske på at det skal være rent presentasjonsrettet. Eksempel på slik logikk kan være at du hvis et felt/data er tomt så fyller du inn en standardtekst. En andre ting kan være å farge annenhver rad i en tabell e.l. med hver sin farge, eller generere dropdown-bokser, tabeller, lister osv.

 

Fordelen med en slik inndeling er mange. Først og fremst gir det fritt spillerom i forhold til design og det rent funksjonelle i applikasjonen. Man kan fritt endre design og funksjon uten at noe krasjer (under forutsetning at grensesnittet beholdes såklart). Videre gir det store fordeler i forhold til sikkerhet i og med at man kan gi ut sikkerhetsoppdateringer uten at det påvirker designet. Hadde ting vært sammenblandet ville jo de med endret design slitt litt.

Endret 16. april 2008 av Ernie

[simenss]

I mine eksisterende systemer inneholder flere av sidene en sidenavn_action.php-fil. I toppen av index.php sjekker et script om det finnes en sidenavn_action.php-fil. Dersom det gjør det, inkluderes den. Disse sidenavn_action.php-filene bruker jeg til å sjekke brukerdefinert data, hente ut data fra en database etc. sidenavn_action.php-filen inkluderes alltid før outputen (HTML). Er det noe liknende dette du mener, eller er jeg fullstendig på jordet?

[pulse]

Jeg bruker OOP av tre grunner:

 

1. Dersom jeg skal definere noe som skal benyttes ofte (som f.eks en språk klasse. Når jeg først kaller på klassen velger jeg språket som skal benyttes, og senere kan jeg bare be den oversette, da den selv vet hvilket språk den skal oversette til). Dette gjelder også andre funksjoner som skal "holde på variabler for senere bruk".

 

2. Når jeg skal ha mange lignende funksjoner. Som f.eks: kutt en seting til maks antall ord, kutt ett ord til maks antall bokstaver osv... Da syns jeg det er greit å bruke en statisk klasse så har jeg alle funksjonene samlet.

 

3. Dersom en funksjon bruker mange andre funksjoner som ikke blir brukt alene, er det greit å samle alle i en klasse.

 

Men om det er noe must? Nei, det vil jeg ikke si. Det er mer oversiktlig når man først har kommet inn i det. Vet ikke hva dette gjør med ytelsen, men jeg ville tro at det faktisk er mer resusjkrevende å bruke klasser i de fleste tilfeller. Så ikke fortvil, lag prosjektet uten OOP, pass på budsjettet, og lykke til!

[simenss]

Takk for svaret pulse. Gjør selvtilliten litt større dersom jeg velger å ikke benytte OOP.

[The Red Devil]

Gjør deg sjølv ein tjeneste og lær OOP før du begynner på prosjektet. I tillegg ville eg anbefalt deg å lære TDD (Test Driven Development), det vil i alle fall redde deg vist du rekner med at du må refactore scriptet seinere.

 

Mens eg ikkje er heilt enig med allyse sitt ståsted angående OOP, så har han eit veldigt vikteg poeng. Du bruker ikkje OOP bare for å ha OOP, du bruker det når det kan gjøre livet ditt som programmerer lettere.

 

Vil anbefale at du får fatt i boka "PHP In Action" og leser den før du starter på prosjektet.

 

Du kan ta ein titt på denne tråden for litt meir "ståpunkter"

http://www.sitepoint.com/forums/showthread.php?t=517506

 

Og, lykke til