PHP är ett programmeringsspråk som är väldigt förlåtande och tillåter programmeraren att skriva lite hur denne vill. Det går att skriva procedural (koden körs steg för steg från början tills slutet) likväl som äkta objektorienterad (OO) kod. Även OO går att skriva i olika nivåer, allt från klasser som egentligen bara är funktionshållare, och därmed inte har någon egentlig mening (förutom för att eventuellt ha ett namespace om det finns kollisioner), till arv, implementera intefaces o.s.v.

Jag tänkte i denna serie med poster (återstår att se hur många det blir) ta upp hur jag anser att PHP bör skrivas för att vara så tydligt som möjligt så att även andra kan ta över koden utan något större problem.

1. Skilj på vad som är en entitet och vad som är en service-klass

• En Entitet är ett objekt som har ett tillstånd (state). T.ex. ett User-objekt eller ett GuestbookPost-objekt.
• En Service är ett objekt som inte har något tillstånd (state) och utför saker (algoritm). T.ex. ett UserMapper-objekt eller GuestbookPostMapper-objekt.

Ett User-objekt är t.ex. en användare som skriver i en gästbok. Denna användare har ett tillstånd (namn, mailadress etc) och ett GuestbookPost-objekt är en post i en gästbok och har också ett tillstånd (rubrik, text, id på användaren som skrivit inlägget, datum etc.).

Ett UserMapper-objekt är en service som skapar användare när de registrerar sig för att skriva i gästboken och hämtar även användare för att skriva ut författarens namn vid ett gästboksinlägg. Objektet har antagligen tillgång till en databaskoppling och kan koppla upp och mata in och hämta användarens data där.
Anledningen till att denna typ av sericeobjekt behövs är att PHP är stateless, d.v.s. när en sida laddats klart försvinner alla tillstånd som skapats. För att kunna återskapa dessa tillstånd lagras tillstånden exempelvis i en databas och ovan nämnda serviceklassers jobb är att spara nya och återskapa tillstånd för entitetsobjekt.

2. Statiska och globala objekt

Nej, man använder sig inte av globala/statiska objekt eller skapar service-objekt inuti klasser. Anledningen till detta är att det blir helt omöjligt att sätta sig in i koden om det är någon annan som skrivit den. Klasser vars beroenden inte tydligt syns får vem som helst att sucka och ge upp. Vi kommer till detta längre fram i serien.

3. Struktur på filnamn, klassnamn och klassinnehåll

Döp filerna efter klassnamn, döp klasserna efter vad de är/gör och se till så att en klass enbart har en uppgift! Detta kan ses självklart, men är alltför ovanligt. T.ex. så ska inte klassen UserMapper göra mer än att vara en hanterare av User-objekt. Den ska inte kunna formatera text eller veta hur man kopplar upp sig mot databasen. Filen ska givetvis heta UserMapper.php.

Detta får bli en snabbstart på denna serie, så ska jag till nästa gång ha med lite kod-exempel för att konkretisera bättre.