A
Andy B.
Is there anywhere I can go to read the best guidelines (if any) on when to
use classes or modules?
use classes or modules?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
M
Michael C
Andy B. said:Is there anywhere I can go to read the best guidelines (if any) on when to
use classes or modules?
It's pretty simple, never use modules. If you need somewhere to put general
purpose functions then put them as shared functions in a class. The reason
you should not use modules is that their methods become global which is
something we should be trying to get away from in dot net. Shared functions
in a class are pretty much the same thing but you need to qualify them with
the class name.
Michael
A
Andy B.
"It's pretty simple, never use modules. If you need somewhere to put general
purpose functions then put them as shared functions in a class. The reason
you should not use modules is that their methods become global which is
something we should be trying to get away from in dot net. Shared functions
in a class are pretty much the same thing but you need to qualify them with
the class name."
So, for example of a shared method would be something like:
Public class NewsManager
Private DBContext as new EternityRecordsEntities()
public Shared Function GetNewsArticle(NewsID as Guid) as ObjectQuery(Of
NewsArticles)
return DBContext.NewsArticles.Where("ID = @NewsID", New
ObjectParameter("NewsID", NewsID))
End Function
End class
Then later in some code for databind as an example:
NewsDataList.DataSource = NewsManager.GetNewsArticle(NewsID)
NewsDataList.DataBind()
Is this right? And if for some reason I have instance methods mixed up in a
class with shared methods, then what do I do?
purpose functions then put them as shared functions in a class. The reason
you should not use modules is that their methods become global which is
something we should be trying to get away from in dot net. Shared functions
in a class are pretty much the same thing but you need to qualify them with
the class name."
So, for example of a shared method would be something like:
Public class NewsManager
Private DBContext as new EternityRecordsEntities()
public Shared Function GetNewsArticle(NewsID as Guid) as ObjectQuery(Of
NewsArticles)
return DBContext.NewsArticles.Where("ID = @NewsID", New
ObjectParameter("NewsID", NewsID))
End Function
End class
Then later in some code for databind as an example:
NewsDataList.DataSource = NewsManager.GetNewsArticle(NewsID)
NewsDataList.DataBind()
Is this right? And if for some reason I have instance methods mixed up in a
class with shared methods, then what do I do?
M
Martin H.
Hello Andy,
Just use it. You can use a shared method and an instanced method in the
same class.
'Here's the class
Public Class Class1
Public Shared Sub TestMe()
MsgBox("TestMe")
Dim c1 As New Class1
c1.TestMe2()
End Sub
Public Sub TestMe2()
MsgBox("TestMe2")
Class1.TestMe3()
End Sub
Private Shared Sub TestMe3()
MsgBox("TestMe3")
End Sub
End Class
'End of the class
'Here's how to call it
Private Sub Test1()
Class1.TestMe()
End Sub
Private Sub Test2()
Dim c As New Class1
c.TestMe2()
End Sub
'End of call
In Test1 you call a shared method by using the class name and the method
name. Result is 3 Messageboxes "TestMe", "TestMe2" and "TestMe3".
In Test2 you first create an instance of Class1 and then call TestMe2 by
using the instance followed by the method name. Result is 2 Messageboxes
"TestMe2" and "TestMe3".
As you can see...just use them.
Best wishes,
Martin
So, for example of a shared method would be something like:
Public class NewsManager
Private DBContext as new EternityRecordsEntities()
public Shared Function GetNewsArticle(NewsID as Guid) as ObjectQuery(Of
NewsArticles)
return DBContext.NewsArticles.Where("ID = @NewsID", New
ObjectParameter("NewsID", NewsID))
End Function
End class
Then later in some code for databind as an example:
NewsDataList.DataSource = NewsManager.GetNewsArticle(NewsID)
NewsDataList.DataBind()
Is this right? And if for some reason I have instance methods mixed up in a
class with shared methods, then what do I do?
Just use it. You can use a shared method and an instanced method in the
same class.
'Here's the class
Public Class Class1
Public Shared Sub TestMe()
MsgBox("TestMe")
Dim c1 As New Class1
c1.TestMe2()
End Sub
Public Sub TestMe2()
MsgBox("TestMe2")
Class1.TestMe3()
End Sub
Private Shared Sub TestMe3()
MsgBox("TestMe3")
End Sub
End Class
'End of the class
'Here's how to call it
Private Sub Test1()
Class1.TestMe()
End Sub
Private Sub Test2()
Dim c As New Class1
c.TestMe2()
End Sub
'End of call
In Test1 you call a shared method by using the class name and the method
name. Result is 3 Messageboxes "TestMe", "TestMe2" and "TestMe3".
In Test2 you first create an instance of Class1 and then call TestMe2 by
using the instance followed by the method name. Result is 2 Messageboxes
"TestMe2" and "TestMe3".
As you can see...just use them.
Best wishes,
Martin
C
Cor Ligthert[MVP]
Andy,
That depends, if you want to use a lot of things public, then it makes sense
to use a module.
In fact it is almost the same as a shared class, with the different that if
you use in the classic way the Dim at module level, it is by default public
for the complete sollution, while all public methods and properties are
visual without using the module name in the complete solution.
However as you like it in that way, there is nothing against it.
Because of the fact that I, beside the main, try to avoid everything which
is shared (static in C), I like the module in VB more then a Shared class
because it is direct a distinct in the solution.
Cor
That depends, if you want to use a lot of things public, then it makes sense
to use a module.
In fact it is almost the same as a shared class, with the different that if
you use in the classic way the Dim at module level, it is by default public
for the complete sollution, while all public methods and properties are
visual without using the module name in the complete solution.
However as you like it in that way, there is nothing against it.
Because of the fact that I, beside the main, try to avoid everything which
is shared (static in C), I like the module in VB more then a Shared class
because it is direct a distinct in the solution.
Cor
A
Andy B.
Thanks. This explains things a lot better. Now the question would be what
guidelines do you use when developing shared methods or instance methods?
guidelines do you use when developing shared methods or instance methods?
F
Family Tree Mike
Andy B. said:Thanks. This explains things a lot better. Now the question would be what
guidelines do you use when developing shared methods or instance methods?
Well, take a class called Car. It would make sense that this class would
have an instance method called Color, because that varies per instance. It
would make sense that it may have a shared method called Wheels, because all
cars have the same number of wheels (for sake of argument...). Basically it
boils down to me whether you expect a different value per instance or not.
M
Martin H.
Hello Mike, hello Andy,
Guidelines? Hmm... I normally use it in a way that if I need to access a
function/sub which does not require to access any variables, but makes
more sense in the class, then I make it shared.
Let's say you have a class MyMath. And in this Class you want to add
some functions to do calculations for you (e.g. SquareRoot, Percentage
etc.). For these functions, you could also use a module, but I like them
in classes as they are better organized (and don't interfere with other
functions with the same name (but in other classes).
Maybe most of the time it would be OK to use a module.
Well, maybe I can give you an example about classes/modules in VB6
(which I use at work):
In VB6 you do not have any shared methods in classes. You can only have
a class with instanced members. This results in things like
clsDatabase
modDatabase
clsDatabase would be a class holding everything that needs to be
instanced (as VB6 doesn't offer shared methods).
modDatabase would contain all the functions which you want to use
without an instance.
However, it can be pretty confusing if in one module you use a
sub/function which also exists in another module. Depending on in which
module you are either one or the other function is being called.
With shared methods you can put everything into one class (where it
belongs) and have your source code "tidier" than in the old VB6 apps,
which will help you to maintain your code with more ease.
Best wishes,
Martin
Well, take a class called Car. It would make sense that this class would
have an instance method called Color, because that varies per instance.
It would make sense that it may have a shared method called Wheels,
because all cars have the same number of wheels (for sake of
argument...). Basically it boils down to me whether you expect a
different value per instance or not.
Guidelines? Hmm... I normally use it in a way that if I need to access a
function/sub which does not require to access any variables, but makes
more sense in the class, then I make it shared.
Let's say you have a class MyMath. And in this Class you want to add
some functions to do calculations for you (e.g. SquareRoot, Percentage
etc.). For these functions, you could also use a module, but I like them
in classes as they are better organized (and don't interfere with other
functions with the same name (but in other classes).
Maybe most of the time it would be OK to use a module.
Well, maybe I can give you an example about classes/modules in VB6
(which I use at work):
In VB6 you do not have any shared methods in classes. You can only have
a class with instanced members. This results in things like
clsDatabase
modDatabase
clsDatabase would be a class holding everything that needs to be
instanced (as VB6 doesn't offer shared methods).
modDatabase would contain all the functions which you want to use
without an instance.
However, it can be pretty confusing if in one module you use a
sub/function which also exists in another module. Depending on in which
module you are either one or the other function is being called.
With shared methods you can put everything into one class (where it
belongs) and have your source code "tidier" than in the old VB6 apps,
which will help you to maintain your code with more ease.
Best wishes,
Martin
C
Cor Ligthert[MVP]
Martin,
In VB.Net you can use the Module name for a member in the same way as it
should for a Shared Class member.
The difference that it must for a Shared Class and for a Module you are free
to use it (However I use the module name forever in VB.Net).
Cor
In VB.Net you can use the Module name for a member in the same way as it
should for a Shared Class member.
The difference that it must for a Shared Class and for a Module you are free
to use it (However I use the module name forever in VB.Net).
Cor
J
James Hahn
It is not practical to suggest a guideline without knowing the environment
you are programming in.
Is this code going to be looked at by anyone other than yourself? Will it
be maintained by others in the future? Are the methods of general
usefulness or specific to the application? Are they likely to be re-used,
and if they are, is that likely to be as a unit, or simply with cut and
paste between applications? Are you testing with a formal test regime, or
simply ad-hoc practical tests, and is it useful to build in protection
against the impact of future changes in the way it's used?
As a rough rule, modules are quite acceptable where the methods are specific
to the application and all you are doing is bringing together some general
routines into one physical area of the source code. Classes are justified
where there is some benefit to be had from the encapsulation and scoping,
such as re-use in other applications by other programmers who have no need
to get involved in the detail of the code..
you are programming in.
Is this code going to be looked at by anyone other than yourself? Will it
be maintained by others in the future? Are the methods of general
usefulness or specific to the application? Are they likely to be re-used,
and if they are, is that likely to be as a unit, or simply with cut and
paste between applications? Are you testing with a formal test regime, or
simply ad-hoc practical tests, and is it useful to build in protection
against the impact of future changes in the way it's used?
As a rough rule, modules are quite acceptable where the methods are specific
to the application and all you are doing is bringing together some general
routines into one physical area of the source code. Classes are justified
where there is some benefit to be had from the encapsulation and scoping,
such as re-use in other applications by other programmers who have no need
to get involved in the detail of the code..
A
Andy B.
Michael D. Ober said:MichaelC,
Given your apparent attitude towards VB.NET in the thread you started on
Linq killing VB, I think your advice to never use a module is way off
track.
Andy,
Use modules for globally useful functions and subs that don't require
saved state between calls. Yes, you can use a Static variable inside the
function, but if you are saving state between calls, chances are you're
really looking at an object. In C#, you have Namespaces and Classes as
the primary scoping control. In VB, you have Namespaces, Modules, and
Classes. A module is a hybrid between a namespace and a static class with
all it's methods shared by default. You can reference functions in
modules using either just the function name or "module.function" syntax.
The latter is useful in that other dotNET languages can call your function
(in a dll) using the module.function syntax. If you have functions in
your module that aren't for public consumption, make the Private, just
like you would for a class.
Hi.
The methods being used fit the following guidelines.
1. They wont be seen or maintained by anyone else but me.
2. They are for the applications use only.
3. They all will do some sort of database operation. The current set of
methods I'm working on now relate to the news feature of the application.
Other ones will deal with Events, mailing lists, settings and so on.
Would shared methods be better or modules?
H
Harry Strybos
I disagree with your assertion to "never" use modules. There may well be aMichael C said:It's pretty simple, never use modules. If you need somewhere to put
general purpose functions then put them as shared functions in a class.
The reason you should not use modules is that their methods become global
which is something we should be trying to get away from in dot net. Shared
functions in a class are pretty much the same thing but you need to
qualify them with the class name.
Michael
case where you wish to put in place some class library specific
functionality that you do not want exposed publically.
Harry
M
Michael C
Andy B. said:Hi.
The methods being used fit the following guidelines.
1. They wont be seen or maintained by anyone else but me.
2. They are for the applications use only.
3. They all will do some sort of database operation. The current set of
methods I'm working on now relate to the news feature of the application.
Other ones will deal with Events, mailing lists, settings and so on.
Would shared methods be better or modules?
Shared methods. In some *very* rare cases it could be argued that you should
use a module but for something like accessing the database these should be
in a shared function in a class.
Michael
C
Cor Ligthert[MVP]
Shared methods. In some *very* rare cases it could be argued that you
should
use a module but for something like accessing the database these should be
in a shared function in a class.
Why *should* whatever (beside the main) be in a shared function of a class.
By instance a fill is simple a sub not a function.
Because there is not any need to do it shared, as it can be instanced as
well.
It is OOP in managed code you know.
An object exist as long as it is used automaticly which is managed by the
managed code.
(I get the idea that you are still programming in VB6 style)
Cor
R
Rory Becker
Hello Andy B.,
Apologies if it's already been mentioned elsewhere in this thread. ( I can't
find a reference but I only had a cursory look)
It is actually a pre-requisite that Extension Methods be contained in Modules,
and whilst some people object to their use, it remains a fact that you simply
must use Modules if you want to use them.
Is there anywhere I can go to read the best guidelines (if any) on
when to use classes or modules?
Apologies if it's already been mentioned elsewhere in this thread. ( I can't
find a reference but I only had a cursory look)
It is actually a pre-requisite that Extension Methods be contained in Modules,
and whilst some people object to their use, it remains a fact that you simply
must use Modules if you want to use them.
M
Michael C
Cor Ligthert said:Why *should* whatever (beside the main) be in a shared function of a
class.
Even main need not be in a module (vb does support that, surely?)
By instance a fill is simple a sub not a function.
Because there is not any need to do it shared, as it can be instanced as
well.
It is OOP in managed code you know.
I'm really not sure what you're trying to say here.
An object exist as long as it is used automaticly which is managed by the
managed code.
(I get the idea that you are still programming in VB6 style)
That is an odd thing to say seeing that in VB6 you had to use modules and
we've gone well away from them in dot net. AFAIK the framework itself does
not use modules anywhere.
The real problem with modules is that methods become completely global
everywhere throughout the app. This is not a good way to program and just
one of the many reasons I prefer C# over VB, many of the bad features are
not there. This forces programmers to at least program a little better. Some
don't even realise they should not be using On Error, having option strict
off, using modules etc.
Michael
M
Michael C
Harry Strybos said:I disagree with your assertion to "never" use modules. There may well be a
case where you wish to put in place some class library specific
functionality that you do not want exposed publically.
Why not make it private or internal in a class then?
M
Michael C
Rory Becker said:Apologies if it's already been mentioned elsewhere in this thread. ( I
can't find a reference but I only had a cursory look)
It is actually a pre-requisite that Extension Methods be contained in
Modules, and whilst some people object to their use, it remains a fact
that you simply must use Modules if you want to use them.
I didn't realise that, the more I know about VB the less I like.
Michael
C
Cor Ligthert[MVP]
Michael,
The more you write, the more I (and probably others) see the advantages of
VB
Cor
I am so glad that you are active in this newsgroup.I didn't realise that, the more I know about VB the less I like.
The more you write, the more I (and probably others) see the advantages of
VB
Cor
M
Michael C
Cor Ligthert said:Michael,
I am so glad that you are active in this newsgroup.
The more you write, the more I (and probably others) see the advantages of
VB
Really? How is being forced to use a VB6 feature an advantage?
Michael