Design Question

ruby-talk
1

Hi guys,

I have a program design question regarding mix-ins.

I currently have 5 modules:

module Authentication
end

module User
end

module Issue
end

module Network
end

module Object
end

and a single class which includes all those modules:

class Client
  include Authentication, User, Issue, Network, Object
end

But while i've done this and it works fine I'm thinking it is poorly
designed because I've not see so many modules mixed in to a single class
for this size of program before.

The modules represent different aspects of an API i'm implementing, so I
decided to separate them into modules to be neater. The client class has
all those aspects so that's why I put them in modules and mixed them in.

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

m

···

--
Posted via http://www.ruby-forum.com/.

2

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.

···

On Saturday, July 24, 2010 09:24:28 am Mochi Mochigome wrote:

3

David Masover 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.

I hope it is OK that I ask a related question. ( not sure what the
etiquette is for this)

When programming in Java people use interfaces everywhere in order to
program to generic objects.

Is this how Modules work as well? If someone includes Modules as the OP
mentioned that class just uses those modules it is almost as if we have
composition no?

So in Ruby is there no such thing as programming to interfaces as there
is in Java?

···

On Saturday, July 24, 2010 09:24:28 am Mochi Mochigome wrote:

--
Posted via http://www.ruby-forum.com/\.

4

David Masover 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.

After thinking more about it and doing some reading I changed my design
to something similar to yours but using delegation.

e.g.

require 'forwardable'

module App
  class Client
    extends Forwardable

    def self.user; User.new end
    def_delegators :user, :show, :search

    def show_user
      Client.user.show
    end
    def search_user
      Client.user.search
    end

  end
end

module App
  class User
    .
    .
    .
  end
end

m

···

On Saturday, July 24, 2010 09:24:28 am Mochi Mochigome wrote:

--
Posted via http://www.ruby-forum.com/\.

5

I hope it is OK that I ask a related question. ( not sure what the
etiquette is for this)

When programming in Java people use interfaces everywhere in order to
program to generic objects.

Is this how Modules work as well? If someone includes Modules as the OP
mentioned that class just uses those modules it is almost as if we have
composition no?

So in Ruby is there no such thing as programming to interfaces as there
is in Java?

Ehh I just found someone who asked the exact same question... thanks..

···

--
Posted via http://www.ruby-forum.com/\.