Richard O'Keefe wrote > Whatever else it is, OOP is a means to an end, not an end in itself. > It's not a religion.
Richard makes an important point here. As I mentioned on Discord (slightly edited to fit this thread), it’s a judgment call with trade-offs, but for the purposes of an OOP exercise, I would say absolutely put the methods in object and wherever else you may need them - if only to get practice with that particular idiom. I needed to do a lot of that sort of thing - probably way *too* much, just to break my procedural thinking habits. Once I got it "in my bones" I became more pragmatic. While in theory, this may always be the “most“ OOP way, in practice it can be confusing due to the limitations of our system organization and the fact that people will have to scroll through more methods on kernel objects (not to mention the extra dependencies Richard noted). That is the dogma, and I think is a fine answer for an OOP exercise, but IMHO in practice there are justifiable exceptions. The two major axes are understandability and adaptability. If in your domain there are only two choices and there can not logically be more, it may be easier to understand one method with a conditional that documents that domain fact, than it would be to dive down a polymorphism rabbit hole spread across the system. Of course, tooling is a big factor in understandability. In GT it may be trivial because you can open implementors in a plane right next to the code browser. Different toolsets themselves mean different trade offs. There are no one size fits all answers for all time. There are principles that have to be negotiated with your current environment, use case, experience level, team size... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
