Tightly integrated private helper class in ASP.NET

Semi-unimportant background: I'm working on a page with two sets of collapsable panels. (using nHibernate) I get category objects with a list of items in them, and for each category generate a left panel and right panel. In both panels, there is a ListBox. Items are pre-populated to the left list box and the user can select and move items into the right list box (under the corresponding category.)

As I've built and worked on it, I ended up with a lot of generic methods like buildPanel(side,categoryID) and then ended up with a lot of repeated if statements inside them to differentiate between the two sides

if type=PanelType.Left then 
    set these 5 id strings to access components
else
    ...

The code got messy, so I moved a lot of the logic and static builder strings for the component ids into a private helper class in order to make other parts of the main class easier to read and follow. The problem I see is that the private class is extremely dependant on specific structures in the parent class. There's a very minimal amount of encapsulation going on and I'm possibly making the logic harder to follow even if the individual components in the code are easi开发者_如何学运维er to read.

My question is: When you're using a private class like this, is it acceptable to have it tightly integrated with the parent class (since it's private and implemented in the same file), am I better to refactor again and find a way of either simplifying my original code to be as short as possible without the helper class (stick all category/panel functions in one spot and hide them in their own region when I'm not using them), or should I move towards putting more of the logic in the helper class and simply mapping my events directly to the subclass.

After typing all this out, I'm leaning towards the last option, but I'm still torn/confused about the whole thing...

Pages are classes and as any class they can grow unwieldy. When you come to the stage where code is heavily coupled, it kind-of depends on how this coupling shows whether or not you should refactor. If the code is clear, concise and easy to follow, it's ok to leave it as it is. But if its hard to follow, if you cannot explain it to a co-worker in a few minutes or you think you won't understand it yourself in half a year than it's eligible for refactoring.

The Law of Demeter (light coupling) shouldn't only be applied in inter-class relationships, but also in inter-method relationships. This is often overlooked or underestimated. But sometimes too much refactoring leads to another extreme: too little coupling can become unreadable, too (just as having too many small methods or too many big ones).

I usually ask myself the question: does the code read like a book with clear chapters and storyline, or do I have to read each paragraph twice, or worse, turn back pages to understand it?

If you never use this panel mechanism on another page, then you don't need to refactor.

Furthermore, until you need to use it on another page, you don't know how to refactor the private class to make it reusable.