Single responsibility principle

Single responsibility principle says, Do One Thing and Do It Well. We see the SRP at play in the Go standard libraries. Here're a few examples:

If a pull request enhances the aes/crypto package, would you expect that code merge to affect the functionality of the database/sql/driver package (or any package)? No. Of course not. Each package is clearly name spaced and highly cohesive; they perform specific tasks and do not cross over into other concerns. 

"A class should have one, and only one, reason to change."

– Robert C Martin

When Mr. Martin said that a class should have only one reason to change, it's obvious that he was talking about OOP design, but the same principle applies to our Go application. Should the tax calculation update affect the user interface or layout of any reports, other than showing a different amount? No. Why? Because one is cosmetic in nature and the other is not. Those are two separate responsibilities that should be handled by different, loosely coupled classes/modules.

Our classes/modules should be highly cohesive, performing as specific a role as possible. Code that has a single responsibility can handle the changing requirements better without adversely affecting other parts of our application. If we have a request to change our class/module and since it does only one thing then the reason for the change can only be related to its one responsibility. 

Application of the SRP will drive our design towards smaller and smaller interfaces. Eventually, we will arrive at the ultimate interface. The interface with one method. For example, in Chapter 5, Adding Functionality with Decoration, we'll look at Go’s complimentary Reader and Writer interfaces:

type Reader interface {
   Read(p []byte) (n int, err error)
}
type Writer interface {
   Write(p []byte) (n int, err error)
}

What the SRP means to FP is aligned with the Unix philosophy. 

"Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools."

- Rob Pike

In lambda calculus, each function has exactly one parameter. It may look like our pure function accepts multiple parameters, but it's actually just currying the parameters. Our function takes the first argument in the list and returns a function which takes the rest of the arguments; It continues to process each argument until they are all consumed. Function composition works when every function accepts only one parameter. 

three := add(1, 2)
func add1 := + 1
three == add1(2)

That was pseudo code for what happens when we curry. It converts a two parameter call into a one parameter call. Currying stores data (the number 1) and an operation (the addition operator) for use later. How is that like an object in OOP?