G'day tusker,

Welcome to the Monastery.

Using class names like A, B, C and D, doesn't make it easy to visualise your overall class structure.

In general terms, A::B::C doesn't imply that B inherits from A nor that C inherits from A::B; it does, however, imply that B is somehow related to A and C is somehow related to A::B.

Having said that, it often makes sense to use naming to logically separate concerns. For instance, A might compose B::C or B::D while both B::C and B::D inherit from B.

Consider these contrived classes:

Building
Building::House
Building::Shed
Building::Garage
Vehicle
Vehicle::Car
Vehicle::Train
Vehicle::Motorcycle
Door
Door::Hinged
Door::Sliding
Door::Roller
[download]

The various Building::* and Vehicle::* classes could compose zero, one or more Door::* classes.

By sticking with your current class structure, you could end up with a huge number of classes such as this:

Building
Building::House
Building::House::Door
Building::House::Door::Hinged
Building::House::Door::Sliding
Building::Shed
Building::Shed::Door
Building::Shed::Door::Hinged
...
Vehicle
Vehicle::Train
Vehicle::Train::Door
Vehicle::Train::Door::Hinged
Vehicle::Train::Door::Sliding
...
[download]

This quickly starts to become unmanageable. Building::House::Door, Building::Shed::Door and Vehicle::Train::Door will probably have duplicated code; as will Building::House::Door::Hinged, Building::Shed::Door::Hinged, Vehicle::Train::Door::Hinged, and so on. Throw in a variety of Lock, Handle, etc. subclasses and you're facing a maintenance nightmare.

I'd recommend spending a bit more time on your class design before writing any code. Class names with duplicated portions will probably equate to duplicated code which you should endeavour to avoid.

[A note on nomenclature. You used the term "composition" in your question and I continued its use; however, in the strictest sense, that may be inappropriate in some cases. There are other types of relationships (e.g. "aggregation", "association", "delegation"): at times, it's important to be specific about which you're referring to. You may already know about these; if not, most introductory OO texts will describe them.]

Thanks for your answer! It's good to read that module hierarchy does not have to be pure inheritance. Indeed I try to avoid having excessive depth in my modules hierarchy. I use it only to create compartments for autonomous code. I don't think I would end up with the last situation you described, as it would indeed lead to a high quantity of redundant code. I indeed know about the OO nomenclature and the objects I'm dealing with constitute really a composition. Thanks for the reminder!

Your current structure sounds fine to me.

I think people will believe that B, C and D are inheriting A and not composing it.

If, as you say, B, C and D are only ever used by A then the casual user probably won't even consider that they exist. Anyone after more than that will read the documentation and so long as that is clear there should be no confusion.

What is the currently considered a best practices for module organization and naming when it comes to composition?

I don't know that there is really a set of best practices for that specifically. If in doubt, go for clarity (which is again in the eye of the beholder). If you have specifics (ie. the actual proposed names) then you can ask here or on PrePAN.

Thanks! Your answer converges with other advices I got. But there is never enough wisdom, so I wanted the monks advice.

Crossposting is OK, but it's considered polite to inform about it to prevent unnecessary work by people not attending both the sites.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Hell, sorry. I thought about mentioning it on Stackoverflow and forgot to do the other way around.