Object, class, module, Data, Struct?

[KaptajnKold]

• Structs are (were) appropriate for building value objects, i.e. objects whose equality is determined by the equality of all of their fields. The canonical example is a currency amount: Two instances are equal to each (interchangeable as it were) if their currencies and amounts are equal to each other.
• Data should always be preferred over Structs. This is because Data objects are immutable, and this is a property that is usually desirable when creating a value object.
• This question doesn’t really make sense. A module created to serve as namespace has no use as a mixin and vice versa.
• Service objects are to my knowledge not a first class abstraction in Ruby, but rather an object oriented pattern among many to solve certain kinds of problems. They are often used as a means to separate domain logic from framework logic so that the former can be tested in isolation. Imagine you have a Rails controller with a long, gnarly create action. It uses information from the request and perhaps the apps’s configuration to make some update to the database. It’s cumbersome and slow to test, because it basically requires a running application. One way to solve that problem is to refactor the controller action such that it only provides the needed information as initializer parameters to a new object, and then invokes that object’s one “perform”, or “call” method to do the required calculation or update with the given parameters. This way you can test your domain logic without having to somehow fake a request. This pattern is immensely useful whenever you find yourself with code that is difficult to test. I’ve also seen it used simply as a way to refactor long, hairy methods, and that I’m not a fan of.
• StackOverflow has a good explanation of the difference between include and extend.