Module/Class Organization

I wonder what’s the general consensus on modular organization. Overall
there seems to be four general approaches.

  1. BASE CLASS

ActiveRecord, uses this design:

module Foo

  class Base
  end

  class Bar < Base
  end

end
  1. BASE CONTAINER

An alternative is to call the base class Foo and use it as a
container:

class Foo
  ...

  class Bar < self
  end

end
  1. EXTERNAL BASE

In this case the organizing module contains a plurality of
subclasses. The base class is external to this module.

class Foo
end

module Foos

  class Bar < Foo
  end

end
  1. BY NAME

No container modules, just use naming:

class Foo
end

class BarFoo < Foo
end

Which is better? Are there serious advantages/disadvantages to any of
these?

Thanks,
T.

On 02.06.2007 18:02, Trans wrote:

  end

  class Bar < Base
  end

end

I’d rather call this “namespace” because that’s what the module is all
about here. IMHO this is the best approach for custom libs because it
helps keep namespaces clean. Also, if someone is using classes from
this module only, it’s easy to place an include Foo at the top of the
script to pull all classes defined in Foo into the current namespace.

end

IMHO that’s the worst of all presented approaches because it combines
two mechanisms that create dependencies between classes (inheritance and
nesting) that support different aims. I’d use nesting for classes that
are closely related to the outer class and make most sens in this
connection. Inheritance (besides delegation) is the usual way to extend
classes, probably even from another module / lib.

  class Bar < Foo
  end

end

I haven’t seen this one and would not do it because it does not ensure
proper use of namespaces.

  1. BY NAME

No container modules, just use naming:

class Foo
end

class BarFoo < Foo
end

I would not use this one in a custom lib because namespaces are really a
better grouping mechanism than name suffixes. Even if you use BarFoo as
subclass name I’d rather do it in a module.

Which is better? Are there serious advantages/disadvantages to any of
these?

There are probably more pros and cons but when I would be writing a lib
I’d certainly use the first approach.

Kind regards

robert

Trans wrote:

  1. BASE CLASS

The only reason this is popular - or even exists at all - is because it
was introduced by rails. I don’t think this naming was ever used before
rails, and for good reason; what kind of name is “Base”?

Which is better? Are there serious advantages/disadvantages to any of
these?

As far as naming is concerned I don’t think you can objectively select a
“best” approach; semantics are too subjective. But the “base class”
approach does have the property of isolating constants defined in the
container namespace whereas the “container class” approach does not:

class A
K = 1
class B < A
end
end
A::B #=> 1
A::C::B #=> 1

Whether you consider that an advantage or an drawback is up to you.

Daniel

On 6/4/07, Rick DeNatale [email protected] wrote:

On 6/3/07, Daniel DeLorme [email protected] wrote:

The only reason this is popular - or even exists at all - is because it
was introduced by rails. I don’t think this naming was ever used before
rails, and for good reason; what kind of name is “Base”?

Ah, but all your base belong to us!
are belong to us
Sorry could not resist :wink:

On 6/3/07, Daniel DeLorme [email protected] wrote:

The only reason this is popular - or even exists at all - is because it
was introduced by rails. I don’t think this naming was ever used before
rails, and for good reason; what kind of name is “Base”?

Ah, but all your base belong to us!


Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

On Jun 2, 1:00 pm, Robert K. [email protected] wrote:

  class Bar < Foo
  end
end

I haven’t seen this one and would not do it because it does not ensure
proper use of namespaces.

Sorry for the delayed response on this. So very busy.

Could you explain further what you mean by “does not ensure proper
use”.

Thanks,
T.

On Jun 15, 5:50 am, Robert K. [email protected] wrote:

class Foo

Could you explain further what you mean by “does not ensure proper
use”.

Foo is not part of the namespace but its subclasses are. Considering
that they seem to be part of one library and thus closely related I find
this separation “improper” because it a) clutters the global namespace
more than necessary and b) it separates things that rather belong together.

I see. Thanks.

T.

On 15.06.2007 08:28, Trans wrote:

end

I haven’t seen this one and would not do it because it does not ensure
proper use of namespaces.

Sorry for the delayed response on this. So very busy.

Could you explain further what you mean by “does not ensure proper
use”.

Foo is not part of the namespace but its subclasses are. Considering
that they seem to be part of one library and thus closely related I find
this separation “improper” because it a) clutters the global namespace
more than necessary and b) it separates things that rather belong
together.

Kind regards

robert

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs