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.
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
Whether you consider that an advantage or an drawback is up to you.
On 6/3/07, Daniel DeLorme <dan-ml@dan42.com> 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"?
> 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>
are belong to us
Sorry could not resist
···
On 6/4/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
On 6/3/07, Daniel DeLorme <dan-ml@dan42.com> wrote:
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
···
On 15.06.2007 08:28, Trans wrote:
On Jun 2, 1:00 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
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.
Sorry for the delayed response on this. So very busy.
Could you explain further what you mean by "does not ensure proper
use".
On Jun 15, 5:50 am, Robert Klemme <shortcut...@googlemail.com> wrote:
On 15.06.2007 08:28, Trans wrote:
> On Jun 2, 1:00 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
>>> 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.
> 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.
