From: David Masover <ninja@...>
Date: 2010-07-25T07:19:17+09:00
Subject: Re: Design Question

On Saturday, July 24, 2010 09:24:28 am Mochi Mochigome wrote:
> Hi guys,
> 
> I have a program design question regarding mix-ins.
> 
> I currently have 5 modules:
[...]
> and a single class which includes all those modules:
> 
> class Client
>   include Authentication, User, Issue, Network, Object
> end

That's not bad in and of itself. It depend show big the modules are.

> So, is there a more elegant way of doing this?

Separate objects.


class Authentication
end

class User
end

class Issue
end

class Network
end

class Client

  def initialize
    @authentication = Authentication.new
    @user = User.new
    @issue = Issue.new
    @network = Network.new
  end
  attr_reader :authentication, :user, :issue, :network
end


That may or may not work well, depending what you're trying to implement. For 
example, does it make sense to reason about a User or an Issue which stands 
alone, and isn't part of anything else?

Basically, _is_ a Client a User, or does a Client _have_ a User?

You may also find that both make sense, sometimes. For example, DataMapper has 
a module that you include (Resource) which extends your class in a number of 
ways to behave like a model object should, but it also ties you into a number 
of separate objects. Some of them obviously shouldn't be part of your class, 
like the repository (represents a database connection). Some of them, though, 
are only about your class -- State, for example -- and of course, you get a 
whole list of properties.

But what you've got isn't necessarily bad.