Another thing I was wondering: In both examples the "Tell Don't Ask" violations happen in "do-er"-classes (Charg_er_, Post_er_). As you said, those are a common way of moving responsibilities out of God-objects. I am wondering if this trade-off between God-objects and "Tell Don't Ask" violations/feature envy hints at a general problem in object oriented programming. The two examples in your video actually illustrate this quite well: - The urge to collocate logic and data to prevent breaking encapsulation - The need to place methods in a class in order to perform polymorphic dispatch I have the impression that this is less of an issue in functional programming, since - data structures are often more of a first class citizen and can be used/transformed by functions in different modules - pattern matching and multimethods allow to dispatch dynamically with regard to arbitrary parameters - not just `self` Not sure if this is too off topic, but would like to hear your take.
There is no such trade-off in general. This video is just an example of two not particularly good refactorings, and the problems that they have. It explains why they're not good; it doesn't give the alternative best practices.
I think `charge!` is a rather counter intuitive name for the method. From a client's point of view, I'd much rather expect the bang version to always charge money no matter what, while `charge` might be tied to additional requirements. I know it's not the point here, but it surely diverted my attention.
Hey Ben, how do you do multi-file / project level search and replace in VIM that doesn't suck?
greplace.vim is...fine. Haven't tried anything that blows me away.
Another thing I was wondering: In both examples the "Tell Don't Ask" violations happen in "do-er"-classes (Charg_er_, Post_er_). As you said, those are a common way of moving responsibilities out of God-objects. I am wondering if this trade-off between God-objects and "Tell Don't Ask" violations/feature envy hints at a general problem in object oriented programming. The two examples in your video actually illustrate this quite well:
- The urge to collocate logic and data to prevent breaking encapsulation
- The need to place methods in a class in order to perform polymorphic dispatch
I have the impression that this is less of an issue in functional programming, since
- data structures are often more of a first class citizen and can be used/transformed by functions in different modules
- pattern matching and multimethods allow to dispatch dynamically with regard to arbitrary parameters - not just `self`
Not sure if this is too off topic, but would like to hear your take.
There is no such trade-off in general. This video is just an example of two not particularly good refactorings, and the problems that they have. It explains why they're not good; it doesn't give the alternative best practices.
I think `charge!` is a rather counter intuitive name for the method. From a client's point of view, I'd much rather expect the bang version to always charge money no matter what, while `charge` might be tied to additional requirements. I know it's not the point here, but it surely diverted my attention.