OO Design in Kohana - Facade Pattern

Published on:
Tags: Kohana, PHP

For the second in my mini-series looking at Object Oriented Design within the Kohana framework I am going to look at the Facade pattern. I had this down for the third article, but I had a comment on the last one voicing some thoughts on a common grey area when it comes to this and the adapter pattern, and so I thought I would jump straight to the facade pattern in an attempt to clear up any confusion!

When it comes to design pattern history the starting point should probably be the book “Design Patterns Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides”. Most commonly referred to as the Gang of Four (GoF) the authors outlined 23 design patterns, potential solutions as they saw them to many common programing scenarios. When reading articles about design patterns you will often come accross references to the pages on which these patterns were described first, so if you havn’t allready I would strongly suggest getting hold of a copy and taking a look. In writing these articles my objective is really to attempt to show some of the potential theory behind certain implementations within the Kohana framework, and more over demonstrate the power they afford us as programmers in developing with, and extending from, the framework.

Swift Mailer in Kohana

One pretty universal piece of functionality to websites or applications now adays is email. There is a number of different potential solutions when it comes to sending emails, often dependant on the specific scenario, you will have undoubtedly used a few of these in your time. Whilst design patterns suggest a potential solution, frameworks provide an implemented solution (GoF). Seeing no need to reinvent the wheel, and identifying an exemplorary open source project Kohana comes with a bundled version of the swift mailer project.

However with a new framework (or library technically) comes a new set of conventions. Along with these different conventions come a large and detailed API, which is to be expected from a library which is as specialised in an area as Swift mailer is. One of the biggest draws of a framework is familiarity which is achieved in large part through consistency: Configurations and files are held in the same format and location, method naming conventions, class, instance accessors/mutators etc etc

So along comes the helper. Whilst sending email using Swift is increadibly easy it is done in a mannor which isn’t entirely cohesive to the Kohana framework ‘experience’. The helper allows us to place our own, simpler interface on top of the swift mailer system (or facade), allowing us to send emails using it with syntax which will blend perfectly into our model or controller. Whats more we can provide configuration parameters for the system in exactly the same way the rest of Kohana does . .neat

Swift Mailer 4 in Kohana

Kohana currently comes bundled with swiftmailer 3 (and a helper for its API). To demonstrate the principles of helpers (and the facade pattern) I have put up a basic helper I use for Swiftmailer 4, though it isnt extensively tested!

In this instance we can use the power of the facade pattern to turn:

1
2
3
4
5
6
7
8
9
10
11
12
<?php

$t = Swift_SmtpTransport::newInstance($hostname, $port);

$t->setUsername($un); $t->setPassword($pw);

$mailer = new Swift_Mailer::newInstance($t);

$message = Swift_Message::newInstance($subject) ->setFrom($from) ->setTo($to)
->setSubject($subject) ->setBody($message, $mime) ;

$mailer->send($message);

Into the more Kohana friendly:

1
2
<?php
email::send($to, $from, $subject, $message);

Bear in mind you will also need to of set up your email configuration in the relevant config folder ( Check the docs here ) The helper also caters for some of the most common sending scenarios and options (forme), though obviously will not cater for all (the side affect of simplifying the interface to an API is it’s inherrent narrowing). However if you find your usage scenario to be different to others then simply ammending the helper allows you to simplify your particular usage pattern. . simple!

Checkout my helper (bundled as a module with the latest swift download) over at github

To Recap

  • We have seen how the facade pattern allows us to provide a simpler, more intuitive (read Kohana-like) interface for a bundled sub-system, or third party solution
  • The swiftmailer helper is a fine example of the facade pattern in use, it provides seemless kohana integration with a third party library which specialises in a particular niche of what we are working with
  • As a bonus I’ve posted up a swiftmailer 4 helper that I use to provide integration with the new Swiftmailer version (and thus new api) – it isnt tested though so beware!

Conclusion

The facade pattern is one of the most intuitive patterns, many will have been using such ‘simplifying’ classes for some time and so their funtionality and purpose probably comes as no real suprise at all. But it is worth remembering the power and efficiency that they afford us as programmers. It’s frequently said that no two programmers program the same, and so a wealth of helpers, designed around your own usage pattern, and systems which you are familiar with can be a very valuable tool when it comes to rapid applicatoin development using a framework.

Kohanas modular system enables such usage very nicely, making it very easy for us to bundle Swiftmailer (or any other such third party library), along with a usage helper into a single module. This module can then be dropped into any of your projects allowing instant and intuitive use to whatever sub-system it contains.

Hopfully the above is usefull to some, all feedback is greatly appreciated!

/Matt