views:

99

answers:

6

I currently have a VB.NET class named "Customers" and it's been steadily growing in size and I now have a couple dozen functions in it. Is there a way of maintaining the functions in the same class? Since they still use common private methods, but group them by similarity.

For example:

Class Customers
-GetData
---GetCustomerObject()
---GetCustomerFieldx()
-Lists
---GetSomeList()
---GetAnotherList()
-Maintenance
---AddCustomer()
---DeleteCustomer()
---UpdateCustomer()

UPDATE: I guess I wasn't clear on where I wanted this grouping to occur. I want the groupings to be almost like namespaces/classes in IntelliSense when I use my Customer class. I currently use Regions but they only help when seeing the code, not when using the class.

+1  A: 

Use code regions in your source files. This gives you expand/collapse buttons so you can hide sections of the file.

#Region "GetData"
    ... code ...
#End Region

#Region "Lists"
    ... code ...
#End Region

#Region "Maintenance"
    ... code ...
#End Region
womp
A: 

Region is one solution which I recommend. But you can also use partial classes.

Carl Bergquist
+3  A: 

I'd not recommend regions to group content in your files on a general basis.

If your file grows to such a size that you feel you need to group things to regain control then that is a hint you should try to refactor the class into several classes each responsible for a subset of what the original class did, so that you do not end up with the untestable mess that is the God object

AndreasKnudsen
+1  A: 

It seems to me that the Customers class may be doing too much and needs to be broken down to adhere to the Single Responsibility Principle. The idea is that a class knows how to do one thing well and getting data is a different responsibility to performing business logic with said data. I'm currently going through the learning process of trying to break down my monolithic classes into smaller, more targetted ones so I can't give great advice about how to do this, but there are lots of resources on the web to help:

like this

Have a bit of a google for SOLID and Uncle Bob (Robert C. Martin) for extra added goodness.

eviltobz
A: 

And remember, when you do break the class up into much smaller classes, you have the ability to place them in an arbitrarily-deep namespace system. The Project.Customer.Data namespace could house the GetCustomerObject and GetCustomerField classes.

(As much as anything, I'm trying to teach myself to apply SOLID to my VB.NET work. Is this the kind of thing that you ended up implementing?)

clweeks
+2  A: 

I don't see any code showing you how to implement the suggestions, so I will add it here. You need to break the code into classes based on function. Then add the namespace keyword to each of the classes you make. Here is the MSDN article with more detail (http://msdn.microsoft.com/en-us/library/ms973231.aspx#assenamesp_topic3). Here is the psuedo code. Then you would reference the code by using projectname.namespace.classname.method.

namespace Customers
-Class GetData 
---GetCustomerObject() 
---GetCustomerFieldx()
end namespace

namespace Customers 
-Class Lists 
---GetSomeList() 
---GetAnotherList() 
end namespace

namespace Customers 
-Class Maintenance 
---AddCustomer() 
---DeleteCustomer() 
---UpdateCustomer()
end namespace
Wade73