How do you organize classes on a large project?

Question

We have a ton of features in our application that can be described very concretely as a module. The usually have some sort of setup dialog, then when the user clicks ok, it configures a process to run and runs that process. Sometimes they are more involed and the user will open up the new dialog and work on the dialog for a while, doing many things that make changes to the underlying database.

I typically end up with several standard classes

ConfigPanel.cs
ConfigPanelData.cs
ProcessRunner.cs
ApiWrapper.cs (for calling the process from somewhere else)

If I had a more end to end module it might be WorkerPanel.cs WorkerData.cs SetupOptions.cs (panel state persisted between runs) Lib/WhateverBackendStuffINeedToSupportModule ApiWrapper

Right now there are folders for each one:

UI/Panels/
    Module1Panel.cs
    Module2Panel.cs
UI/PanelData/
    Module1PanelData.cs
    Module2PanelData.cs
UI/PanelManagers
    Module1PanelManager.cs
    Module2PanelManager.cs
Core/Module1/
    Module1.cs
    Module1Helpers.cs
Core/Module2/
    Module2.cs
    Module2Helpers.cs

As you can see, everything is really spread out. With 50+ modules those folders aren't really organized. Even breaking them up by subsystem, they are still a mess. Would it be bad design to just put everything together so everything is separated by function rather than class type?

Module1/
    Module1Panel.cs
    Module1PanelData.cs
    Module1PanelManager.cs
    Module1PanelLib.cs
    Module1PanelWrapper.cs
Module2/
    Module2Panel.cs
    Module2PanelData.cs
    Module2PanelManager.cs
    Module2PanelLib.cs
    Module2PanelWrapper.cs

How do you organize your classes and what are the advantages / disadvantages?

Answer 1

Would it be bad design to just put everything together so everything is separated by function rather than class type?

There's no general rule, it depends on the situation, your personal preferences and change patterns in your code. However I would suggest doing the following:

• Keep as much of the common code in the superclasses to eliminate any redundancy. Maybe then some of the subclasses won't even be needed.
• I'm not sure what you mean by "modules", but I would recommend separating the stuff using namespaces+subdirectories in the same project and not by using separate assemblies. Use assemblies only for deployment separation purposes and similar stuff.
• Those "helper" classes you mention sound a bit code-smelly. They could be a violation of OO principles. Check out this link for more info: http://blogs.msdn.com/nickmalik/archive/2005/09/06/461404.aspx. Maybe you can reorganize the code, reduce the need for such classes AND get a benefit of a cleaner OO design at the same time?