People don't say "I can't write code like this" because they don't trust the objects to do the right thing. They say it because abstractions don't always remove cognitive cost, sometimes they add it. The cognitive cost is added when the roles are chosen poorly: people don't know what a justifier is, or what a subsetter is, or what a source is. These ad-hoc abstractions are a product of the programmer's mind and have to be carefully documented and explained once introduced.
Go ahead, make my day. And you did, Sandi! I will forever more be referring OO noobs to this video, and most especially _Procedures vs OO_ (at time 6:00 ). This gem should be on StackOverflow with its own tag - "OO Zen".
I enjoyed this talk and I like having these examples that clearly show what's wrong and how to fix it. These are not OO patterns, though. You can do all of this in any functional language and even in C with function pointers. And if you are choosing between just two choices then I really must wonder how much better a class/function is compared to an if condition. You can still take out the if condition from the original function and put it in its separate function/class/whatever you like. Your code will be much faster and you'll concentrate more on what actually needs to get done
I think she misspoke a little when she said "part 2". Parts 1 - 3 of her original numbering are part 1 in the misspoken numbering. Part 4 is the part 2 she misspeaks.
Fantastic talk, well researched and explained but I think one mistake on the code. At 36:32 you can see .new(...).lines -> each sub-class calls 'lines'. At 37:00 when that logic is moved to the factory the .new does NOT call lines on the sub-classes. Hence the factory will return an instance of the subclass, and not the result of calling lines as before. At 37:16 you say it will 'give you back the right thing' but actually it will give you back the class instance, and not the result of calling lines. Because Clump.lines is calling the factory lines method, not the sub-class lines method.
