Design Question

[Mochi Mochigome]

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

 

[David Masover]

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.

 

[Carl Jenkins]

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?

 

[Carl Jenkins]

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

http://www.ruby-forum.com/topic/213323#new

 

[Mochi Mochigome]

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