Module/Class Organization

[Trans]

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

2) BASE CONTAINER

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

class Foo
...

class Bar < self
end

end

3) 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

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

 

[Robert Klemme]

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

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.

2) BASE CONTAINER

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

class Foo
...

class Bar < self
end

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.

3) 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

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

4) 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

 

[Daniel DeLorme]

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

 

[Rick DeNatale]

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! <G>

 

[Robert Dober]

Ah, but all your base belong to us! <G>

are belong to us
Sorry could not resist

 

[Trans]

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.

 

[Robert Klemme]

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

 

[Trans]

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.