Impure functions


#1

I am reading a book ‘Functional Programming In Scala’ by Paul Chiusana.

It gives an example of impure function as:

class Cafe {
def buyCoffee(cc: CreditCard): Coffee = {
	val cup = new Coffee()
	cc.charge(cup.price)
	cup
 }
}

Author argues that cc.charge() call has side effects,hence the code is difficult to test.

Then a better approach is suggested as:

class Cafe {
def buyCoffee(cc: CreditCard, p: Payments): Coffee = {
	val cup = new Coffee()
	p.charge(cc, cup.price)
	cup
 }
}

Author argues:“Though side effects still occur when we call p.charge(cc, cup.price), we have at
least regained some testability. Payments can be an interface, and we can write a mock
implementation of this interface that is suitable for testing.”

But we can have a similar interface based approach for first implementation too. Then how is second approach a better one?


#2

I tend to agree, especially because the return types of the methods

charge(d: Double) of CreditCard
and
charge(cc: CreditCard, d: Double) of Payments

are nowhere declared

I guess that the idea is that

the CreditCard interface one is exposed by the credit card company and charge has type

charge(d: Double): Unit // charging "just happens"

the Payments interface one is owned by the developer and charge has a flexible type

charge(cc: CreditCard, d: Double): Flexible // whatever you want

for example: maybe Flexible == Payments, where Payments has interesting methods
that are not necessarily exposed by CreditCard to test (besides: later on the
authors introduce Charge and List[Charge], I can imagine that Payments itself
has charge related members that you can test)

but, again, the authors could, maybe, have done a slightly better job here


#3

also asked at https://stackoverflow.com/questions/48567929/why-does-splitting-one-class-into-two-improve-testability


#4

agreed ( again :slight_smile: ), and the answer there, referring to granularity, kind of corresponds to what in the book is referred to as “more modular”


#6

het logo is geinspireerd door Erik Meijer’s vroegere “headiinthebox” GitHub logo (het is vervangen door een “colorful egg” logo) … hoe dan ook het is een beetje een “rabbitinthebox”


#7

The previous message was brought to you by my pocket and auto-correct.