little question about naming and organizing functions....

[MrPolite]

I'm making a utility class for myself. I have a little question which is hard for me to explain, so I just wrote this code:

Class GraphicsUtil
      Public Function RectToRectF ...
End Class
 
Public ConvertorUtil
     Public Function ArrayListToString .....
 
[color=red]heres my question, should I do this? it helps me 
organize my code better, but it results in multiple declaration of a 
function:[/color] 
 
     Public Function RectToRectF ()
             ' Calling the function from the other class
            Return GraphicsUtil.RectToRectF...
     End Function
End Class

I just have too many functions and I'm trying to categorize them by putting them in different classes. But some of them like the above function dont fit into one category, so I decided to put them in more than one class. Is this considered bad coding or something? should I aviod this?

[Mr.No]

Have a look at this link http://msdn.microsoft.com/library/de...guidelines.asp. It provides guidelines on naming conventions of classes, variables etc.

[Edneeis]

If the functions do the same thing and aren't different version with the same name then I would put them as shared in a class and then nest the other classes by category inside that class. It basically works like using the namespace but namespaces can't have functions.

Public Class Utilities
 
    Public Class GraphicsUtil
 
    End Class
 
    Public Class ConvertorUtil
        Public Function ArrayListToString()
 
        End Function
 
    End Class
 
    Public Shared Function RectToRectF()
 
    End Function
 
    Private Sub New()
        'if you don't want the namespace type class to be able to be an actual object then use this
        'then it can't be made with the New keyword
    End Sub
 
End Class

[CoMMiE]

If we put a class inside a class wont it make the class hard to maintain when the no of lines of code increase?

is there another way around it?

[Edneeis]

Why would it make it hard to maintain?

The only way the objects are linked is through their namespace really. That and the children can access private members of the parent (although they are not tied to an instance mind you).

If you mean because of the amount of room on the screen then just set some regions up to make each class or parts of them collapsable.

[MrPolite]

Originally posted by Edneeis
If the functions do the same thing and aren't different version with the same name then I would put them as shared in a class and then nest the other classes by category inside that class. It basically works like using the namespace but namespaces can't have functions.

Public Class Utilities
 
    Public Class GraphicsUtil
 
    End Class
 
    Public Class ConvertorUtil
        Public Function ArrayListToString()
 
        End Function
 
    End Class
 
    Public Shared Function RectToRectF()
 
    End Function
 
    Private Sub New()
        'if you don't want the namespace type class to be able to be an actual object then use this
        'then it can't be made with the New keyword
    End Sub
 
End Class

well, ahem, there are more than 2 classes and those functions arent supposed to be shared with all classes I either have to go with my own way, or I have to aviod doing this...
In my first post, I'm just declaring another function with the same name, which calls the function from the GraphicsUtil class. Is it bad if I leave it like this?

[hellswraith]

I don't think your way is going to harm anything. The only thing you will be doing is adding another object to the call stack. If speed is your ultimate concern, you might want to run some tests to see what the performance hit would be, if any.

[MrPolite]

hellswraith, I'm not worried that much about performance So I guess I would go with my way.
I want the user to be able to access the class like this:

Utility.GraphicsUtils.RectToRectF
Utility.Convertors.RectToRectF
Utility.Convertors.....
Utility.....

something like that