Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been examining the code base we use in work and I am worried about the size the packages have grown to. The actual code is modular, procedures have been broken down into small functional (and testable) parts. The issue I see is that we have 100 procedures in a single package - almost an entire domain model.

I had thought of breaking these packages down - to create sub domains that are centered around the procedure relationships to other objects. Group a bunch of procedures that have 80% of their relationships to three tables etc. The end result would be a lot more packages, but the packages would be smaller and I feel the entire code base would be more readable - when procedures cross between two domain models it is less of a struggle to figure which package it belongs to.

The problem I now have is what the actual benefit of all this would really be. I looked at the general advantages of modularity:

1. Re-usability
2. Asynchronous Development 
3. Maintainability

Yet when I consider our latest development, the procedures within the packages are already reusable. At this advanced stage we rarely require asynchronous development - and when it is required we simply ladder the stories across iterations.

So I guess my question is if people know of reasons why you would break down classes rather than just the methods inside of classes? Right now I do believe there is an issue with these mega packages forming but the only benefit I can really pin down to break them down is readability - something that experience gained from working with them would solve.

share|improve this question
    
I am not sure what you mean by a package exactly? –  Emmad Kareem Jul 1 '12 at 16:43
2  
Within an oracle database you can group procedures into packages similar to methods being grouped into a class in java. If you want to read more about PLSQL packages, here is a link: docs.oracle.com/cd/B10501_01/appdev.920/a96624/09_packs.htm –  John D Jul 1 '12 at 16:47
    
Of course John D, I have not touched those for about 7 years...Thanks. –  Emmad Kareem Jul 1 '12 at 16:49

1 Answer 1

up vote 1 down vote accepted

Right now I do believe there is an issue with these mega packages forming but the only benefit I can really pin down to break them down is readability

Well, IMHO the point you are missing here is better encapsulation. If you are going to add a new feature to a mega package with 100 functions, you may have to check for side effects or similar things in all those 100 functions (YMMV depending on the actual problem). If you split your package before into 5 smaller packages, you can probably handle such a change more easily, since it may impact a smaller area of your code.

However, when you only seldom change your packages and functions, you have to consider if such a refactoring is worth the trouble - a big refactoring should never be applied just for the sake of itself. And I guess you don't have any refactoring browser for PL/SQL which could assists you (does such a thing exist?), so such a restructuring could mean a lot of work.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.