När vet man att det är dags att börja köra med Objektorienterad programmering (php) i sina arbeten?
Har försökt att förstå OOP under en väldigt lång tid men lyckas inte tillämpa det praktiskt. Känns som att jag slösar bort massor av tid på att försöka förstå OOP när jag istället kunnat ägnat tiden åt att lära mig att skapa nånting praktiskt istället.

Vad är era tankar angående objektorienterad programmering för nån (mig) som inte har läst omfattande datoringenjörskunskap?

Först måste du väll fundera på vad du vill åstadkomma. Behöver du skapa en inloggning eller en koppling till en databas, ja då är det dags att börja studera PHP eller något annat programmeringsspråk.

En duktig programmerare lär sig hela tiden nya saker. OOP är kanske inte lämpligt i all fall, men OOP är sällan fel. Sedan kan man arbeta OOP utan att för den delen arbeta med ett språk som har OO stöd. Men det är överkurs att förstå det... :-) men det korta svaret på din fråga är att OOP har sina fördelar och det finns väl ingen anledning till att du inte skulle använda det genomgående.

Det här kanske känns som ett personligt påhopp, men det är det inte. Men om du har problem med att förstå grundläggade programmeringsprinciper är det kanske inte programmering du skall fokusera på. Som wooper skriver bör du fudnera på vad du vill åstadkomma. Enklare fixar kanske du kan klara ändå, men du kanske borde fundera på om du skall fokusera på något annat. Du har kanske massor av bra idéer och ett sinne för affärer. Fokusera då på det tillsammans med någon annan som är en duktig programemrare. Eller så hittar du en bättre lärare :-)

IC, då kan jag med rent samvete ignorera OOP och bara försöka bli bra på procedural formen istället.

Jag skulle vilja påstå att det i många fall är lättare att skriva bra kod om man jobbar objektorienterat. Dessutom finns det större möjligheter att på ett enkelt sätt utveckla koden vid ett senare skede om man använder OO. Därför är det aldrig fel att lära sig OOP.

Jag har samma problem, PHP programmeringen flyter på jätte bra men har inte riktigt förstått hur man tillämpar OOP.
Läst lite guider och så och jo, jag förstår poängen med det. Men hur tillämpar man det :blink:

Finns säkert någon som kan tipsa om någon bok eller något där de beskriver från grunden upp till lite mer avancerad OOP i PHP?
Då skulle både jag och wizzo nog bli glada :)

Nu kanske det här låter lite knas, jag lärde mig grunderna i PHP och hoppa sedan på Ruby on Rails ( ca 3 månader sedan ).

Och mycket av det jag lärt mig nu av RoR skulle jag kunna använda till fin och effektiv kod i PHP.

Agile, DRY, RESTful development och givetvis OOP.

Blaha blaha.

Säger två saker, papper o penna :)

men värt o läsa
http://www.webmasterstop.com/56.html

Jag kodar inte allt i oop, men vissa saker passar perfect i OOP medans andra saker inte passar.

hehe, ja om du inte vill bli en duktig programemrare i alla fall... :-)

I små till medelstora system tycker jag det är mer en smaksak om man vill köra oop eller inte. Det är väl egentligen aldrig fel att köra i OOP, men det kan ibland ge onödigt "komplicerade" filer kan jag tycka....

Men däremot om du bygger ett större system kan det vara en bra ide. Alla har väl ett eget sätt att programmera och lägga upp saker och ting, själv brukar jag köra med vad jag kallar moduler som mer eller mindre bara är ett sätt att struktera funktioner och annan kod så att man får en bättre överblick. Många gånger så ska personen jag kodar åt själv kunna gå in i koden och göra ändringar... därför viktigt att det är så simpelt och strukturerat som möjligt.

Använder man php så skulle jag nog säga att det beror på vad man vill åstadkomma.

1. Vill man bara skriva ut dagens datum på sidan eller liknande så är php utmärkt för att bara klämma in lite kod hur som helst likt SSI.

2. För enklare funktionalitet kan man använda funktioner (funktioner kan sedan lätt byggas in i objekt) - t.ex. räkna fram morgondagens datum.

3. Har man någon form av webbapplikation (formulär, automatiska utskick, webbshoppar, CMS:er, databashantering), särskilt om den har flera sidor, så måste man nästan använda OOP. I synnerhet bör man alltid använda OOP om man har variabler som kan sägas höra ihop med funktioner. Till varje funktion för databasuppkoppling hör en användare och ett lösenord, för varje epost du skickar hör en mottagare och en avsändare - för detta är OOP optimalt eftersom det blir busenkelt att skicka två mejl eller starta två separata databasuppkopplingar, det är bara att skapa så många objekt man behöver, varje objekt kommer då innehålla den relevanta informationen utan att man behöver hålla reda på det och skicka med det vid funktionsanrop.

Objekt (och poängen med objektorienterad programmering) är egentligen bara att tillhandahålla en "förpackning" för funktioner och variabler så att man får lite mer ordning.

Jag har sett det vackra med OOP men jag kan inte fatta hur man plockar ut och ersätter dem förinstallerade kugghjulen för eget bruk.
Jag har bland annat läst detta stycke från en bok men fattar inte vad dem menar med att
procedural lägger vikt på funktioner medans OOP lägger vikten på variabler. Kan nån förklara detta synsätt med vardagssvenska?


The big advantage of classes is that they let you define variables and the functions that use them together in one place, while keeping the functions hidden from unrelated code. This highlights one of the key theoretical point about the object oriented paradigm.

• The procedural paradigm places most emphasis on functions, variables being treated as little more than a place to store data between functions calls.
• The object oriented paradigm shifts the emphasis to variables; the functions "back" the variables and are used to access or modify them.

De menar helt enkelt att om du programmerar proceduralt så får du själv hålla reda på dina variabler - programmerar du objektorienterat så sköter objekten detta åt dig.

Se det hela som en fabrik. Du en massa maskiner (funktioner) som kan göra olika saker. För att tillverka något behöver du dessutom en massa material (variabler). Om du programmerar proceduralt så har du en massa väloljade maskiner men du har allt materialt spritt utöver hela fabriken. Om du däremot programmerar objektorienterat så har du rätt material liggande vid varje maskin och hela processen går snabbare och är enklare. Framförallt är risken mindre att du som programmerare bladar ihop material och skapar kaos i maskineriet…

Det är möjligt att den här förklaringen inte hjälper dig ett dugg men när du väl satt igång kommer du märka hur praktiskt det är att slippa tänka vilken variabel var det nu jag behövde för det och var finns den, etc.

Exempelvis så kan du använda ett beställningsobjekt där du kan hämta och spara adress, namn samt skicka beställningen - mycket enklare än att ha en funktion där du måste mata in namn, adress osv. varje gång när du skickar:

$olles = new Beställning("Olle", "Vägen 43", "Nånstad");
$olles->addProduct('Pepparkakor'); //Lägg till och ta bort produkter (till Olles besällning)
$olles->sendOrder(); //Beställningen skickas - all nödvändig information finns i objektet $olles
(Olle gör en beställning - objektet håller reda på vem som beställer, vart beställningen skall skickas osv.)

Det här är den bästa teoretiska OOP sidan jag träffat på hittills mer lärorikt än den bok jag kämpat med!!
http://homepages.north.londonmet.ac.uk/~ch...r/sitemap1.html

Den känns ju inte så värst modern… men den kanske har ett bra innehåll. :D

Jag håller med, men det är också lättare att skriva dålig kod om
man använder OOP. I alla fall som nybörjare. Det är lätt att fascineras
av arv och polymorfism och börja använda det både när det är lämpligt
och när det är olämpligt.

Om man är på väg från procedural programmering till OOP, så tror jag
det är bäst att bara fokusera på inkapsling till att börja med och senare
använda arv/polymorfism bara när det är absolut nödvändigt.