创建一个由许多子类组成的类库

Question

This is a follow-up to my previous question Stop my "Utility" from giving errors between different architectures , suppose I am trying to create a class library that looks something like this:

- Class Utility (Parent class)
     ... Utility functions and methods
         (EG: Public Sub Sub1() )

  - Class Utility_Web
       ... Functions and methods only related to Web / Web-Controls
         (EG: Public Sub Web_Sub1() )

  - Class Utility_WinForms
       ... Functions and methods only related to Winforms / WinForm-Controls
         (EG: Public Sub WinForm_Sub1() )

Now, what I would like to be able to do is to just add the Utility dll as a reference to any of my projects and be able to access the functions and methods from ALL 3 of these classes by simply typing in, for example:

Utility.Sub1
Utility.WebSub1
Utility.WinFormSub1

In other words, not having to type :

Utility.Utility_Web.Websub1

And making it so that the end-programmer doesn't need to know the internal structure of this utility, they can reference all it's methods / functions with just the Utility. nomenclature.

How would I go about doing that? Is this where NameSpaces come into effect? Inheritance ? Partial Classes ? Modules rather than classes?

Answer 1

There doesn't seem to be any reason for these methods to be in separate classes if they are going to be accessed using the same class name.

If you want to split the code across many source files for organizational purposes, you can use partial classes .

Answer 2

This seems like an excellent instance where you'd want to use partial classes, all using the same Utility namespace. That would allow you to access the methods with Utility.WebSub1 and reduce a step.

Answer 3

A class named Utility is a bad class from the start. What is its utility? What does it help you do? How many other people are going to name classes Utility?

Name your classes for what they do, associate them in the namespaces where they make logical and functional sense.

Let's say that you are making a set of static methods that help out with a class that represents a Month . Why not put the methods into Month ? If you're writing methods to transform data from one representation to another, name it that way (ie, MonthDataTranslation ).

Don't worry about typing on the part of your clients or your client code. Intellisense and the C# using statement mitigate that a great deal and given the choice between a badly named, nebulous Utility class and a long, well-named class, I will pick the latter every single time.