OOP noe vits i å lære seg?

[allyse]

Jeg vil også legge til en oppfølging på Ernie sitt siste innlegg om at PHP kan være closed-source. Null problem det, og her er jo faktisk Zend i løpet. Eneste forskjellen blir da at du må bruke zend encoder til å renderere sidene, men ellers er filene krypterte. Kaller du det open source, DarkSlayer?

 

Men tilbake til OO. Jeg kunne egentlig ønsket med tall og fakta, gjerne fra spørreundersøkeler mv, jobberfaring mv. fra DarkSlayer som bekrefter at OOP er for det første mest brukt fra proffisjonelle utviklere (regner ikke med folk som ikke har en jobb innen utvikling) og at OOP faktisk forbedrer et program. Husk vi snakker om PHP, ikke java, c++ mv.

[DarkSlayer]

Trådstarter startet med: "Er det vits å lære seg oop?" i et slikt tonefall at jeg leser det som: "Jeg er lat og gidder ikke å lære med oop med mindre det er sinnsykt viktig fordi jeg ikke ser poenget med det".

 

Så jeg forsøker å gi et svar på at oop er viktig, og at det gjerne kan brukes i php. Enig med ernie at php kanskje ikke er verden beste plass å begynne med oop, men det er så godt som full støtte for det med noen rare og tungvinte ting å gjøre ting på. Så presenterer jeg endel synspunkter, som jeg drar litt ut for å gjøre poeng ut av dem.

 

De aller fleste her hadde gitt et svar som er meget anti-oop, og at oop er IKKE NØDVENDIG. Og de som var for kom med noen rare halvsannheter. Så jeg forsøkte å dra ting litt ut i perspektiv.

 

Den eneste argumentasjonen som er dratt frem av betydning er at oop kode er tregt og inneffektivt. Ja så kjør xDebug eller Zend sin profiler da og profiler koden din så du kan se hvor det går tregt, og gjør noe med det. Mest sannsynlig så er det ikke oop som gjør koden din tregt, men fordi man har ineffektive algoritmer av ymse slag.

 

Men enig at oop i php ikke er helt rette plassen siden det finnes mye ferdige funksjoner for rare ting, og at kode på en side ikke blir benyttet på en annen side. Men jo mer jeg jobber med php, jo mer anti-php blir jeg. For det er mye rart der.

 

Og problemet med open source .... jeg skal omformulere meg. Du har ingen garanti for at kode man finner i open source ikke inneholder rettighetsbeskyttet materiale, og siden php er veldig mye "go and get code" så medfører det unødvendig risiko.

 

Men som alt annet innen it. Går man rundt og lager unskyldninger for ikke å lære seg ting, så blir man utdatert og ubrukelig. Man må streve for å lære seg masse rart. OOP er definitivt en av de viktigste tingene man bør lære seg, for det kan benyttes i bøttevis av språk.

[Jankee]

Med litt erfaring med system som er store og programmert i php , med manglande OO-kunnskap.

 

Det ser jævlig ut, skalerbarheiten stinker, programmering i koden tar lengre tid, og budsjetter er ikkje noko sjanse i havet å holde seg innanfor.

 

Ei av hovudfilene er åleine 2500 linjer koder, totalt består hovudsystemet av 350 kodefiler og antal tegn er ca 6,7 mill.

Så har me jo selfølgeleg "nokre" undersystem

 

 

For utviklingsgruppa eg sitt i som har overtatt denne koden så er det ikkje få gonger at tanker om å kaldkvele dei tidelegare utviklerene går igjennom hjernen på oss.

 

Lage større system utan skikkeleg OO-tankegang skulle ha vore forbode.

[Ernie]

Med litt erfaring med system som er store og programmert i php , med manglande OO-kunnskap.

 

Det ser jævlig ut, skalerbarheiten stinker, programmering i koden tar lengre tid, og budsjetter er ikkje noko sjanse i havet å holde seg innanfor.

 

Ei av hovudfilene er åleine 2500 linjer koder, totalt består hovudsystemet av 350 kodefiler og antal tegn er ca 6,7 mill.

Så har me jo selfølgeleg "nokre" undersystem

 

 

For utviklingsgruppa eg sitt i som har overtatt denne koden så er det ikkje få gonger at tanker om å kaldkvele dei tidelegare utviklerene går igjennom hjernen på oss.

 

Lage større system utan skikkeleg OO-tankegang skulle ha vore forbode.

5751993[/snapback]

Min (lille) erfaring tilsier at dette kommer av at de ikke kan å dokumentere skikkelig, og ikke mangel på OO-tankegang. Som sagt, det er en myte at OOP automatisk gir mer oversiktlig og vedlikeholdbar kode. Det er også en myte at man med OOP kan kode raskere eller mer effektivt. Du hadde nok fått et minst like stort helvete om koden var OO, men hadde mangelfull kommentering og dokumentasjon ...

 

Det burde vært forbudt å lage en klasse man alltid bare oppretter et objekt av under kjøring.

Endret 14. mars 2006 av Ernie

[aeinstein]

Så da er masse kommentarer, skrevet med rettskrivning (ikke sms-språk som ikke går an å søke gjennom hvis man leter etter noe spess) og gode variabelnavn++ de beste tingene å ta med seg? Pluss stukturert kode i form av litt tab og sånn?

 

Er det "dumt" for hastigheten å lage lange og _veldig_ forklarende variabelnavn:

passord_for_md5

passord_etter_md5

eller betyr det lite når sidene er små hvertfall?

[Jankee]

Med litt erfaring med system som er store og programmert i php , med manglande OO-kunnskap.

 

Det ser jævlig ut, skalerbarheiten stinker, programmering i koden tar lengre tid, og budsjetter er ikkje noko sjanse i havet å holde seg innanfor.

 

Ei av hovudfilene er åleine 2500 linjer koder, totalt består hovudsystemet av 350 kodefiler og antal tegn er ca 6,7 mill.

Så har me jo selfølgeleg "nokre" undersystem

 

 

For utviklingsgruppa eg sitt i som har overtatt denne koden så er det ikkje få gonger at tanker om å kaldkvele dei tidelegare utviklerene går igjennom hjernen på oss.

 

Lage større system utan skikkeleg OO-tankegang skulle ha vore forbode.

5751993[/snapback]

Min (lille) erfaring tilsier at dette kommer av at de ikke kan å dokumentere skikkelig, og ikke mangel på OO-tankegang. Som sagt, det er en myte at OOP automatisk gir mer oversiktlig og vedlikeholdbar kode. Det er også en myte at man med OOP kan kode raskere eller mer effektivt. Du hadde nok fått et minst like stort helvete om koden var OO, men hadde mangelfull kommentering og dokumentasjon ...

 

Det burde vært forbudt å lage en klasse man alltid bare oppretter et objekt av under kjøring.

5752147[/snapback]

 

Ja, dokumentasjon er jo noko som kunne ha redda litt av dagen, men det mangler jo selfølgeleg dokumentasjon også i dette systemet (så lenge "insert comment here" ikkje er godkjent dokumentasjon då )

 

Myten rundt at OO automatisk vil gi bedre system er selfølgeleg ikkje sann, men det ser ut som at det er ein tendens til at systemene blir bedre av at utviklerene har ein god OO-tankegang som ligg bak utviklinga og ikkje "hack and slash"-programmeringa som ofte blir brukt meir av hobby-programmerene.

 

 

No skal det seiast at konsulentar som er inne i prosjektet (10-15 års erfaring som utviklerer) meiner at det er noko av det værste som dei har sett.

Satser på at eg får godt betalt for å rydde opp i svinestien

[Ernie]

Ja, dokumentasjon er jo noko som kunne ha redda litt av dagen, men det mangler jo selfølgeleg dokumentasjon også i dette systemet (så lenge "insert comment here" ikkje er godkjent dokumentasjon då )

5752674[/snapback]

Huff Føler med deg. Når kommentarene er såpass på jordet så hadde jeg brukt to knapper, shift og delete.

 

Myten rundt at OO automatisk vil gi bedre system er selfølgeleg ikkje sann, men det ser ut som at det er ein tendens til at systemene blir bedre av at utviklerene har ein god OO-tankegang som ligg bak utviklinga og ikkje "hack and slash"-programmeringa som ofte blir brukt meir av hobby-programmerene.

5752674[/snapback]

Selvsagt min mening det her, men god OO-tankegang vil jeg påstå man blant annet unngår å lage en klasse man aldri lager flere objekt av. Jeg har fortsatt til gode å se en klasse bli brukt flere ganger i et PHP-script.

 

Når det er sagt, hvordan kan du si at systemer i PHP blir bedre av OO-tankegang når det virker som du sammenligner profesjonell utvikling med OO-tankegang mot særdeles uprofesjonell utvikling uten? Det nytter ikke å sammenligne profesjonell utvikling med ordentlig SU-modell mot hobbyprogrammerere som bedriver code & fix og cowboy coding.

 

No skal det seiast at konsulentar som er inne i prosjektet (10-15 års erfaring som utviklerer) meiner at det er noko av det værste som dei har sett.

Satser på at eg får godt betalt for å rydde opp i svinestien 

5752674[/snapback]

Vel, jeg tviler ikke på at det er grusomt kan man si

 

Edit:

Så da er masse kommentarer, skrevet med rettskrivning (ikke sms-språk som ikke går an å søke gjennom hvis man leter etter noe spess) og gode variabelnavn++ de beste tingene å ta med seg? Pluss stukturert kode i form av litt tab og sånn?

5752573[/snapback]

Indentert kode (innrykk i koden) og gode kommentarer som er lett å forstå er et must for å få god oversikt.

 

Er det "dumt" for hastigheten å lage lange og _veldig_ forklarende variabelnavn:

passord_for_md5

passord_etter_md5

eller betyr det lite når sidene er små hvertfall?

5752573[/snapback]

På små ting har det lite å si, men på store prosjekter går det dårlig å si $var, $data o.l. Det betyr derimot ikke at man skal holde på med $passord_for_md5 og $passord_etter_md5 (det skaper uoversikt, økt minnebruk og fare for feil). Det holder med en variabel kalt $passord.

Endret 14. mars 2006 av Ernie

[Sindre]

OOP er lurt og lære seg!

 

Skal du lage en personlig hjemmeside og ikke noe mer så kan det hende at det ikke er noen vits og lære seg OOP.

 

Driver du derimot med flere programmeringsspråk eller har lyst til og lære deg det, er det en utrolig stor fordel og lære seg OOP først som sist. Man kan ikke komme vekk fra OOP hvis man driver med nyere programmeringsspåk.

 

Skal du holde på med PHP på et avansert nivå vil du oppleve at koden vil bli mer oversiktlig og lettere og forholde seg til. Leser her at noen ikke er enig, men hvis begge kodene er bra dokumentert og indentert så vil en OOP kode være mer oversiktlig. Et av hovedpoengene er jo fordi det blir mindre kode og forholde seg til. På et stort prosjekt vil man selvfølgelig lage flere objekter av en klasse. Hvis ikke Ernie har opplevd dette så forstår jeg godt at han synes en kode uten OOP er lettere og mer oversiktlig og forstå.

 

Ser også at noen påpeker at PHP ikke er det beste språket for OOP, dette er jeg bare litt enig i. PHP har blitt kraftig forbedret siden versjon 4. og i versjon 5 har de rettet på veldig mange av de forbedringene som måtte gjøres på PHP 4. Men jeg har ikke brukt PHP så lenge til at jeg kan si at versjon 5 ikke har mangler den og.

[Ernie]

Skal du holde på med PHP på et avansert nivå vil du oppleve at koden vil bli mer oversiktlig og lettere og forholde seg til. Leser her at noen ikke er enig, men hvis begge kodene er bra dokumentert og indentert så vil en OOP kode være mer oversiktlig. Et av hovedpoengene er jo fordi det blir mindre kode og forholde seg til. På et stort prosjekt vil man selvfølgelig  lage flere objekter av en klasse. Hvis ikke Ernie har opplevd dette så forstår jeg godt at han synes en kode uten OOP er lettere og mer oversiktlig og forstå.

5755570[/snapback]

Altså, at OOP gir automatisk mindre kode er en av ørten myter rundt OOP, og bare så det er sagt, denne er også "busted".

Hvor du får det fra at OOP automatisk gir mer oversiktelig kode er for meg en gåte. Kan jeg få noen eksempler anyone?

[jorgis]

Det jeg synes er litt skøy med OOP er at det tillater parametrisk programmering (tror det var rett navn på det...):

 

$mail->compose($title, $message)
       ->add_headers($header, $var)
       ->send();

 

 

 

Men fra spøk til andre ting: OOP er et ganske nyttig verktøy, men som med alle verktøy må det brukes med fornuft. Ikke lag en klasse av en enkelt funksjon. Ikke bruk OOP på små, 100-linjers hjemmesider. Derimot er OOP uvurderlig om en f.eks. skal lage seg et plugin/extension/modul-system, eller lage mer avanserte systemer med modularisert arkitektur. Men for all del, styr unna OOP om du ikke vet hvorfor du trenger det.

[blackbrrd]

Litt av poenget med OOP er å skille kodebiter fra hverandre... Dvs at du jobber mot public delen av en klasse, du skal ikke trenge å vite i detalj hvordan klassen fungerer.

 

Poenget er å lage byggeklosser som du kan sette sammen og endre innvendig uten å måtte rive ned hele muren...

 

Av erfaring vet jeg at å skrive sql direkte når man jobber mot databaser uten å enkapsulere det man gjør på noe vis kan føre til relativt mye ekstraarbeid...

 

... Og når jeg snakker om databaser og OOP... Det er der en ORM (Object Relation Mapper) dukker opp... Har testet litt med Hibernate (www.hibernate.org) og jeg må si at den gjør jobbing mot databaser og korrekt bruk av OOP endel lettere. Dessuten går det hele mye fortere også, spesiellt når du kan lage databasetabellene og så få reverse engineeret klassene...

 

F.eks kan du ha følgende tabell:

CREATE TABLE kunde (

kundeid serial primary key not null,

navn text,

adresse text

);

 

og få generert en klasse med alt av get/set metoder og med lagring mot databasen automatisk generert... Du kan da skrive f.eks:

 

Kunde kunde = new Kunde();

kunde.setNavn("Ole");

kunde.setAdresse("Blåsbortgata 3");

session.save(kunde);

 

for å få lagret kunden... null skriving av sql, veldig lesbar kode, og hvis du f.eks skal sjekke adressen mot posten når du setter den så kan du legge den koden inn i setAdresse(String) metoden, og du slipper å tenke på den ellers...

 

Det er kanskje spesiellt under henting av data dette er praktisk...

 

Istedetfor å skrive kode som

 

String sql = "SELECT * FROM kunde WHERE kundeid = "+id;

ResultSet rs = con.executeQuery(strSql);

int kundeid = rs.getInt("kundeid");

String kundenavn = rs.getString("kundenavn");

String kundeadresse = rs.getString("adresse");

 

for så å bruke disse variablene i html'n som <%=kundenavn%>

 

Så kan du skrive

Kunde kunde = new Kunde(id);

session.load(kunde);

 

og bruke dataene i kunde-objektet senere i html med f.eks <%=kunde.getNavn()%>

 

Den siste måten å gjøre det på er vesentlig enklere å lese og skrive og definitivt mer objektorientert enn den første...

 

(koden jeg har skrevet er i Java hvis det var noen som lurte på det, ettersom det her er på php forumet, men poenget er det samme)

Endret 15. mars 2006 av blackbrrd

[Oracel]

Er det noe å spare på å programmere i OOP ?

 

Feks hvis jeg lager et script der jeg aldri kommer til å trenge noen av rutinene igjen til et senere prosjekt?

 

Aldri prøvd før, har holdt meg til functioner. Noe vits i å lære seg OOP?

5733955[/snapback]

Hvis du klarer å karre deg gjennom ungdomsskolen og VGS uten å få diagnosen ADHD, så kanskje du får muligheten til å prøve deg på en ingeniørhøgskole. Der vil du få mer enn nok øvelse i OOP, så det er ingen grunn til å ta sorgene på forskudd. Kanskje du kan studere noe litt mer passende i mellomtiden, f.eks. include_once(). Eller enda mer avansert, require() og require_once()! Da er du på vei altså! :thumbup:

[Sindre]

Skal du holde på med PHP på et avansert nivå vil du oppleve at koden vil bli mer oversiktlig og lettere og forholde seg til. Leser her at noen ikke er enig, men hvis begge kodene er bra dokumentert og indentert så vil en OOP kode være mer oversiktlig. Et av hovedpoengene er jo fordi det blir mindre kode og forholde seg til. På et stort prosjekt vil man selvfølgelig  lage flere objekter av en klasse. Hvis ikke Ernie har opplevd dette så forstår jeg godt at han synes en kode uten OOP er lettere og mer oversiktlig og forstå.

5755570[/snapback]

Altså, at OOP gir automatisk mindre kode er en av ørten myter rundt OOP, og bare så det er sagt, denne er også "busted".

Hvor du får det fra at OOP automatisk gir mer oversiktelig kode er for meg en gåte. Kan jeg få noen eksempler anyone?

5755596[/snapback]

 

Hvordan kan du si at OOP ikke gir mindre kode? hvis du skal lage en enkel hjemmeside så tror jeg nok ikke den gir så mye mindre kode, kan hende den blir endel lengere faktisk, men på større prosjekter blir det mye mindre kode. uten at jeg faktisk gidder og komme med noen eksempler eller noe. Gå inn på et java/C++ forum og komm med meningene dine så får du noe høre. Vil du ha noe støtte for det du sier kan du prøve et C forum, der er det sikkert noen (langt fra alle) som er enig med det.

[blackbrrd]

Bare så det er sagt, C er ikke spesiellt objektorientert, antar du mener C++

 

Funksjonsorientert programmering har sin plass, det går definitivt an å overdrive OOP og lagdelt arkitektur... Men å si at det er unødvendig å kunne OOP er å dra det veldig langt.

[Ernie]

Hvordan kan du si at OOP ikke gir mindre kode? hvis du skal lage en enkel hjemmeside så tror jeg nok ikke den gir så mye mindre kode, kan hende den blir endel lengere faktisk, men på større prosjekter blir det mye mindre kode. uten at jeg faktisk gidder og komme med noen eksempler eller noe.

5755895[/snapback]

Så synd, for da tror jeg ikke på det.

 

Gå inn på et java/C++ forum og komm med meningene dine så får du noe høre. Vil du ha noe støtte for det du sier kan du prøve et C forum, der er det sikkert noen (langt fra alle) som er enig med det. 

5755895[/snapback]

Altså, jeg har aldri sagt at OOP er ubrukelig (slik du hinter til). Det jeg sier er at det er ubrukelig i PHP fordi man aldri klarer å bruke det riktig eller faktisk har reele korrekte bruksområder uannsett. OOP er uunværlig i språk som C++ og Java, men der lager man da også klasser som det faktisk blir opprettet flere objekter av. I PHP derimot, har jeg bare sett det bli opprettet et objekt av klassen. Det er ikke god bruk av OOP etter min mening. Da burde man holdt seg til funksjoner. Samtidig unnskylder man seg med en masse myter om bedre vedlikehold, raskere koding, bedre oversikt og gudene veit hva. Endret 15. mars 2006 av Ernie

[Sindre]

Ok. spørsmål da, hvis man bruker OOP på en rett og bra måte, som du aldri har sett i PHP, er du da enig at koden kan bli lettere å vedlikeholde og den blir mer oversiktlig?

 

Enig i at koden ikke trenger og bli raskere. Kan faktisk bli tregere, men kan også bli raskere.

 

edit:leif

Endret 15. mars 2006 av Sindre

[allyse]

Ok. spørsmål da, hvis man bruker OOP på en rett og bra måte, som du aldri har sett i PHP, er du da enig at koden kan bli lettere å vedlikeholde og den blir mer oversiktlig?

 

Enig i at koden ikke trenger og bli raskere. Kan faktisk bli tregere, men kan også bli raskere.

 

edit:leif

5756830[/snapback]

 

 

Problemet er jo at det ikke er behov for dette i PHP, og at det da blir generelt sett feil slik som Ernie påpeker. Sett da at en programmerer en optimal OO og en som programmerer optimal sekv. kode så vil enda oo være tregere. Det er faktisk så mye tregere i php4 det er nesten oppsiktsvekkende. Mange hundre prosent. I php5 er det bedre, men si om en side lastes 50 millioner ganger og hver side har xxms delay pga oop så blir tallene som går til unødvendig serverkraft store.

[Ernie]

Ok. spørsmål da, hvis man bruker OOP på en rett og bra måte, som du aldri har sett i PHP, er du da enig at koden kan bli lettere å vedlikeholde og den blir mer oversiktlig?

5756830[/snapback]

Nei, men koden kan bli mindre kompleks ved at man lettere kan holde styr på fysiske objekter man skal modelere, noe som også er hele poenget med OOP. Derimot har det svært lite for seg i PHP da ingen ser ut til å opprette flere objekter av en klasse og hele poenget faller bort.

 

Enig i at koden ikke trenger og bli raskere. Kan faktisk bli tregere, men kan også bli raskere.

5756830[/snapback]

Nei, slik OOP blir brukt i PHP er det alltid treigere enn tilsvarende "procedural"-kode. I andre språk er det mulig dette ikke er tilfelle.

[allyse]

Støtter det Ernie skriver her. Som jeg skulle sagt det selv

[Peter]

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.