A program or function is said to have side effects if it impacts the system state through a means other than its return value or reads the system state through a means other than its arguments. Every meaningful program eventually requires some form of side effect(s), such as writing output to the standard output file-stream or saving a record to a database. That said, working with pure functions, which lack side effects and are consistent, has many advantages. How can the practical necessity of side effects be amended with the benefits of avoiding them?
Your Special Island
If a program’s side effects are isolated in a small, known subset of the codebase, we can reap the benefits of working in their absence throughout large sections of the codebase whilst providing their practical application when needed. Indeed, functional programming languages like Haskell facilitate this approach by isolating side effects directly through language features / limitations. But what about the many languages that don’t directly facilitate side effect isolation, how can we achieve the same effects?
We Will All Go Down Together
Let’s begin with a typical example involving a non-isolated side effect. We’ll work through a small PHP function for sending email that resembles countless other examples online.* Because the side effect (the call to the mail function) is not isolated, the entire function is impure, making it all very difficult to test.
<?php
function sendSalesInquiry($from, $message)
{
// validate email
if (filter_var($from, FILTER_VALIDATE_EMAIL)) {
return "<p>Email address invalid.</p>";
}
// init vars
$to = "sales@company.com";
$subject = "Sales Inquiry";
$headers = "From: $from';
// attempt to send
if (mail($to, $subject, $message, $headers)) {
return "<p>Email successfully sent.</p>";
} else {
return "<p>Email delivery failed.</p>";
}
}
?>
And They Parted The Closest Of Friends
To isolate the side effect, we’ll add some all-powerful indirection by refactoring the email function into multiple functions. Using a combination of a potentially-pure function with two fall-through functions allows us to easily, cleanly isolate the side effect in this example. When using this combination of function types specifically to isolate side effects, I refer to them collectively as an isolation set.
<?php
// potentially-pure function
function sendSalesInquiry($from, $message, $mailer)
{
// validate email
if (filter_var($from, FILTER_VALIDATE_EMAIL)) {
return "<p>Email address invalid.</p>";
}
// init vars
$to = "sales@company.com";
$subject = "Sales Inquiry";
$headers = "From: $from';
// attempt to send
if ($mailer($to, $subject, $message, $headers)) {
return "<p>Email successfully sent.</p>";
} else {
return "<p>Email delivery failed.</p>";
}
}
// fall-through function provides implementation
function sendSalesInquiryMail($from, $message)
{
// call potentially-pure function passing in mailer
return sendSalesInquiry($from, $message, $mailer = function($from, $message, $headers) {
return mail($from, $message, $headers);
});
}
?>
The original example has been refactored into one potentially-pure function to handle the logic and initialization; and two fall-through functions, one to encapsulate the side effect, and one to provide the default behavior (in this case the mailer function) for production.**
When testing the code, the sendSalesInquire() function becomes the natural entry point, as it contains all of the important logic and initialization to be tested. Because the function is potentially-pure, passing in pure arguments causes the function to behave like a pure function, yielding better testing and clarity.
Music Left To Write
Although the example only dealt with one side effect, an isolation set can be used to isolate to any number of side effects. We could extend the example above and add a spam-checking algorithm. We’d just have to add another fall-through function for the side effect.
<?php
// potentially-pure function
function sendSalesInquiry($from, $message, $mailer, $isSpam)
{
// validate email
if (filter_var($from, FILTER_VALIDATE_EMAIL)) {
return "<p>Email address invalid.</p>";
}
// check for spam
if ($isSpam($from, $message)) {
return "<p>Don't call us, we'll call you.</p>";
}
// init vars
$to = "sales@company.com";
$subject = "Sales Inquiry";
$headers = "From: $from';
// attempt to send
if ($mailer($to, $subject, $message, $headers)) {
return "<p>Email successfully sent.</p>";
} else {
return "<p>Email delivery failed.</p>";
}
}
function sendSalesInquiryMail($from, $message)
{
// call potentially-pure function passing in
return sendSalesInquiry(
$from,
$message,
$mailer = function($from, $message, $headers) {
return mail($from, $message, $headers);
},
$isSpam = function($from, $message) {
$spamChecker = new SpamChecker();
// this analysis could involve any number of database queries, networking requests, etc.
return $spamChecker->isSpam($from, $message);
}
);
}
?>
It’s Nine O’Clock On A Saturday
What? Doesn’t getting your side effects isolated put you in a mood for a melody?
* I’m not enamored with returning HTML markup in this type of function, but it represents a common example I found online, and it’s for a programming language that people don’t typically associate with functional programming practices, so the example works well for the purposes of the current demonstration.
** You could reduce this example to two functions, as the potentially pure function could be used to contain default values for the fall-through function(s), which could then be overridden by passing in an argument for testing purposes. However, I like the clarity granted by implementing an isolation set with three functions, as I want to avoid marrying the potentially pure function to any default implementation. For example, I could easily provide a different mailing mechanism by merely creating a new function, like sendSalesInquirySMTP(), which provides a PHPMailer implementation.
Leave a Reply