Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Perl modules hierarchy and composition

by tusker (Novice)
on Jan 06, 2017 at 10:57 UTC ( #1179070=perlquestion: print w/replies, xml ) Need Help??

tusker has asked for the wisdom of the Perl Monks concerning the following question:

Reading more and more about Perl, I'm having doubts about how I organized my modules on my current project.

I have a main namespace - let's call it "MyProject". I have objects from class A that are composed of objects of class B, C and D. Classes B, C and D are used by class A only, so it made sense to me to organize the modules as follows:

  • MyProject::A
  • MyProject::A::B
  • MyProject::A::C
  • MyProject::A::D

But I'm starting to think that it will make sense to me only if I ever dare to relase parts of my project in CPAN. I think people will believe that B, C and D are inheriting A and not composing it.

So: shall I reorganize my modules this way?

  • MyProject::A
  • MyProject::B
  • MyProject::C
  • MyProject::D

Or maybe indicate that B, C and D are parts of A by appending their names?

  • MyProject::A
  • MyProject::AB
  • MyProject::AC
  • MyProject::AD

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

Replies are listed 'Best First'.
Re: Perl modules hierarchy and composition
by kcott (Archbishop) on Jan 06, 2017 at 16:50 UTC

    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

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

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

    — Ken

      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!
Re: Perl modules hierarchy and composition
by hippo (Bishop) on Jan 06, 2017 at 11:20 UTC

    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.
Re: Perl modules hierarchy and composition
by BillKSmith (Monsignor) on Jan 06, 2017 at 16:07 UTC
    The book "Perl Best Practices" (ISBN 0596001738) has a chapter on naming conventions. The first few pages deal with package names. The author suggests a scheme and his reasons for it. In the introduction, he points out that it is important to adopt and use a consistent scheme, not necessarily his.
Re: Perl modules hierarchy and composition
by choroba (Cardinal) on Jan 09, 2017 at 10:25 UTC
    Crossposted to StackOverflow.

    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,
      Hell, sorry. I thought about mentioning it on Stackoverflow and forgot to do the other way around.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1179070]
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (3)
As of 2023-09-26 03:42 GMT
Find Nodes?
    Voting Booth?

    No recent polls found