Use Class or Module for utility library

[Academia]

I have a library that contains classes.

A typical example is shown below.

I wonder if Module instead of Class would make more sense.

Are there pros and cons for using one or the other?

Thanks





Public Class WinDefH



Public Const MAX_PATH As Integer = 260



Public Structure SIZE

Public cx As Integer

Public cy As Integer

End Structure



Public Declare Auto Function Appnu Lib "user32.dll" _

(ByVal hMenu As IntPtr, ByVal flagsw ) As Integer





Public Shared Sub DisplayLastError()

...snip

end sub



Public Shared Function NoB(ByVal f As String) As String

...snip

End Function



end class

 

[Bill McCarthy]

Hi Academia,

I personally prefer a class, but you should add a Private sub New to it so
as it cannot be instantiated from outside as an instance if all members are
to be Shared. A Module addresses that issue, as all members in a Module are
Shared. The issue I have with Module is that is implicitly Imported into the
project so that all methods inside can be called without any qualification,
e.g: DisplayLastError, versus WinDefH.DisplayLastError. With a class, if
you want that effect you can explicitly Import RootNamespace.WinDefH
So I think classes provide greater flexibility.

 

[AMercer]

I personally prefer a class, but you should add a Private sub New to it so

as it cannot be instantiated from outside as an instance if all members are
to be Shared. A Module addresses that issue, as all members in a Module are
Shared. The issue I have with Module is that is implicitly Imported into the
project so that all methods inside can be called without any qualification,
e.g: DisplayLastError, versus WinDefH.DisplayLastError. With a class, if
you want that effect you can explicitly Import RootNamespace.WinDefH
So I think classes provide greater flexibility.

I agree with all of the above. Additionally, Fxcop suggests marking as
NotInheritable a class whose members are all Shared.

http://msdn2.microsoft.com/en-us/library/ms182168(vs.80).aspx

 

[Academia]

Hi Academia,

I personally prefer a class, but you should add a Private sub New to it so
as it cannot be instantiated from outside as an instance if all members
are to be Shared.

I don't know why one would but, what is there a reason for not allowing
this?

A Module addresses that issue, as all members in a Module are Shared. The
issue I have with Module is that is implicitly Imported into the project so
that all methods inside can be called without any qualification, e.g:
DisplayLastError, versus WinDefH.DisplayLastError.

Thanks, I don't like that either.

 

[Academia]

I agree with all of the above. Additionally, Fxcop suggests marking as
NotInheritable a class whose members are all Shared.

What would be wrong with someone extening the library that way??

Thanks, I'll look at the site now.

 

[Cor Ligthert[MVP]]

Academia,

I don't see any reason why you would not use in this case a module.

In my idea is a class is here only syntytical sugar.

Cor

 

[Academia]

From McCarthy:

The issue I have with Module is that is implicitly Imported into the
project so that all methods inside can be called without any qualification,
e.g: DisplayLastError, versus WinDefH.DisplayLastError. With a class, if
you want that effect you can explicitly Import RootNamespace.WinDefH

Probably not a big deal but I like the idea of having to identify where it
is declared (I have quite a few classes in my library and the names are
meaningful).

I think, if I could get the compiler to check on me, I might like putting Me
in front of all the "local procedures" . Not sure about this - it might be
cumbersome.

It just occurred to me that since an extension method must reside in a
Module, a library containing them must be Module not Class. Consistency is
nice too. Oh well!

It was suggested that I insert Private sub new() in the classes so they
can't be inherited. Can you guess what problem they saw with them being
inherited.


Thanks for the input

 

[Bill McCarthy]

I don't know why one would but, what is there a reason for not allowing
this?

It's a matter of code clarity (and to a lesser extent performance) If only
shared members exist, you don't want people accidentally writing Call (new
Foo).Bar etc. The IDE experience is such that it isn't always obvious which
methods are Shared until after you have selected them. So if you warn
people immediately when they try to create an instance, it's better for
everyone.

 

[Bill McCarthy]

I agree with all of the above. Additionally, Fxcop suggests marking as
NotInheritable a class whose members are all Shared.

http://msdn2.microsoft.com/en-us/library/ms182168(vs.80).aspx

Yep. It would be nice if we had, as per the comments on that page, a Shared
modifier on classes similar to the static modifier on classes in C#
(without the Module namespace imports pollution)

 

[Cor Ligthert[MVP]]

It's a matter of code clarity (and to a lesser extent performance)

I wished that there was not that strong loby to go back to the future and
make everything good or bad the same as C#.

Why should a shared class be mixed up, it has not any documentative value
more than to keep a shared class (module) shared and an real OOP class non
Shared.

However that is just my idea, I never will use those confusing mixed up
classes (as I try to avoid modules and everything that is shared)

Cor

 

[Academia]

thanks

It's a matter of code clarity (and to a lesser extent performance) If
only shared members exist, you don't want people accidentally writing
Call (new Foo).Bar etc. The IDE experience is such that it isn't always
obvious which methods are Shared until after you have selected them. So
if you warn people immediately when they try to create an instance, it's
better for everyone.