Hvordan organisere korrekt OOP?

[Mads-b]

God kveld godtfolk!

 

Jeg utvikler for øyeblikket et OOP-system mer komplisert enn den kvinnelige psyke for hjemmesiden min. Hovedmålet er vel egentlig å lære riktig OOP-teknikk, men jeg trenger noen føringer.

 

Jeg begynte med noen low-level klasser for arbeid bak kulissene. *tenke* Jeg har en IO-klasse for databasebehandling, queries etc. All databehandling mot SQL går gjennom den. Jeg har en template-klasse du mater inn data i, gjerne sammen med IO-klassen, for å skape en nettside. Jeg har en config-klasse du mater inn config filer i, som serverer instillingene til nettsidene jeg utvikler.

 

Disse klassene er artige å utvikle hver for seg, men jeg sliter litt med Medusa. Altså: Når jeg skal bruke disse klassene i forskjellige sider, starter jeg gjerne med en klasse som fòrer template-klassen med data. Jeg føler disse klassene blir litt vel prosedyriske, da de kun kan brukes til å vise den siden de er laget for. Jeg tenker bare: hvorfor lage en klasse for dette når jeg egentlig bare stykker opp kilovis med prosedyrisk kode?

 

Så siste problemstilling: Når jeg skal bruke sistnevnte klasse, blir det en hel bunch med prosedyrisk, ala:

new container

 

if(login)

new adminpanel

output = adminpanel->userlist

endif

if(!login)

output = adminpanel->login

endif

 

container->put output into content area

print container

 

Gjerne litt mer avansert også.. Er det virkelig sånn man må gjøre det? Føler liksom ikke at jeg "vinner" på å kjøre OOP her. Low-level klassene er greie nok, de hjelper på kodebesparing, men når jeg skal kople dem sammen for å gjøre noe fornuftig, ser jeg ikke helt hensikten med å lage klasser, når jeg i realiteten bare stykker opp en shitload med prosedyrisk.

 

Noen tanker eller en oppskrift til meg?

Endret 20. juni 2009 av Mads-b

[Jonas]

Gjerne litt mer avansert også.. Er det virkelig sånn man må gjøre det? Føler liksom ikke at jeg "vinner" på å kjøre OOP her.

Nope, slik vinner du ingen ting. Når du blir fortalt at OOP er veien å gå, det er mer riktig - så holder det ikke bare å programmere OO. Du kommer til å møte akkurat samme problemer der, som du gjorde før. OOP tillater på den andre siden en del mer fancy ting; teknikker for å håndtere vanlige problemer. Man kaller dette for patterns og omtrent alle baserer seg på OOP. Å prøve å lære seg nytteverdien av OOP uten å bruke et design pattern vil være rimelig nytteløst etter min mening. Ta f.eks. en titt på Zend sine saker, som bl.a. implementerer MVC.

[Mads-b]

Gjerne litt mer avansert også.. Er det virkelig sånn man må gjøre det? Føler liksom ikke at jeg "vinner" på å kjøre OOP her.

Nope, slik vinner du ingen ting. Når du blir fortalt at OOP er veien å gå, det er mer riktig - så holder det ikke bare å programmere OO. Du kommer til å møte akkurat samme problemer der, som du gjorde før. OOP tillater på den andre siden en del mer fancy ting; teknikker for å håndtere vanlige problemer. Man kaller dette for patterns og omtrent alle baserer seg på OOP. Å prøve å lære seg nytteverdien av OOP uten å bruke et design pattern vil være rimelig nytteløst etter min mening. Ta f.eks. en titt på Zend sine saker, som bl.a. implementerer MVC.

Jeg tipper at med design patterns mener du at programmet bør lages med gode gamle penn-og-papir før man skriver en linje. Jeg gjorde det, og produserte disse kjempefine klassene som behandler databaser og råfiler og spytter ut litt mer brukbar data. Dette viste meg elegansen ved OOP. Jeg kan bare kalle på klassen for å behandle en templatefil, for eksempel, og oppdateringer i en klasse ødelegger ikke resten av scriptet, så lenge funksjonene serverer riktig output. Problemet oppstår når jeg prøver å kombinere disse klassene for å gjøre en nyttig jobb.

 

Problemet oppstår når jeg skal bruke denne "nyttige" outputten til å gjøre noe fornuftig. Greit nok, jeg bruker databehandlingsklassene mine i mange forskjellige prosjekter, men hvis jeg skal kalle på dem fra en annen klasse, ser jeg ikke poenget med å kalle på dem derfra, i stedet for å bare slenge det ut i good ol' procedural. Jeg har ikke et sekunds tvil på at databehandlingsklassene mine er feil vei å gå, jeg bare vet ikke hvordan man implementerer dem i et prosjekt med spesifikke bruksområder. Det føles bare så... uelegant når jeg prøver.

Endret 20. juni 2009 av Mads-b

[Jonas]

Jeg tipper at med design patterns mener du at programmet bør lages med gode gamle penn-og-papir før man skriver en linje.

Langt ifra, ta en nærmere titt på linken jeg sendte. Og se spesielt på Zend sin MVC-implementasjon.

[Mads-b]

Hmm. Jeg bør kanskje "get my shit together" og lære dette før jeg begynner på en programmeringslinje på NTNU.. Makes life easier..

 

Ok. La oss se om jeg har forstått riktig: MVC-konseptet er en tredeling av klasser. Det er en modell der applikasjoner består av tre "ingredienser", og hvordan de kommuniserer.

 

Slik jeg har forstått det er det ikke nødvendig at alle klassene man skriver til et program er gjenbrukbare i annen programvare. Controller-klassene, for eksempel, er applikasjons-spesifikke. Da føler jeg at jeg ikke er så langt unna med mine klasser ihvertfall.

 

La oss ta en enkel gjestebok som eksempel. Model-klassen har instruksjoner om sletting, endring og oppretting av poster i en database. I tillegg har den funksjonalitet som kan fòre view-klassen med data den bruker i visning av siden.

 

Controller-klassen er nettopp det, en kontroller. Den tar brukerinput (som POST og GET vars) og leverer instrukser til view-klassen om hva som vises.

 

View-klassen tar da og henter info fra modellen, og prosesserer det til bruker-leselig output.

 

Har ikke peiling om jeg er i nærheten av rett spor engang men..

 

Isåfall, er dette en view-klasse?:

class blog { //Essentially a template handling class..
private $blog;
private $curDir;
public function __construct($curDir) {
	$this->curDir = $curDir;
	$this->blog = new template('blog/blog.tpl'); 
	$this->blog->parse('blogPage'); //Extract relevant portion og template file
}

public function showPosts($from,$to,$fullStory = FALSE) {
	$blogPosts = blogPost::getBlogPosts($from,$to); //blogPost, model class? Retrieve data
	foreach($blogPosts as $blogPost) 
		$this->blog->set('blogPosts',array('blogPost'=>$blogPost->applyTemplate($fullStory))); //put model data into template
	return $this; //method chaining
}

 

Det er en ultrasimpel blogg jeg skriver.. Klassen blogPost (håper?) tror jeg er en model-klasse, og den inneholder funksjoner som saveChanges, deletePost etc..

[fhugas]

Vet ikke om det er dette du er ute etter, men det har tennt et lite lys for meg iallefall.

 

Singleton design pattern

 

Tok meg noen år med $database = new databaseclass(); og et underlig system for å holde orden på alle classene slik at jeg fikk de global på en merkelig måte.

 

Så oppdaget jeg singleton metoden, og har begynt å skrive om hele prosjektet jeg har jobbet med i det siste