Sign In Start Free Trial
Account

Add to playlist

Create a Playlist

Modal Close icon
You need to login to use this feature.
  • Book Overview & Buying Learning Functional Programming in Go
  • Table Of Contents Toc
  • Feedback & Rating feedback
Learning Functional Programming in Go

Learning Functional Programming in Go

By : Sheehan
4.1 (8)
close
close
Learning Functional Programming in Go

Learning Functional Programming in Go

4.1 (8)
By: Sheehan

Overview of this book

Lex Sheehan begins slowly, using easy-to-understand illustrations and working Go code to teach core functional programming (FP) principles such as referential transparency, laziness, recursion, currying, and chaining continuations. This book is a tutorial for programmers looking to learn FP and apply it to write better code. Lex guides readers from basic techniques to advanced topics in a logical, concise, and clear progression. The book is divided into four modules. The first module explains the functional style of programming: pure functional programming, manipulating collections, and using higher-order functions. In the second module, you will learn design patterns that you can use to build FP-style applications. In the next module, you will learn FP techniques that you can use to improve your API signatures, increase performance, and build better cloud-native applications. The last module covers Category Theory, Functors, Monoids, Monads, Type classes and Generics. By the end of the book, you will be adept at building applications the FP way.
Table of Contents (13 chapters)
close
close

SOLID design principles


The SOLID design principles of Object-Oriented Programming (OOP) apply to designing Go software solutions.

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...

Unlock full access

Continue reading for free

A Packt free trial gives you instant online access to our library of over 7000 practical eBooks and videos, constantly updated with the latest in tech

Create a Note

Modal Close icon
You need to login to use this feature.
notes
bookmark search playlist download font-size

Change the font size

margin-width

Change margin width

day-mode

Change background colour

Close icon Search
Country selected

Close icon Your notes and bookmarks

Delete Bookmark

Modal Close icon
Are you sure you want to delete it?
Cancel
Yes, Delete

Delete Note

Modal Close icon
Are you sure you want to delete it?
Cancel
Yes, Delete

Edit Note

Modal Close icon
Write a note (max 255 characters)
Cancel
Update Note

Confirmation

Modal Close icon
claim successful

Buy this book with your credits?

Modal Close icon
Are you sure you want to buy this book with one of your credits?
Close
YES, BUY