SOLID reasons to take a look at functional programming

Functional programming is fashion

There is a freight train barreling down the tracks towards us, with multi-core emblazoned on it; and you’d better be ready by the time it gets here.

-- Uncle Bob

SOLID

Single Responsability Principle

SRP in Functional Programming

Functions return ALWAYS the same output for the same input (Referential Trasparency)
In functional programming you should avoid side-effects

Then can we consider the single responsibility principle inherent in the functional paradigm?

It violates the Single Responsibility Principle because there is more than one reason for it to change.

-- Robert C. Martin

public Money calculatePay(Employee e)
throws InvalidEmployeeType {
    switch (e.type) {
        case COMMISSIONED:
            return calculateCommissionedPay(e);
        case HOURLY:
            return calculateHourlyPay(e);
        case SALARIED:
            return calculateSalariedPay(e);
        default:
            throw new InvalidEmployeeType(e.type);
    }
}

Open Close Principle

OOP

FP

defmodule Car do

    def slow_down brake_system do
        brake_system
    end

end

defmodule Brake do

    def simple do
      IO.puts "Hope you're not on ice!"
    end

    def abs do
        IO.puts "Press as you want..." 
    end
end

Car.slow_down Brake.simple
# or
Car.slow_down Brake.abs

Liskov Substitution Principle

LSP in OOP

class Rectangle
{ 
    private $topLeft;
    private $width;
    private $height;
 
    public function setHeight($height)
    {
        $this->height = $height;
    }
 
    public function setWidth($width)
    {
        $this->width = $width;
    }
 
    public function getArea()
    {
        return $this->width
            * $this->height;
    } 
}

class Square extends Rectangle
{ 
    public function setHeight($value)
    {
        $this->width = $value;
        $this->height = $value;
    }
 
    public function setWidth($value)
    {
        $this->width = $value;
        $this->height = $value;
    }
}

class RectangleTest
{ 
    public function testArea(Rectangle $r)
    {
        $r->setWidth(5);
        $r->setHeight(4);
 
        if($r->getArea() != 20) {
            throw new \Exception("Ms. Liskov crying!");
        }
 
        return true;
    }
}

LSP in FP

Functional languages emphasize substitutability and deemphasize implementation reuse since reuse is better achieved through composition

Most ambitions of the Liskov substitution principle are effectively trivial in a functional language.

Interface Segregation Principle

ISP in FP


list = [key: "value"]
map  = %{key: "value"}

Dict.get(:key, map) # "value"
Dict.get(:key, list) # "value"

There is no augmented concept of role-based interfaces because function roles are explicit at the onset. Functions are segregated by default.

Dependency Inversion Principle

DIP in OOP

Inversion of control
Dependency Injection Container

DIP in FP

In object-oriented programming, high-level modules depend on infrastructure modules primarily to invoke side-effects. In functional programming, side-effects are more naturally triggered in response to domain behavior as opposed to being directly invoked by domain behavior. Thus dependencies become not merely inverted, but pushed to outer layers all together.