Create a class library with many subclasses
This is a follow-up to my previous Stop my "Utility" question from providing 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 I would like to just add the dll Utility
as a reference to any of my projects and access the functions and methods from ALL 3 of these classes by simply typing, for example:
Utility.Sub1
Utility.WebSub1
Utility.WinFormSub1
In other words, you don't need to type :
Utility.Utility_Web.Websub1
And by doing this so that the end programmer does not need the internal structure of this utility, they can refer to all its methods / functions with only nomenclature Utility.
.
How would I do it? This is where it NameSpaces
comes into effect? Inheritance
? Partial Classes
? Modules
rather than classes?
source to share
There seems to be no reason for these methods to be in separate classes as long as they would be available using the same class name.
If you want to split your code into many source files for organizational purposes, you can use partial classes .
source to share
A named class Utility
is a bad class from the start. What is its use? How does this help? How many more people will be calling the Utility classes?
Name your classes for what they do, bind them in namespaces where they make logical and functional sense.
Let's say that you create a set of static methods that help with the class that represents Month
. Why not include methods in Month
? If you write methods to transform data from one view to another, name it that way (i.e. MonthDataTranslation
).
Don't worry about typing information from your clients or your client code. Intellisense and C # using the statement are very softening and given the choice between the poorly named, vague Utility class and the long, well-named class, I will choose the latter every time.
source to share