Re: So much interconnectedness

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?

Replies are listed 'Best First'.
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);" ?	[reply]
Re^3: So much interconnectedness - good or bad? by DentArthurDent (Monk) on Dec 17, 2004 at 14:46 UTC
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!	[reply]
Re^4: So much interconnectedness - good or bad? by kiat (Vicar) on Dec 17, 2004 at 14:57 UTC
Ah, no wonder forum code like YaBB and ikonboard have so many modules :) Thanks!	[reply]
Re^3: So much interconnectedness - good or bad? by hakkr (Chaplain) on Dec 18, 2004 at 20:23 UTC
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.	[reply]


laziness, impatience, and hubris
	PerlMonks

Re: So much interconnectedness - good or bad?