If you are a programmer, and utilize all the goodness of OOP, and you have not heard of fluent interfaces, then you have been missing out!
Using them further establishes object relationship, tidies up code, and gives access to a whole array of new uses.
A quick example of fluent interfacing is this
company::getInstance()->selectStore(31)->addEmployee(array('fname'=>'Joey','lname'=>'Adams'));
Get It?
Basically, to achieve fluent interfaces, just return object references in methods. This can be accompolished fairly easily using a singleton pattern, which doubles to prevent unwanted memory usage by restricting instantiation of a class to one object. Take the following:
class employees {
private $_instance;
public function getInstance(){
if(!isset($this->_instance)){
$this->_instance = new employees;
}
return $this->_instance;
}
public function getEmployeeList() {
Query Database or Model for List
$list = array(employeeId,employeeId)
$employees = array();
foreach($list as $employeeID) {
$employees[] = employee::getInstance()->selectByID($employeeID);
}
return $employees;
}
If you have been paying attention you can see the uses for this, such as
$list = employees::getInstance()->getEmployeeList();
foreach($list as $employee) {
echo $employee->lastname . ", " . $employee->firstname . "
";
}
The possibilities are endless, and when you take a look at them, it really seperates objects, and makes them more usable. For the last example, instead of the employees class method “getEmployeeList()” returning a list of last names and firstnames, it returns an instance of the employee class for each employee.
What does this mean? Anything! The employee class can retrieve detailed info on the employee and you now have a much more diverse way of computation and expansion when it comes to retrieving info about a group of employees. All of that employee’s info is at your fingertips, without having to add extra information to a complex query, instead you let the model for the employee class do all the work.
But with great power comes great responsibility. Fluent Interfacing is sometimes shunned because people abuse its’ scalability. Programmers create long interface maps that result in unreadable code, or mistake number two, programmers use non descriptive naming tactics with methods.
To address #1 , keep it practical. No one wants to follow a map like this:
company::getInstance()->getStores()->selectByState('GA')->filterByCity('Albany')->
getEmployees->filterByPosition(array('cashier','photo'))->sortByName('ascending');
This map can be debatable, but unless you have a very expansive company and this is used at the root, there is no need, if there is a need for something this deep, break it down.
- What do we want? A listing of employees from stores based on city,state and type of work.
- Combine like terms. (city, state) (position)
- Create new map
company::getInstance()->getAllEmployees(array('position'=>array('cashier','photo'),'location'=>array('city'=>'Albany','state'=>'GA'))
->sortByName('ascending');
Is it still long? Yes, however it is a little easier to map out, and just by looking at them, you can see the methods in use will be much faster, as well as the queries. Of course this is not ideal, but it’s the brain that matters, looking at your fluent-map in different ways, concerning different use-cases can help you find the perfect solution.
The answer to #2? Long method names do not take that much more time to execute, it is not noticeable. So instead of naming something filbyLoc(), name it filterByLocation(). USE CAMEL CASE in method names, this means filterByLocation, instead of filterbylocation. You might not think it helps, but it really does.
Using fluent interfaces responsibly, and smartly, will give you the ability to harness power only rivaled by arrays.
