# Side Effects and Composition

DevFeed: [Side Effects and Composition](<https://devfeed.tech/articles/side-effects-and-composition-25870.md>)

Original publisher: [Read original article](<http://lordraydenmk.github.io//2019/side-effects-and-composition/>)

Author: Stojan Anastasov

Published: 2019-08-13T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stojan Anastasov's blog](<https://devfeed.tech/sources/stojan-anastasov-s-blog.md>)

Topics: [Functional programming](<https://devfeed.tech/topics/functional-programming.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Code](<https://devfeed.tech/topics/code.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [SDKs](<https://devfeed.tech/topics/sdks.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [arrowkt](<https://devfeed.tech/tags/arrowkt.md>), [code](<https://devfeed.tech/tags/code.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [fp](<https://devfeed.tech/tags/fp.md>), [functional](<https://devfeed.tech/tags/functional.md>), [functional-programming](<https://devfeed.tech/tags/functional-programming.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [programming](<https://devfeed.tech/tags/programming.md>)

## AI overview

This tutorial uses a coffee-shop payment example to explain side effects, testability, dependency injection, composition, and referential transparency in functional programming. It shows how extracting payment logic into a Payments object enables mock implementations for tests, and how reusing single-coffee logic for multiple coffees can avoid charging a credit card multiple times.

## Source excerpt

Photo by Ryan Yoo on Unsplash Functional Programing is amazing. It limits the things you can do (no nulls, no exceptions, no side effects...) and in return you get some benefits. Some benefits of FP are easy to explain and some not so much. I have been playing with FP for more than a year and only few weeks ago, when I started reading Functional Programming in Scala, I found an amazing example the benefits of pure functions. The problem Building a software for a Coffee Shop. For the initial MVP the requirements are: Sell coffee Pay with a card so the first draft of the code looks like this: import coffee.* fun buyCoffee(cc: CreditCard): Coffee { val cup = Coffee() cc.charge(cup.price) return cup } The buyCoffee function receives a CreditCard as an input and returns a Coffee as an output. It creates a Coffee object, then executes a charge and returns the Coffee object. Testability The call cc.charge uses an SDK/API to talk to the credit card company. It involves authorization, network call(s), persisting a record in the DB. The buyCoffee function returns a Coffee and the charging happens on the side hence the terms "side effect". The side effect makes buyCoffee hard to test in isolation. It would be nice (and cheaper) to run tests without actually talking to the credit card company and doing an actual charge. One could also argue that a CreditCard should not know how it's being charged. The testability problem can be fixed using Dependency Injection. fun buyCoffee(cc: CreditCard, p: Payments): Coffee { val cup = Coffee() p.charge(cc, cup.price) return cup } The logic of charging the credit card is extracted into the Payments object. In production code the real Payments implementation is used and a mock version is injected for tests. New requirements After a few weeks in business new requirements arrive. Some people buy more than one coffee so the next version of the software has additional requirements: Buying N coffees Single charge per Credit Card Composition The pro