Lære OOP ordentlig?

[Sk!ppy]

Hei.

 

jeg har programert php siden jeg var 10, nå 14,75 år gammel.

 

Jeg har ikke særlig kunnskap innenfor OOP, men gjør mitt beste, og vil ha bedre kunnskapp innenfor OOP da jeg oppfatter det som mer ryddig, om man kan det.

 

jeg kan såpass:

 

class cats {
Public function dog() {
print 'Dogs dont like cats';
}
}
$var = new cats;
print $cats->dog();

 

og litt sånnt, men har ikke helt forstått poenget med public og private - mer enn at public kan det brukes utenfor classen og private er kun i classen. om det er riktig?

 

ville også lært om extend, moduler o.l.

 

noen som ville lagt meg til på msn e.l og gitt meg råd og hjelp når jeg spør?

[BlueEAGLE]

Jeg vil ikke legge deg til på MSN, men jeg hjelper gjerne med generelle OOP-relaterte spørsmål.

 

En av hovedgrunnene til å bruke OOP er at du får gruppert data og funksjoner i lett manipulerbare strukturer. Du har en større mulighet til å skille komponenter fra hverandre og tvangen til å sende data eksplisitt imellom klasser gjør at du får renere grensesnitt og med større frihet kan endre en del uten å ødelegge alle andre.

 

private-funksjoner og variabler kan kun nyttes av klassen selv og er ikke tilgjengelig for funksjoner utenfor.

 

Grunnen til å bruke private er når en endring av en variabel ikke kan gjøres uten at annen kode kjøres samtidig.

 

La oss si at du har et register med folk som er logget på samtidig for eksempel.

 

Det kan være at du vil at andre funksjoner skal kjøre når en person har vært inaktiv en stund. For eksempel så vil du opprette en brukerklasse som leser inn brukerspesifikke preferanser, men du vil også kalle en klasse som er ansvarlig for en liste med påloggede brukere slik at denne kan oppdatere seg selv og på den måten slipper å gå igjennom alle brukerobjektene hver gang den skal skrive ut en liste med påloggede aktive og inaktive brukere.

 

Koden blir da noe slik

class user
{
 private:
$is_active = false; //Indikerer om brukeren er aktiv
 public:
set_active($status); //Dette er en prototype for funksjonen som setter en bruker til aktiv eller inaktiv.
...
function set_active($status)
{
  $this->is_active=$status;
  userlist::update_status($this->username, $status); //userlist er her en singeltonklasse og det ligger langt ute i pensum.;)
}
}

....

foreach($user_list as $user)
{
 if($user->last_active_time < now()-$this->timeout)
$user->set_active(false);
}

 

Hvis du ikke har beskyttet is_active så er det veldig fristende å bare bruke $user->is_active=false; men da vil du ikke få oppdatert userlist automagisk.

 

Håper det forklarer litt av konseptene du er ute etter.

 

Når det gjelder å utvide klasser med arv så har jeg ganske god erfaring og kan være til hjelp, men moduler har jeg ikke satt meg så godt inn i enda.

[Thomas.]

userlist::update_status($this->username, $status);

 

Hva er dette/hva brukes det til?

Vet at det er noe med static.

 

Er det userlist som er klassen, også er update_status en funksjon i den klassen?

Endret 27. januar 2010 av Thomas.

[Jonas]

Userlist er en klasse og update_status er en statisk metode i den. Ser det blir kalt for singleton pattern ovenfor, men det stemmer ikke helt. Å kalle en statisk metode i seg selv er ikke singleton. Singleton handler om å opprette en instans av objektet og kunne hente denne instansen fra hvor som helst i koden.

 

http://en.wikipedia.org/wiki/Singleton_pattern#PHP

Endret 27. januar 2010 av Jonas

[Alex Moran]

Metoder og egenskaper definert som public er tilgjengelig både internt i klassen og utenfra. Når de er definert som private er de kun tilgjengelige fra klassen som definerte dem. Med protected er dem bare tilgjengelig av klassen de ble definert i og eventuelle klasser som arver fra denne.

 

Når en klasse arver (extender) en annen, får denne klassen tilgang på metoder og egenskaper definert i foreldreklassen såfremt de ikke er private. Inheritance kan brukes når man kan si at klassen har en is-relasjon, f.eks. An apple is a fruit =>

class Apple extends Fruit {}

eller når det er metoder som går igjen som f.eks. når du har flere adaptere til en databaseklasse. class MySQLConnection extends \DBAL\AbstractConnection {}. Her vil naturligvis mye være likt og det kan være greit å extende. Har dem ikke har en slik relasjon (has, f.eks) er det composition du er ute etter. A family has children.

class Family {
protected $children = array();

public function addChild(Child $child) {}
}

 

Ellers er dette ord som er relevante i OOP-sammenheng: composition, polymorphism, inheritance. I tillegg bør du se på MVC, ORM og andre design patterns om du skal lage noe vettugt.

Endret 27. januar 2010 av Josh Homme

[Sk!ppy]

Jeg har tenkt å lage mitt eget lille MVC, ivertfall prøve.

 

Jeg tenker da på mappestruktur.

 

Jeg tenker litt sånn:

 

config/

class/

models/

includes/

template/

tmp/

 

Config - Alt omhandlene database

Class- Klassene

Models - Plugins

includes - Alle filer som skal includes

template - designet

Tmp - Cache og sånnt

 

 

Jeg vil lage egen class for databasen, så jeg kan f.eks bruke $database->update('table', 'field', 'value');

 

Uavhengig, om det er MySQL eller annen form for database. - Dette er jo en egen class, burde den ligge i config eller class da? Den omhandler databse, men er en class?

 

og hva synes dere om mappestrukturen min?

Endret 28. januar 2010 av Sk!ppy

[quantum]

Jeg har tenkt å lage mitt eget lille MVC, ivertfall prøve.

 

Jeg tenker da på mappestruktur.

 

Jeg tenker litt sånn:

 

config/

class/

models/

includes/

template/

tmp/

 

Config - Alt omhandlene database

Class- Klassene

Models - Plugins

includes - Alle filer som skal includes

template - designet

Tmp - Cache og sånnt

 

 

Jeg vil lage egen class for databasen, så jeg kan f.eks bruke $database->update('table', 'field', 'value');

 

Uavhengig, om det er MySQL eller annen form for database. - Dette er jo en egen class, burde den ligge i config eller class da? Den omhandler databse, men er en class?

 

og hva synes dere om mappestrukturen min?

 

Uhm, du skal lage et MVC, javel. Altså, når det gjelder database så ville jeg lagt databaseklassene i Class, evt. Class/Database kanskje? Det du legger i Config vil typisk være konfigurasjonsparametre av ymse slag, når det gjelder database vil du kanskje legge brukernavn, passord, host, databasenavn mv. i en fil i Config.

 

Forøvrig, MVC er et pattern, og du skal lage et rammeverk som gjør det enklere å implementere dette da? Litt på samme måte som Struts for Java? Akkurat hvorfor du vil blande databasefunksjonalitet inn her er litt uvisst. Det hører ikke naturlig hjemme i et MVC-rammeverk. Isteden er det opp til de som bruker rammeverket å aksessere en database via Delegate->Facade->DAO.

[Sk!ppy]

Da har jeg kanskje oppfattet MVC litt feil?

 

Jaja, men, jeg synes det er veldig vanskelig og forstå de tutorialene jeg har lest (google mvc framework php tutorial).

 

men jeg skal lese , lese og lese isåfall.

[BlueEAGLE]

Det er ikke dumt å ha et stort prosjekt i sikte, men da må du være klar over at du kommer til å måtte redesigne hele greia flere ganger fordi dette er en læringsprosess og du kommer garantert ikke til å ta de beste valgene på første forsøk.

 

Det som nok er mest fornuftig etter min er faring er å lage små ting som gjør det du vil legge til i systemet ditt helt og holdent for seg selv og så få dette til å virke med systemet.

 

Jeg anbefaler at du ikke klipper og limer kode og heller ikke skriver verbatim av tutorialer.

 

Les tutorialene og koden og finn ut hvordan den virker så implimenterer du det selv med dine helt egne variabler som vil gi mening også i systemet ditt.

[quantum]

Da har jeg kanskje oppfattet MVC litt feil?

 

Jaja, men, jeg synes det er veldig vanskelig og forstå de tutorialene jeg har lest (google mvc framework php tutorial).

 

men jeg skal lese , lese og lese isåfall.

 

Neida, greia er bare at MVC er et mønster/pattern, og som sådan er det allerede «lagd». Innenfor programmering er det definert en rekke mønstre for hvordan man implementerer vanlig funksjonalitet, som f.eks. brukergrensesnitt (MVC).

 

Det du kan gjøre er enten å bruke dette mønsteret (evt. sammen med et rammeverk som støtter det) når du lager et program med brukergrensesnitt, eller finne opp et annet og enda smartere mønster for hvordan man skal utforme slike programmer. Det siste vil nok kreve en god del grublerier :-)

 

I et program med brukergrensesnitt (eller uten for den saks skyld) bruker du selvfølgelig andre mønstre også i skjønn forening, for eksempel mønstre for programmering mot databaser (Data Access Objects - DAO mv.) Kommentaren min om at MVC ikke har noe med databaser å gjøre handler om at pattern/mønstre bør være mest mulig avgrenset og "self contained" slik at en står friest mulig til å kombinere de mønstrene man trenger og utelate de man ikke trenger. Se for deg at du skulle lage et batch-program uten brukergrensesnitt, og at MVC-mønsteret også omfattet databasefunksjonalitet. Da ville du enten måtte implementere overflødig MVC-kode i batchprogrammet ditt, eller dele opp mønsteret.

 

Når det gjelder sammenhengen mellom OOP og patterns er det vel ikke så mye generelt å si annet enn at den er «løs». Et pattern kan godt være (tør ikke si bør være) så generelt at det ikke legger føringer på hvilke språkegenskaper som behøves for å implementere det. Samtidig impliserer patterns ofte visse strukturer som OO ofte egner seg til å implementere, et naivt og nærliggende eksempel kan være å implementere klassene Model, View og Controller. Men i mange web-applikasjoner er view bare en drøss html-templates med litt ekstra dilldall og faller da utenfor OO, men ikke utenfor MVC-mønsteret.

 

Generelt er det veldig greit å vite litt om patterns, så hvis du likevel googler "MVC" så ta gjerne en runde med "programming patterns"-googling også.