Object Oriented PHP Question

[KevinM1]

I wasn't sure if I should post this here or in PHP Help, so I hope I got it in the right place.

I was reading through my O'Reilly PHP reference and noticed that PHP has a pretty simplistic object oriented side to it.  Everything more or less made sense until I got to the keyword [b]abstract[/b].  I just can't see why I'd ever make an abstract class or abstract methods if they couldn't be fleshed out, especially given PHP's [b]interfaces[/b] keyword, which, at least on the surface, basically does the same thing.  So, with all that said, when would using an abstract class be beneficial?  And what are the differences between that and interfaces?

Thanks :)

[Jenk]

When building a set of classes that share common functionality, it's useful to bundle that functionality into one class. Sometimes that functionality is useless on it's own and must be extended to complete the class; thus abstract comes into play :)

Not every method has to be abstract within an abstract class, infact you don't have to have any abstract methods at all.

[KevinM1]

[quote author=Jenk link=topic=111314.msg451021#msg451021 date=1160674626]
When building a set of classes that share common functionality, it's useful to bundle that functionality into one class. Sometimes that functionality is useless on it's own and must be extended to complete the class; thus abstract comes into play :)

Not every method has to be abstract within an abstract class, infact you don't have to have any abstract methods at all.
[/quote]

So how would an abstract class be 'connected' to a non-abstract class that needs the functionality the former has?

[Jenk]

[code]<?php

abstract class A
{
    public function fooBar()
    {
        echo 'Foobar!';
    }
}

class B extends A
{
}

$obj = new B;
$obj->fooBar();

?>[/code]

[KevinM1]

[quote author=Jenk link=topic=111314.msg451115#msg451115 date=1160684806]
[code]<?php

abstract class A
{
    public function fooBar()
    {
        echo 'Foobar!';
    }
}

class B extends A
{
}

$obj = new B;
$obj->fooBar();

?>[/code]
[/quote]

...duh, I should've known that.  :D

Thanks. :)

[redbullmarky]

Jenk - am I right (at all) in thinking that many of these keywords such as 'abstract' and 'interface', etc are ways of forcing a particular behaviour/usage of a class, rather than actually doing anything functional?

[neylitalo]

[quote author=redbullmarky link=topic=111314.msg451165#msg451165 date=1160691066]
Jenk - am I right (at all) in thinking that many of these keywords such as 'abstract' and 'interface', etc are ways of forcing a particular behaviour/usage of a class, rather than actually doing anything functional?
[/quote]

Well, I'm not Jenk, but I'll jump in - You're absolutely right.

Abstract methods and classes are the basis for polymorphism - the idea that objects should be able to take on several different "identities" and behave differently according to the specific need. For example, we'll pretend we're creating a little RPG with several different character types. Some of these character types will be able to attack, but specifically how that is done depends entirely on the type of the character. For example, an archer will shoot arrows, a swordsman will (naturally) swing a sword, and an assassin will creep up in the shadows and silently make his mark. So, in the base character class, we would create an [b]abstract[/b] method attack(). Then, in each character class with the ability to attack, we would over-ride that abstract method with specific instructions as to how that character should attack. The abstract keyword comes in handy in our example to make sure that character objects unable to attack can't call the attack() method. An abstract method NEEDS to be over-ridden to be used, but just because an abstract method is defined, it does not have to be extended. The abstract keyword doesn't force a specific behavior; rather, it ensures that a behavior is defined before it is used.

Interfaces, on the other hand, force a specific behavior. An interface is simply an easy way to make sure that a given object has certain properties and methods. We'll use a different example to demonstrate the uses of interfaces - a car. You have to be able to steer the car, so we'll create an interface requiring each and every car object to have methods that turn the car's wheels. Now, we can't just have steerLeft() and steerRight() methods in the base car class - remember, back in the "old days", cars had no power steering. It was purely a mechanical link. That's the difference, and the reason we have to make an interface to force the steering behavior instead of just creating universal steering methods. So, on the cars that don't have power steering, the steerLeft() and steerRight() methods will contain instructions to put the mechanical linkage into motion. The cars that have power steering will have methods that know how to "activate" the power steering and turn the car. Note that, unlike abstract methods, methods in an interface are REQUIRED in classes that implement that interface.

So, in summary, abstract methods are used to make sure that the method is extended before it is used, and interfaces are used to require the definition of certain methods and properties crucial to the object.

[Jenk]

abstract classes are a mixture of common functionality and ensuring abstract methods are defined.

final classes and methods are the complete opposite, you cannot extend a final class and you cannot overload a final method.

interfaces simply define what access points (thus: interface) are required.

abstract and interface have a use in type hinting.