Nu is deze vraag al waarschijnlijk 100 keer gesteld. Maar ik krijg het er bij mij zelf niet in waarom ik OO moet gaan gebruiken.
Ja, ik zie het voordeel van Object oriented programmeren. Maar ik zie niet waarom ik Classes moet gebruiken. Nu heb ik in de tijd dat ik van OO afweet in PHP tot nog toe nooit een echt groot project gehad waarvan ik zeg dat OO echt nodig is.
Nu ben ik echter bezig met een tool, waarbij ik echt volgens mij doen al OO werk, maar niet het voordeel zie van Classes etc...
Als ik dan zoek naar Waarom OO? krijg ik het antwoord "omdat je bepaalde functies kan her gebruiken" Dan kom ik eigenlijk tot de conclusie dat ik al OO denk wanneer ik bijvoorbeeld een centraal bestand heb met daarin functions die ik dus hergebruik.
Ook omdat ik bijvoorbeeld voor een inlog scherm al het bestand inlog.php include. (ik noem maar wat)en die aanpas als er wat moet gebeuren...
Nu ben ik dus niet opzoek waarom OO, maar ik ben eigenlijk opzoek die bij mij de knop kan omzetten om OO te gaan programmeren met de bijbehorende objecten, classes etc.
Ik kom ook nooit uit het voorbeeld van de auto... Boeiend dat deze blauw moet zijn...
Graag hoor ik het ook als ik echt compleet de bus mis en bovenstaande kant noch wal raakt.. Ik probeer bij mij zelf die knop om te zetten....
Hier geef ik je de tip om wanneer mogelijk een interface te gebruiken omdat je waar mogelijk moet programmeren naar een interface en niet naar een implementatie toe.
Reshad, waarom is dit? Kun je dat eens uitleggen? Mij lijkt het juist handig om een abstracte class te gebruiken omdat de constructor en class property telkens hetzelfde zijn. Het enige dat verschilt is de validate functie. De rest is idem. Is dan een abstracte class niet handiger?
Mij lijkt het juist handig om een abstracte class te gebruiken omdat de constructor en class property telkens hetzelfde zijn. Het enige dat verschilt is de validate functie. De rest is idem. Is dan een abstracte class niet handiger?
Hier hoort validate() juist in de interface. De interface schrijft voor dat alle implementaties de methode validate() moeten hebben, maar niet hoe die wordt ingevuld.
Een abstracte klasse gebruik je vooral voor gedeelde of gemeenschappelijke standaardcode. Dat is in dit geval dan niet validate(), want die methode verschilt per klasse.
Je kunt een abstract class maken die de interface implementeert.
Als jij type hint op een abstract class, dan MOET het een instantie van een child van die class zijn.
Als jij type hint op een interface, dan kan het een instantie van elke class zijn ZOLANG het die interface maar implementeert.
>> Hier hoort validate() juist in de interface. De interface schrijft voor dat alle implementaties de methode validate() moeten hebben, maar niet hoe die wordt ingevuld.
Dat doet een abstract class toch ook? De hele class is verder precies hetzelfde, alleen de validate method verschilt per class, dus die maak je dan abstract. Als je een interface gebruikt ga je telkens dezelfde code opnieuw schrijven, terwijl je als een abstracte class gebruikt de childs alleen maar een validate method hoeven te hebben. Daar is een abstract class toch voor bedoeld? Als je gebruikmaakt van een interface, dan maakt het niet uit hoe de classes eruit zien, zolang ze maar de methods uit de interface ondersteunen. Bij een abstract class is de class feitelijk al klaar, alleen de abstracte methods, in dit geval de validate method, moeten nog worden ingevuld door de childs. Dat is dan toch een logischere oplossing dan een interface in dit geval?
Nee, in een abstract class zijn de methoden vaak al gebruiksklaar. De validate() is er dan al in alle afgeleide klassen en die moet dus ook al functioneren. In een abstract class kan een methode zelfs final zijn en dan kán een child class niet eens meer een andere validate() implementeren. Moet elke child class echter een eigen validate() implementeren, dan dwing je de aanwezigheid daarvan af in een interface.
Je kunt inderdaad in de abstract class een validate() opnemen die door child classes mag worden overschreven. Maar dan is onduidelijk of dat ook moet. Dat kun je enkel in de interface afdwingen.
Methods defined as abstract simply declare the method's signature - they cannot define the implementation.
When inheriting from an abstract class, all methods marked abstract in the parent's class declaration must be defined by the child.
Hier staat dat abstracte methods juist geen functionaliteit mogen bezitten en moeten worden ingevuld door de child class. Dat lijkt niet overeen te komen met wat jij zegt "Nee, in een abstract class zijn de methoden vaak al gebruiksklaar.", of ik begrijp je verkeerd.
Een abstract class kun je niet instantiëren: je kunt er geen objecten mee maken. Maar je kunt er wel degelijk standaardmethoden in onderbrengen. Je kunt ze zelfs final maken, zodat child classes allemaal dezelfde implementatie gebruiken.
Even een voorbeeld. We hebben "een betaalmethode", maakt niet uit welke. Daarvoor hebben we altijd een te betalen bedrag $Amount nodig. En aangezien we sowieso nu al een bedrag hebben, voegen we voor de volledigheid een getAmount() toe:
<?php
abstract class AbstractPayment implements PaymentInterface
{
protected $Amount;
final public function getAmount()
{
return $this->Amount;
}
}
?>
Dat bedrag moet er nog in als we een object maken. Alleen hanteren verschillende betaalmethoden verschillende bedragen. De verplichte aanwezigheid van een setter setAmount() formaliseren we in de interface:
<?php
interface PaymentInterface
{
public function setAmount($amount);
}
?>
Hiermee hebben we een prototype dat altijd een bedrag $Amount heeft, dat altijd met de universele getAmount() kan worden opgevraagd en dat altijd met een unieke setAmount() moet worden ingesteld. Daarmee kunnen we tot slot verschillende betaalsystemen ondersteunen, bijvoorbeeld iDEAL voor bedragen van € 0,84 t/m € 10.000 en MrCash voor bedragen van € 0,49 t/m € 5.000:
<?php
class iDEALPayment extends AbstractPayment
{
public function setAmount($amount)
{
if (is_int($amount) && $amount >= 84 && $amount <= 1000000) {
$this->Amount = $amount;
} else {
throw new Exception('Invalid iDEAL amount.');
}
return $this;
}
}
class MrCashPayment extends AbstractPayment
{
public function setAmount($amount)
{
if (is_int($amount) && $amount >= 49 && $amount <= 500000) {
$this->Amount = $amount;
} else {
throw new Exception('Invalid MrCash amount.');
}
return $this;
}
}
?>
class Bike implements Moveable
{
public goTo(Location $location)
{
...
}
}
function driveTo(Car $car, Location $location)
{
return $car->goTo($location);
}
function goTo(Moveable $object, Location $location)
{
$object->moveTo($location);
}
driveTo(new Bike, new Home); // werkt niet
goTo(new Bike, new Home); // werkt wel
?>
Interfaces zijn flexibeler. Interfaces zijn meer future proof. Als ik was begonnen met een abstract Car class zonder interfaces, en later blijk een class Bike ook nodig, dan zal ik moeten refactoren. Als ik meteen een interface had gebruikt hoefde ik alleen maar de classe Bike aan te maken.
@Dos: oké, ik snap wat je bedoelt en in die zin kan het inderdaad handig zijn.
@Wouter: duidelijk voorbeeld! Ik snap alleen niet waarom je dan de setAmount method niet als abstracte method opneemt in de abstract class:
<?php
abstract class AbstractPayment implements PaymentInterface
{
protected $Amount;
abstract public function setAmount();
final public function getAmount()
{
return $this->Amount;
}
}
?>
Wat is het verschil met een interface? Ik grijp weer even terug naar de uitleg op php.net
"all methods marked abstract in the parent's class declaration must be defined by the child"
Ofwel, de abstracte methods in de parent class (in jouw voorbeeld setAmount) moeten worden ingevuld door de child class. Wat is nu het verschil met een interface? :-s
Interface methods MOETEN public zijn. Dat is een eigenschap van interfaces.
Interface methods zijn ook altijd impliciet abstract methods.
Abstract methods kunnen public of protected zijn, private kan niet.
Methods die in een child/interface al als abstract gedefineerd zijn hoef je in een abstract class niet nogmaals te defineren. Het kan wel, zolang het maar precies de zelfde signature heeft.
"all methods marked abstract in the parent's class declaration must be defined by the child" geldt voor classes die niet abstract zijn.
