I am having a "weird" situation of my VB.Net modules, as per my understanding, Module in VB.Net means static class so I have implemented a couple of helper modules with couple of functions each, let's have some examples for better explanation (free hand code, may contains syntax problem):
Namespace Helpers
Module HelperA
Public Function FunctionA() As Boolean
Return True
End Function
End Module
End Namespace
Namespace Helpers
Module HelperB
Public Function FunctionB() As Integer
Return 1
End Function
End Module
End Namespace
When I start coding in Visual Studio and type Helpers., both FunctionA() and FunctionB() are show up in the recommended auto-complete dialog which I have not type HelperA or HelperB yet, I have some C#.Net projects with static class and I found such behavior does not apply to C#.Net static class.
It is weird to me and inconvenience since I am now having 50-ish functions under a single namespace, have done some Google but nothing could be find, could anyone suggest a solution (besides change Module to Class) or any keywords to search with?
Any help will be appreciate!
Module doesn't technically mean static class. Static in VB.net (with regard to functions) is Shared, and there is no Shared Class. What I think you want is a sealed/abstract/not-inheritable class with static/shared functions (you'll be able to call the functions without an instance of the parent class, but you'll still have to reference the parent class when calling the function). If that's the case, then do something similar to the following:
Public NotInheritable Class HelperA
Public Shared Function FunctionA() as Boolean
Return True
End Function
End Class
Having said that, the only difference I've found—at least for practical purposes—between a shared function and a module function is that module functions can be called without referencing the module.
Related
what is the best way to store functions and sub routines so that every page in my site can use them?
At the moment they are on one aspx.vb page and I would need to copy them to each page I want to use them on, I really don't want to do that.
If you are using VB.NET, you can use a Module in the App_Code folder to store functions.
If you are using C#, you can create a class with static functions
VB.NET:
Public Module Utilities
Public Function MyFuct()
End Function
End Module
C#:
public class Utilities
{
static public string MyFuct()
{
}
}
Then, call using:
Utilities.MyFuct()
Based on what the classes do, I would categorize them into classes, or helper-type static classes. Again, it just depends on what you need them for.
I have a couple of class files in C#. I want to write a method that could be used in all the classes. For example, I am trying to write the method that returns the number of rows from the database table, and I need this in multiple times, so thought of writing a single method to share among all the classes. I thought it would be easy with the use of namespace. But when I add namespace in all the class files, it gives error stating "CONTROL NAME is not present in current context". From the internet search I came to the conclusion that I also need to add the namespace in xxx.designer.cs files. Is it correct? I tried to find the designer.cs files but could not, and in one of the solution it was stated that designer.cs file is created during compile time. If so how to add the namespace on designer.cs file.
Thank you!!!
You need to create a static class and this function that classes need to share has to be a static member.
This function can now be called from anywhere.
static class Helper
{
public static string Calculate(int myVariable)
{
//do some common calculation
}
//...
}
If these classes have common data members and you need to share a common function, you can consider using a base class. All common functionality and common data members would go into the base class, and by merit of inheriting that class, all your sub classes would be able to call this function.
Create a Static class and create static member functions into that. You need not to create instance of the class in this case and you can directly call member function using class name.
Currently, if I have different classes containing functions etc, I would structure them all in the 1 VB file titled whatever the main Class is. For example:
MainClass.vb:
Class MainClass
Function FunctionA() as String
...
End Function
Class SubClass
Function SubFunction() as String
....
End Function
Class SubSubClass
......
End Class
End Class
End Class
However, the problem with this is the file can become 1000s of lines long making hard to find portions of code.
Is there a way I can store SubClass in a file such as MainClass.SubClass.vb so that its easier to locate classes? Or is there a better, more standard, way of doing this?
At least C# understands "partial classes" where you can spread the code over multiple files (within the same assembly)
EDIT
I expected VB to have partial classes also (I only work in C# myself), but as noted in the comments, it does have them.
In C# I could code something like this:
File MainClass.cs:
public partial class MainClass // note the "partial" keyword
{
// some method declarations etc.
}
File MainClass.SubClass.cs:
public partial class MainClass // have to repeat this to hook up correctly
// but an "Implements" or "Extends" could be different
{
// maybe some other methods
private class SubClass
{
// etc.
}
}
But the real question is: do those subclasses really need to be inner classes of that "MainClass", or could they be top-level classes themselves?
Instead of packaging all classes into 1 class you should use multiple classes and Namespaces to store and use your code. Especially with larger Projects this can help you organize your code.
Note: The name of a Namespace may not be the same as one of class. But you can use the same Namespace for multiple classes.
i.e.
Create a "MainClass.vb"
Create a "SubClass.vb"
Code "SubClass.vb"
Namespace Main
Public Class SubClass
Function SubFunction() as String
....
End Function
End Class
End Namespace
So you can access the Class SubClass by "Main.SubClass"
If you have a lot of classes and files you could i.e. create for each Namespace a SubFolder
Main
|-- SubMain
|---|-- SubSubMain
|-- AnotherSubMain
|---|-- SubAnotherSubMain
with the Namespaces
"Main"
"Main.SubMain"
"Main.SubMain.SubSubMain"
"Main.AnotherSubMain"
etc.
To store general functions which are often or commonly used you could also create a library project.
Yes, partial classes in vb.net will allow you to do exactly what you request.
MainClass.vb
Partial Class MainClass
Function FunctionA() as String
...
End Function
End Class
MainClass.SubClass.vb
Partial Class MainClass
Class SubClass
Function SubFunction() as String
....
End Function
End Class
End Class
Leaving aside questions of re-architecting and re-factoring, which is not the question you asked, with a very large class file, described as 1000s of lines long, there may be some additional quick-fix benefits in using even more partial class files to enact a separation of concerns. Use Partial to split the unwieldy class file into logically related bundles of code across multiple smaller .vb files.
How advisable, how effective, or how dirty, this action is is obviously debatable, but the facility does exist, and it would therefore be up to you to take a view on how beneficial/problematic this partitioning option may or may not prove to be.
http://en.wikipedia.org/wiki/Partial_class
I have a class called MembershipHelper, which I am using in my ASP.NET project. It looks like this:
Public Class MembershipHelper
Public Shared Function IsMultiStoreUser() As Boolean
return Roles.IsUserInRole(....)
End Function
Public Shared Function IsAdmin() As Boolean
return Roles.IsUserInRole(....)
End Function
Public Shared Function IsReaderOnly() As Boolean
return Roles.IsUserInRole(....)
End Function
End Class
I read somewhere that its not a good idea to have a class with just shared functions - but I don't remember where.
Why is this bad and how can I improve it?
Thank you
From the naming that you used for your functions it seems that all functions describe properties of a user (e.g. whether the user is an admin).
Therefore it would seem more natural** to have these functions replaced by properties of your user object or by having your user implement an IRole interface.
** I'm not saying that your design is good or bad. Depending on the context such a helper class might very well be reasonable.
Shared functions are like static functions, which in turn are like global functions or objects.
What you are essentially doing in your example is adding some redirection and abstraction, which I think is fine for Helper/Extension classes.
I have a bunch of different forms that I would like to create a base MustInherit class for. One function I would like them all to contain is a shared function called GetForms(). I know that you can't declare a shared function MustOverride so I did the following in my abstract class:
Public Shared Function GetForms() As List(Of OrderForm)
'to be overridden in child class'
Return Nothing
End Function
And this in my child class:
Public Overloads Shared Function GetForms() As List(Of OrderForm)
'do stuff'
End Function
Will this cause problems down the line, or is this an acceptable workaround? It has a smell to it, but it will enforce that all my forms include a shared GetForms function.
EDIT I realize that if this were possible with interfaces, I would use one, but you can't declare shared functions in interfaces and I would like to make sure that this is a SHARED function.
This has a smell because it creates a false expectation of the behavior of the code.
You mention that your reason for doing this is that 'it will enforce that all my forms include a shared GetForms function'. This is only partly true. Yes, they will all have the GetForms function, but you're not actually forcing the derived classes to implement their own version of it. If you forget to implement the function on one of them, you'll be calling the base version, and you won't get any sort of warning about it from the compiler.
That is the smell: it can't actually enforce the behavior that you want, but it creates an impression, at first glance, that it can. This will lead to headaches 6 months from now when you're adding a new Form type and you've forgotten the convention. You'll get no warning that something's wrong until you start getting bad results during testing.
If you want to enforce behavior, you have to do it using instance members; using MustOverride (abstract) functions or an interface.
You can have static (Shared) methods like that, but you can't enforce the implementation of them.
Each static method is local to it's class, you can't overload it in a child class or make it abstract (MustInherit). You have to use an instance method (non-static) to get the object oriented aspects that you want.
Yes, that does smell!
Looks like you should be using an interface instead.
Here is a vb.net article: http://www.developer.com/lang/other/article.php/939411
Why wouldn't you simply declare it as:
Public MustOverride Function GetForms() As List(Of OrderForm)?
Static methods aren't inherited, so the expectation of overriding is not something we want to encourage. In other words, I think you might be barking up the wrong tree here.