Interfaces

Object interfaces allow you to create code which specifies which methods a class must implement, without having to define how these methods are handled.
Interfaces are defined using the interface keyword, in the same way as a standard class, but without any of the methods having their contents defined.
All methods declared in an interface must be public, this is the nature of an interface.

To implement an interface, the implements operator is used. All methods in the interface must be implemented within a class; failure to do so will result in a fatal error. Classes may implement more than one interface if desired by separating each interface with a comma.

Abstract Classes

PHP 5 introduces abstract classes and methods. Classes defined as abstract may not be instantiated, and any class that contains at least one abstract method must also be abstract. 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; additionally, these methods must be defined with the same (or a less restricted) visibility. For example, if the abstract method is defined as protected, the function implementation must be defined as either protected or public, but not private. Furthermore the signatures of the methods must match, i.e. the type hints and the number of required arguments must be the same. This also applies to constructors as of PHP 5.4. Before 5.4 constructor signatures could differ.

Some Cases

Now let’s do a quick experiment. According to the definition of interfaces we can define an interface and than an abstract class can implement this interface.

interface A
{
	public function a();
}

abstract class B implements A
{
	public function a()
	{
		return 10;
	}
}

However the abstract class cannot be instantiated so we need to extend it.

interface A
{
	public function a();
}

abstract class B implements A
{
	public function a()
	{
		return 10;
	}
}

class C extends B
{
	...
}

In the first place is completely OK to define an abstract class that does not contain any abstract method. TUsually if a class has one or more abstract methods (Methods defined as abstract simply declare the method’s signature – they cannot define the implementation, according to the docs), it must be defined as abstract. But we can also define an abstract class which has no abstract methods.

abstract class B
{
	public function a()
	{
		return 5;
	}
}

class C extends B
{
	public function a()
	{
		return 10;
	}
}

$c = new C();
echo $c->a();

OK then what would happen if we had an interface that is implemented by an abstract class, which in turn is extended by a given class. First of all if a class implements an interface, even if it is an abstract class, it must implement all methods defined in the interface. So if the predefined method in the abstract class is marked as abstract, it would result into a fatal error.

interface A
{
	public function a();
}

abstract class B implements A
{
	abstract public function a();
}

class C extends B
{
	public function a()
	{
		return 5;
	}
}

$c = new C();
echo $c->a();

This is perfectly logical, because in fact each method of the interface must be implemented by his children.

“All methods in the interface must be implemented within a class; failure to do so will result in a fatal error.”

Fine, but we can have abstract classes with no abstract methods, let’s try this:

interface A
{
	public function a();
}

abstract class B implements A
{
	public function a()
	{
		return 10;
	}
}

class C extends B
{
	public function a()
	{
		return 5;
	}
}

$c = new C();
echo $c->a();

This code is working and the result is the returned value from C::a(). However class B is abstract so let’s go even further. Let’s define an abstract method, different from the method B::a().

interface A
{
	public function a();
}

abstract class B implements A
{
	public function a()
	{
		return 10;
	}
	
	abstract public function b();
}

class C extends B
{
	public function a()
	{
		return 5;
	}
	
	public function b()
	{
		return "hello world!";
	}
}

$c = new C();
echo $c->a();
echo $c->b();

Now there’s a fatal error. Why?

Typically you’ve one module in your Zend App – the default one. In the basic installation of the framework, you put all the controllers, models and views directly in the application folder, as described below.

/application
	- /controllers
		- /IndexController.php
	- /models
		- /MyModel.php
	- /views
		- /scripts
			- /index/index.phtml
/library
	- /Zend
/public_html
	- /images
	- /scripts

Bigger Apps – More Code

When the application becomes bigger and bigger the controller, models and views/scripts directories contain more and more files. That’s a bit odd, because it becomes difficult to maintain, and than the modules come in hand.

Modules in a Zend App

When it comes to setting up modular Zend App there are tons of articles in the web, but let me show you a simple directory layout and … sample code that sets up the framework.

/application
	- /modules
		+ /admin
			- /controllers
				- /IndexController.php
			- /views
				- /scripts
					- /index/index.phtml
		+ /default
			- /controllers
				- /IndexController.php
			- /views
				- /scripts
					- /index/index.phtml
	- /models
/library
	- /Zend
/public_html
	- /images
	- /scripts

Source

Simply add this into the bootstrap:

$frontController->addModuleDirectory(APPLICATION_PATH . '/modules');

// where params include adapter, host
// username, password and dbname
$db = new Zend_Db_Adapter_Pdo_Mysql($params);

and set the default adapter

Zend_Db_Table::setDefaultAdapter($db);

That can be done in the bootstrap or into a front controller plugin!

Almost every web site need some abstraction over the access control list (ACL) to grant access of its users. As usual Zend Framework has quite good mechanism to deal with this – Zend_Acl.

Out in the web there are a lot of resources about Zend_Acl’s usage, so I ain’t going to cover it one more time, but simply copy/paste a very small front controller plugin implementing the basic usage of Zend_Acl.

Note that instead of defining the __construct() here is called preDispatch where the request is passed as a parameter. However only by copy pasting not every answer will be given. That’s why I’m going to write more about Zend_Acl in my future posts, for now only the source code:

add(new Zend_Acl_Resource('index'))
            ->add(new Zend_Acl_Resource('create'))
            ->add(new Zend_Acl_Resource('read'))
            ->add(new Zend_Acl_Resource('update'))
            ->add(new Zend_Acl_Resource('delete'));

        // define roles
        $acl->addRole(new Zend_Acl_Role('guest'))
            ->addRole(new Zend_Acl_Role('admin'));

        // define privileges
        $acl->allow('guest', array('index', 'read'))
            ->allow('admin');

        // setup acl in the registry for more
        Zend_Registry::set('acl', $acl);

        // check permissions
        if (!$acl->isAllowed('guest', $request->getActionName())) {
            $request->setControllerName('error');
            $request->setActionName('error');
        }
    }
}