# Design Question

**URL:** <https://www.ruby-forum.com/t/design-question/192135>\
**Category:** Ruby\
**Created:** [July 24, 2010, 4:24pm UTC](https://www.ruby-forum.com/t/design-question/192135 "2010-07-24T16:24:26Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mochigome](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@mochigome](https://www.ruby-forum.com/u/mochigome)\
**Post date:** [July 24, 2010, 4:24pm UTC](https://www.ruby-forum.com/t/design-question/192135/1 "2010-07-24T16:24:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mochigome](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@mochigome](https://www.ruby-forum.com/u/mochigome)\
**Post date:** [July 25, 2010, 12:40am UTC](https://www.ruby-forum.com/t/design-question/192135/2 "2010-07-25T00:40:39Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mochigome](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@mochigome](https://www.ruby-forum.com/u/mochigome)\
**Post date:** [July 25, 2010, 3:04am UTC](https://www.ruby-forum.com/t/design-question/192135/3 "2010-07-25T03:04:36Z")

</div>

David M. wrote:

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

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?

---

<div class="post-metadata">

**Author:** ![mochigome](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@mochigome](https://www.ruby-forum.com/u/mochigome)\
**Post date:** [July 25, 2010, 3:07am UTC](https://www.ruby-forum.com/t/design-question/192135/4 "2010-07-25T03:07:00Z")

</div>

> 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](http://www.ruby-forum.com/topic/213323#new)

---

<div class="post-metadata">

**Author:** ![mochigome](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ed655f/32.png) [@mochigome](https://www.ruby-forum.com/u/mochigome)\
**Post date:** [July 25, 2010, 3:25pm UTC](https://www.ruby-forum.com/t/design-question/192135/5 "2010-07-25T15:25:35Z")

</div>

David M. wrote:

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

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