Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: So much interconnectedness - good or bad?

by DentArthurDent (Monk)
on Dec 17, 2004 at 14:12 UTC ( #415629=note: print w/ replies, xml ) Need Help??


in reply to So much interconnectedness - good or bad?

I've been in that situation before, not so much in Perl, but in C. If you end up using all of them together because they are so tightly coupled, then what you really have is one big module even if it's in several files on disk.

Perhaps what's really needed here is a new concept of what separates the modules. I can go on and on with respect to the fact that low level libraries (like it appears A and D are) shouldn't depend on higher level ones, but without knowing your situation that's really not valuable.

Start with the functions that are atomic and don't depend on anybody else. Then build from that layers, making modules that depend only on those atomic functions. Then add layers above that that build on the 2nd layer modules. Make the distinction between the modules and layers functional where one module does one job and it should become more clear where the lines are.

Above all though, this is an issue of if it ain't broke don't fix it. Unless this is causing you heartache, or you have time to burn, or it's making your application buggy, don't mess with it.

----
My mission: To boldy split infinitives that have never been split before!


Comment on Re: So much interconnectedness - good or bad?
Re^2: So much interconnectedness - good or bad?
by kiat (Vicar) on Dec 17, 2004 at 14:25 UTC
    Thanks, DentArthurDent!

    I've a more specific question and hope you can help.

    Let's say I've two modules X and Y. Module X has a function func_x that it uses. That function is also used by Y.

    Should I pull func_x out of X and put it in a separate module? Or is it okay to have it reside in X (and be exported) and let Y use it via "use autouse X => qw(func_x);" ?

      In a vacuum with no other functions to consider it doesn't matter. Let's put it this way. You can't go wrong putting it in a new library or module. That's especially true if there are many functions that X and Y share. You can go wrong putting it in X. If you followed the same procedure and added one to Y that X uses after that then you're right back where you're at right now.

      That's why each module should do one job to the greatest extent possible. Your lowest level modules might be a bit of a mishmash because they could provide many low level services, but higher level ones should do one job so that they don't need to depend on one another. That way when you want to do one specific thing, you can include as little as possible and not have to get a huge group of modules to do one small job.
      ----
      My mission: To boldy split infinitives that have never been split before!
        Ah, no wonder forum code like YaBB and ikonboard have so many modules :)

        Thanks!

      Or is it okay to have it reside in X (and be exported)

      If you start to try and follow some of the OO advice I would stay away from using exporter if you can.

      Some of the worst spaghetti i.e overly interconnected code I have seen has used exporter so much everything might as well be in one big file.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://415629]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (10)
As of 2014-09-02 19:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (29 votes), past polls