### **Interfaces & Team Development** ###
When you team is building a large application, pieces of the application progress at different speeds. For example, imagine one developer is working on the data layer, while another developer is working on the front-end and web/controller layer. The front-end developer wants to test his controllers, but the back-end is progressing slowly. However, what if the two developers can agree on an interface, or contract, that the back-end classes will abide by, such as following:
~~~
<!-- lang:php -->
interface OrderRepositoryInterface {
public function getMostRecent(User $user);
}
~~~
Once the contract has been agreed upon, the front-end developer can test his controller, even if no real implementation of the contract has been written! This allows components of the application to be built at different speeds, while still allowing for proper unit tests to be written. Further, this approach allows entire implementations to change without breaking other, unrelated components. Remember, ignorance is bliss. We don't want our classes to know how a dependency does something, but only that it can. So, now that we have a contract defined, let's write our controller:
~~~
<!-- lang:php -->
class OrderController {
public function __construct(OrderRepositoryInterface $orders)
{
$this->orders = $orders;
}
public function getRecent()
{
$recent = $this->orders->getMostRecent(Auth::user());
return View::make('orders.recent', compact('recent'));
}
}
~~~
The front-end developer could even write a "dummy" implementation of the interface, so the application's views can be populated with some fake data:
~~~
<!-- lang:php -->
class DummyOrderRepository implements OrderRepositoryInterface {
public function getMostRecent(User $user)
{
return array('Order 1', 'Order 2', 'Order 3');
}
}
~~~
Once the dummy implementation has been written, it can be bound in the IoC container so it is used throughout the application:
~~~
<?php
<!-- lang:php -->
App::bind('OrderRepositoryInterface', 'DummyOrderRepository');
~~~
Then, once a "real" implementaion, such as ``RedisOrderRepository``, has been written by the back-end developer, the IoC binding can simply be switched to the new implementation, and the entire application will begin using orders that are stored in Redis.
> ### **Interface As Schematic** ###
>
> Interfaces are helpful for developing a "skeleton" of defined functionality provided by your application. Use them during the design phase of a component to facilicate design discussion amongst your team. For example, define a ``BillingNotifierInterface`` and discuss its methods with your team. Use the interface to agree on a good API before you actually write any implementation code!
>
- Dependency Injection
- The Problem
- Build A Contract
- Take It further
- Too Much Java?
- The IoC Container
- Basic Binding
- Reflective Resolution
- Interface As Contract
- Strong Typing & Water Fowl
- A Contract Example
- Interface & Team Development
- Service Provider
- As Bootstrapper
- As Organizer
- Booting Providers
- Providing The Core
- Application Structure
- MVC Is Killing You
- Bye, Bye Models
- It's All About The Layers
- Where To Put "Stuff"
- Applied Architecture: Decoupling Handles
- Decoupling Handlers
- Other Handlers
- Extending The Framework
- Manager & Factories
- Cache
- Session
- Authentication
- IoC Based Extension
- Request Extension
- Single Responsibility Principle
- Open Closed Principle