The way I've come to understand this is that a method is how an object responds to a message or messages.
I've come to learn that a lot of us think about creating classes first and the conversations second. Conversations and the messages in these conversations should, often times, tell us whether creating a class right now is needed. I really follow the philosophy of putting off decisions to lock oneself into an abstraction too early on (not enough information/data) and preserving flexibility. Often times, a struct is enough for carrying pieces of a related idea around. It isn't until its internal state or a need for it to have conversations with other objects do methods defined in a class make sense. Furthermore, classes without methods are just state containers.
I write some Ruby and some of the basis of my ideas come from Sandi Metz's book, "Practical Object-oriented Design in Ruby" where she describes message-passing.
I've come to learn that a lot of us think about creating classes first and the conversations second. Conversations and the messages in these conversations should, often times, tell us whether creating a class right now is needed. I really follow the philosophy of putting off decisions to lock oneself into an abstraction too early on (not enough information/data) and preserving flexibility. Often times, a struct is enough for carrying pieces of a related idea around. It isn't until its internal state or a need for it to have conversations with other objects do methods defined in a class make sense. Furthermore, classes without methods are just state containers.
I write some Ruby and some of the basis of my ideas come from Sandi Metz's book, "Practical Object-oriented Design in Ruby" where she describes message-passing.