The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

123avi (31) [Avatar] Offline
First I want to say that it is a pleasure reading this book. I implemented most of the stuff in my designs. Just wanted to ask regarding decoupling the logic from the ADT as shown in listing 1.5.

since AccountService is handling Account behavior, is it a mistake or misconception to force a mix-in of this trait with Account rather than using a concrete instance ?
trait AccountService{
  this:Account =>
 def debit( amount: Amount): Try[Account] = {             
            if (balance.amount < amount)  
               Failure(new Exception("Insufficient balance in account"))    
           else Success(this.copy(balance = Balance(this.balance.amount – amount)))   
  def credit( amount: Amount): Try[Account] =      
        Success(this.copy(balance = Balance(this.balance.amount + amount))) 
Debasish Ghosh (116) [Avatar] Offline
Hi -

Thanks for your comments.

First, I would like to say that in design and modeling there's hardly anything that's considered a wrong option. Stated otherwise all modeling options suck, some just happen to work smilie.

But I follow a principle while modeling - that's using the option that brings in the least of coupling between abstractions. In this case if u mix the Account in the AccountService, it will work no doubt. But it creates a coupling that could be avoided. And self type annotation is basically a round about form of inheritance. And inheriting an AccountService from Account doesn't make much sense intuitively.