Ik ben zelf ook niet goed in OOPHP maar waarom ga je dit doen:

class User {  


public function register () {} 
public function login () {} 
public function settings () {} 


}

Die functie settings vind ik persoonlijk maar raar, waarom ga je settings in een functie steken? Ik zou het eerlijk gezegd zo doen:

class User_settings extends User { }

En dan zou je in principe die functies op protected kunnen zetten.

Om eerlijk te zijn is dit nog geen OO maar eerder classes en functies maken, OO is een denkwijze die hier nog niet echt klopt.

Ik zou zeggen ga eens in de source code van Wordpress of een andere open source kijken en leer daaruit, het is allemaal strict OOP dus de beste manier om iets te leren, de verschillende functies e.d kun je via de PHP.net site opzoeken.

Ik denk dat die methode het beste werkt om OO denkwijze te begrijpen. Uiteraard is veel lezen en doen ook een manier.

Citaat

Om eerlijk te zijn is dit nog geen OO maar eerder classes en functies maken, OO is een denkwijze die hier nog niet echt klopt.

Er wordt veel gezegd dat OO een denkwijze is. Daar ben ik het niet mee eens. Om goed object georiënteerd te programmeren moet je op een andere wijze denken, maar dat is iets anders dan wanneer object oriëntatie een denkwijze zou zijn.

Objecten
Wanneer je goed object georiënteerd wilt kunnen programmeren moet je weten wat een object, een eigenschap en een methode is. Object is eigenlijk gewoon een object, zoals de naam als zegt. Bijvoorbeeld een auto, een huis, een computer en een fiets. Wanneer je een website maakt zou dat betekenen dat objecten bijvoorbeeld een gebruiker is, een database, een databasetabel (!) en een reactie op een forum.

Methodes
Methodes zijn actief die met het object kunnen worden uitgevoerd. Een database kan bijvoorbeeld een query uitvoeren, en een reactie kan worden verwijderd, toegevoegd of worden beoordeeld.

Eigenschappen
Daarnaast heeft een object eigenschappen. Eigenschappen zijn waardes die afhankelijk zijn van de instantie van dat object. Een gebruiker kan bijvoorbeeld als eigenschappen een gebruikersnaam e-mail en voornaam hebben. Maar ook kan een gebruiker als eigenschappen zijn forum reacties hebben. Deze reacties zijn vervolgens dan zelf ook weer objecten, dit licht dan ook iets ingewikkelder. Een database heeft als eigenschappen bijvoorbeeld de naam, het aantal uitgevoerde query's en een type. Maar NIET het resultaat van de uitgevoerde query, tenslotte kan één database meerdere query's uitvoeren en dus meerdere resultaten opleveren. De resultaten zullen dus ook weer object op zich zijn (die wel weer toe kunnen behoren aan het database object).

Ik hoop dat ik dat een beetje duidelijk heb kunnen maken zo.

De wijziging die dein voorstelt zal ik dan ook niet doorvoeren. Hij breid 'User' uit met 'User_Settings' terwijl 'User_Settings' geen 'User' is, maar iets heel anders. 'Administrator' kan bijvoorbeeld wel 'User' uitbreiden, tenslotte is een administrator een gebruiker.

De user settings zijn denk ik de eigenschappen van de gebruiker, deze zou ik dus ook als eigenschappen in het object definiëren.

Daarnaast zou ik nog een object item, reply en database result toevoegen.

Ik zou je willen adviseren in je ontwerp ook de proporties (eigenschappen) toe te voegen, zo kunnen wij beter zien of je met een goed ontwerp van start gaat.

Een interessante manier om dit soort applicaties te ontwerpen is UML. Echter denk ik dat dat voor dit topic veel te ver gaat.

Ik ben benieuwd wat je er van maakt, en je kunt dus zeker nog feedback verwachten. Succes!:cheer:

Vraagje aan jou: Waar wil jij $db vandaan halen?
Is het niet slimmer om de user class te extenden naar db class?

En verder zou ik denk zelf login, register in een auth class zetten.
Dingen zoals settings dan weer in de user class.

Citaat

Is het niet slimmer om de user class te extenden naar db class?

Een gebruiker is niet bepaald vergelijkbaar met een database.

Mijn commentaar: Properties!

Ik zou het meer doen in de trend van:

<?php


class user { 
	protected $db;


	protected $data = array(
		'username' => '', 
		'password' => '', 
		'email'    => '',
	);
    
    
	public function __construct (array $values = array())
	{
		$db->connect();


		if(!empty($values)) {
			$this->values($values);
		}
	}
    
	public function register ()
	{
		if(empty($data['username']) OR empty($data['password']) OR empty($data['email'])) {
			throw new Exception('Not all values are set.');
		}
        
		//Registreren
	}


	public function values(array $values) {
		foreach($values as $key => $value) {
			if(array_key_exists($key)) {
				$data[$key] = $value;
			}
		}
	}


	public function login()
	{
		if(empty($data['username']) OR empty($data['password'])) {
			throw new Exception('Username and password has to be set.');
		}
		
		//Inloggen
	}
	
	/**
	* Ik heb deze laten staan, maar snap niet helemaal wat je me deze functie wil.
	*/
	public function settings ($setting, $value ) 
	{
		
		
	}


}


?>

@Killingdevil
Ik dacht dat ongevangen Exceptions zorgden voor een warning?
Dat is bij mij meestal het geval tenminste...

Richard op wat voor manier gebruik jij de exception dan?
Je kan het ook op deze manier gebruiken:

try
{
     if(empty($_POST['naam']))
     {
         trow new Exception('Er is geen naam opgegeven.');
     }
}
catch(Exception $e)
{
   echo $e->getMessage();
}

Zolang jij eigenlijk de exception echo't via bijv. zo'n catch dan moet hij het gewoon doen?

<?php


$user = new User(array('username' => 'Darsstar', 'email' => '[email protected]'));




try
{
	$user->register();
	mail(blabla); // wordt al niet meer uitgevoerd
	header('Location: woef.php;');
}
catch(Exception $e)
{
	// zorg dat de fout wordt weergeven
}

Wat ik duidelijk probeer te maken:
Dan moet je de Exceptions maar vangen!
Natuurlijk hoef je Exceptions niet op deze manier te gebruiken.

Dank je Darrstar. Je zegt precies wat de bedoeling is.

Exceptions hoef je niet in de functie zelf af te vangen (dat zou een leuke zijn, hoe kun je dan ooit een exception gooien?). De manier waarop ik ze in het voorbeeld heb gezet zijn ze nuttig om foutmeldingen te tonen of de code af te kappen als de actie niet lukt. Een makkelijkere en duidelijkere flow dan wanneer je FALSE of TRUE zou retourneren.

Maar dat geeft Darsstar al heel mooi aan met zijn voorbeeldcode.:)

Citaat van Killingdevil

Dank je Darrstar. Je zegt precies wat de bedoeling is.

Exceptions hoef je niet in de functie zelf af te vangen (dat zou een leuke zijn, hoe kun je dan ooit een exception gooien?). De manier waarop ik ze in het voorbeeld heb gezet zijn ze nuttig om foutmeldingen te tonen of de code af te kappen als de actie niet lukt. Een makkelijkere en duidelijkere flow dan wanneer je FALSE of TRUE zou retourneren.

Maar dat geeft Darsstar al heel mooi aan met zijn voorbeeldcode.:)

Ik denk dat je dat er beter direct even bij kon zetten dan. Veel mensen hier weten waarschijnlijk niet eens wat een exception is.

Dan kan ik er dus ook beter direct bijzetten wat een klasse is? En hoe waar je de accolades op je toetsenbord vind?

Als het niet duidelijk is kun je vragen.:) Daarnaast weet het internet gigantisch veel.(b)

Dit topic is wel interessant voor de beginnede OOP'ers, even een highlight voor maken(is nog eens lang geleden trouwens :p)?

Citaat van Killingdevil

Dan kan ik er dus ook beter direct bijzetten wat een klasse is? En hoe waar je de accolades op je toetsenbord vind?

Als het niet duidelijk is kun je vragen.:) Daarnaast weet het internet gigantisch veel.(b)

Misschien is het handig als je meteen onder alle posts de gehele qwerty keyboard layout zet :p