Impure functions

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?

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

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

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”

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”

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

2 Likes