My issue here is that BorrowABook is a verb. This isn't a model class, and in my understanding of OOP, doesn't really deserve a class by itself at all. You could instead put the borrow method in a class called Book that represented the model of your application. Then you call borrow on the book, the book does some logic, and returns a status code to the controller. Or since it's a bit silly to ask a book to borrow itself, have a library model object that handles a bunch of book objects, and put the borrow method in the library class. That's how I do MVC anyways.
BorrowABook is a Command. What the article is, albeit unknowingly, discussing is roughly the CQRS pattern. CQRS can rarely ever be considered to be a bad practice. As good developers mature, they come to realise that generally all the good patterns in the world worth pursuing have traits of immutability, messaging and functional programming (FP), even in OOP-land. Most good OOP designs are merely trying to emulate what FP does.
I agree with this...perhaps it is more akin to a factory method, where parameters are passed in and a book, with its borrow status affected, is returned?
