Итак, сформулируем проблему:  При использовании наследования реализующий код жестко привязан к абстракции, что сильно усложняет независимую модификацию. Необходимо отделить абстракцию от реализации так, чтобы и то и другое можно было изменять независимо.

Допустим у нас есть задача создания списка статей разного типа, при этом также следует учесть, что формат вывода может иметь несколько вариаций.

Пример реализации:

<?php

abstract class Articles
{
    protected $_viewType;

    abstract function printAll();

    function __construct($viewType)
    {
        $this->_viewType = $viewType;
    }

    protected function printLogic(array $articles)
    {
        if($this->_viewType == 'block')
        {
            $this->blockPrintLogic($articles);
        }
        else
        {
            $this->listPrintLogic($articles);
        }
    }

    protected function blockPrintLogic(array $articles)
    {
        echo 'Вывод блоками: | '.
            implode(' | ',$articles)
            .' |';
    }

    protected function listPrintLogic(array $articles)
    {
        echo 'Вывод списком <br><ul><li>'.
            implode('</li><li>',$articles)
            .'</li></ul>';
    }
}

class GameArticles extends Articles
{
    function printAll()
    {
        $articles = array
        (
            'Статья об игре 1',
            'Статья об игре 2',
            'Статья об игре 3',
        );
        $this->printLogic($articles);
    }
}

class VideoArticles extends Articles
{
    function printAll()
    {
        $articles = array
        (
            'Статья о фильме 1',
            'Статья о фильме 2',
            'Статья о фильме 3',
        );
        $this->printLogic($articles);
    }
}

$listGameArticles = new GameArticles('list');
$listGameArticles->printAll();

$blockVideoArticles = new VideoArticles('block');
$blockVideoArticles->printAll();
?>

В результате выполнения получим:

Какие неудобства мы здесь видим? Код абстракции и код реализации связаны друг с другом, мы не можем проводить независимые модификации, хоть для одного разработчика это может и не быть проблемой, для группы программистов это несет негативные последствия.

Путем применения шаблона «Мост» мы не только избавляемся от проблем с модификациями в будущем, но и делаем структуру класса более изящной и логичной.

Вот как выглядит оптимизированный вариант:

<?php

abstract class Articles
{
    protected $_articleView;

    abstract function printAll();

    function __construct(ArticleView $articleView)
    {
        $this->_articleView = $articleView;
    }

    protected function printLogic(array $articles)
    {
        $this->_articleView->printLogic($articles);
    }
}

class GameArticles extends Articles
{
    function printAll()
    {
        $articles = array
        (
            'Статья об игре 1',
            'Статья об игре 2',
            'Статья об игре 3',
        );
        $this->printLogic($articles);
    }
}

class VideoArticles extends Articles
{
    function printAll()
    {
        $articles = array
        (
            'Статья о фильме 1',
            'Статья о фильме 2',
            'Статья о фильме 3',
        );
        $this->printLogic($articles);
    }
}

interface ArticleView
{
    function printLogic(array $articles);
}

class BlockArticleView implements ArticleView
{
    function printLogic(array $articles)
    {
        echo 'Вывод блоками: | '.
            implode(' | ',$articles)
            .' |';
    }
}

class ListArticleView implements ArticleView
{
    function printLogic(array $articles)
    {
        echo 'Вывод списком <br><ul><li>'.
            implode('</li><li>',$articles)
            .'</li></ul>';
    }
}

$listGameArticles = new GameArticles(new ListArticleView());
$listGameArticles->printAll();

$blockVideoArticles =
new VideoArticles(new BlockArticleView());
$blockVideoArticles->printAll();
?>

Реализацию логики отображения мы вынесли в отдельный класс ArticleView, оставив в абстракции только необходимое.

Обратите также внимание на изменения в клиентском коде, код стал более строгим, уточнение типов не даст нам совершить ошибку при создании экземпляра статей.

Для более глубокого восприятия рекомендую отличную статью.

Когда применять? Если класс фабрика начинает обрастать логикой по созданию разного типа объектов (продуктов) и методы начинают содержать дублированные ветвления.

Пример: пусть у нас есть класс фабрики статей задача которого предоставлять по запросу коллекции статей заданного типа.

<?php

class ArticlesFactory
{
    function getArticles($type)
    {
        switch($type)
        {
            case 'game':
                $articles = new GameArticles(); break;
            case 'video':
                $articles = new VideoArticles(); break;
            default:
                throw new Exception('$type not defined');
        }

        return $articles;
    }

    function info($type)
    {
        switch($type)
        {
            case 'game':
                $info = 'Статьи о играх'; break;
            case 'video':
                $info = 'Статьи о видео'; break;
            default:
                throw new Exception('$type not defined');
        }

        return $info;
    }
}

interface Articles
{
    function get($articleId);
}

class GameArticles implements Articles
{
    function get($articleId)
    {
        return 'Статья об играх под #id '.$articleId;
    }
}

class VideoArticles implements Articles
{
    function get($articleId)
    {
        return 'Статья о видео под #id '.$articleId;
    }
}

$articlesFactory = new ArticlesFactory();
echo $articlesFactory->info('video');

$articles = $articlesFactory->getArticles('video');
echo '<p>'.$articles->get(rand(1,100)).'</p>';

?>

после выполнения получим вывод примерно следующего содержания

Статьи о видео
Статья о видео под #id 16

В коде намерено опущена проверка на ошибки для простоты примера. Главные участники здесь: ArticlesFactory — фабрика статей (в терминологии шаблона «создатель») и Articles — наборы статей (продукт).

На лицо несколько проблем:

• Дублирование кода (Добавление нового метода в фабрику (например подсчета количества статей заданного типа) приведет к очередному дубликату конструкции switch

• Тесная связь (Добавление нового типа статей приведет к правке всех методов фабрики)

Шаблон Factory Method предлагает для решения этих проблем создать специфичные фабрики для каждого из продуктов, т.е. фактически свеcти реализацию к полиморфизму.

<?php

interface ArticlesFactory
{
    function getArticles();
    function info();
}

class GameArticlesFactory implements ArticlesFactory
{
    function getArticles()
    {
        return new GameArticles();
    }

    function info()
    {
        return 'Статьи о играх';
    }
}

class VideoArticlesFactory implements ArticlesFactory
{
    function getArticles()
    {
        return new VideoArticles();
    }

    function info()
    {
        return 'Статьи о видео';
    }
}

interface Articles
{
    function get($articleId);
}

class GameArticles implements Articles
{
    function get($articleId)
    {
        return 'Статья об играх под #id '.$articleId;
    }
}

class VideoArticles implements Articles
{
    function get($articleId)
    {
        return 'Статья о видео под #id '.$articleId;
    }
}

$videoArticlesFactory = new GameArticlesFactory();
echo $videoArticlesFactory->info();
$articles = $videoArticlesFactory->getArticles();
echo '<p>'.$articles->get(rand(1,100)).'</p>';

?>

Перечислим основные плюсы такого подхода:

• Клиентский код по созданию объектов стал более универсален и не привязан к конкретному продукту (типу статей), а оперирует общим интерфейсом ArticlesFactory
• Однозначная связь между параллельными иерархиям классов

Не обошлось и без минусов:

• Необходимо создавать новую фабрику под каждый новый тип статей

kupreev.com

Отличная статья о Views в Kohana

Простейший HMVC  в Kohana

HMVC виджет

Внутренние роутеры Коханы

brotkin.ru

Базовая ORM

KO3 мультиязычность

Пагинация

Собираем статистику

habrahabr.ru

KO3: HMVC и роутинг

Интеграция Doctrine в kohana 3

kerkness.ca

Отличная документация на английском, очень много всего, рекомендую

kohanaframework.org

Скромная оффициальная документация (скомпилированная в chm)

Kohana — это открытый, объектно-ориентированный MVC web-фреймворк, построенный на PHP5 на общественных началах, основными целями которого являются скорость, безопасность и небольшой размер.

Являясь одним из форков CodeIgniter, Kohana была переписана в целостный монументальный проект, сохраняя при этом легкую расширяемость, обладая 100% поддержкой юникода при этом следуя строгой концепции ООП.

Установка

Коротко: Скачиваем, распаковываем в директорию доступную web серверу, открываем в браузере.

Подробно: http://kohanaframework.org/guide/about.install

Настройка

Основной конфигурационный файл bootstrap.php, каталога applications. Основное моменты:

• подключение модулей (Kohana::modules($modules), где $modules – массив подгружаемых модулей расположенных в папке modules корневого каталога.
• Route::set() – подключение роутеров, структура включения не привычная, но достаточно наглядная и приятная.

Дополнительно:

Подробности из Блога Броткина Ивана

Оффициальная документация

Дополнительная документация

MVC

Контроллеры следует располагать в папке application/classes/controller, методы должны называться action_имяМетода например action_index

Модели – по сути обычные статичные классы, если требуется добавить метод фабрику, то можно сделать это наследованием от Model. Рекомендуется располагать в application/classes/model

Представления - создаются с помощью вызова метода фабрики, пример:

$this->request->response = View::factory('main')->set('areas',$areas);

В данном случае, будет вызвано представление по адресу application/view/main.php, c передачей переменной $areas. Результат генерации будет передан объекту request для вывода пользователю.

Подробнее:

Офф. документация

Роутинг

По умолчанию URI роутинг Коханы настроен на прием запросов вида
www.your-site.com/controller/method/id/


С помощью правил роутинга можно расширить данное поведение до практически любого формата URL.

Для примера простое правило для задания рейтинга файлам:

Route::set('setRating', 'setRating/file<file_num>/<rating>',
    array
    (
        'file_num' => '[0-9]{1,5}',
        'rating' => '[1-5]'
    )
)
->defaults(array(
    'controller' => 'file',
    'action' => 'setRating'
));

Если что-то не ясно, много отличной документации:

Базовые сведения

Офф. документация

Подробная статья

Итог

Как видите начать использовать этот фреймворк совсем не сложно, вы можете сами помочь в разработке Kohan’ы или её модулей.

В завершении предлагаю скачать скомпилированную документацию в chm формате, успехов.