Use Class or Module for utility library

  • Thread starter Thread starter Academia
  • Start date Start date
A

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
 
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.
 
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.
Click to expand...

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
 
Bill McCarthy said:
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.
Click to expand...


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.
Click to expand...

Thanks, I don't like that either.
 
AMercer said:
I agree with all of the above. Additionally, Fxcop suggests marking as
NotInheritable a class whose members are all Shared.
Click to expand...

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

Thanks, I'll look at the site now.
 
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
 
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
 
Academia said:
I don't know why one would but, what is there a reason for not allowing
this?
Click to expand...


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.
 
It's a matter of code clarity (and to a lesser extent performance)
Click to expand...
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
 
thanks

Bill McCarthy said:
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.
Click to expand...
 
Back
Top