Sorry, longer than intended:

Modules vs Classes
-------------------
Modules are Classes. The (most important) differences are:
- All members in a Module are implicitly declared Shared.
- The Module is imported at project level.

Consequently, these two versions are equal:

Version M:

   Module M
       Sub Test
       End Sub
   End Module

Version C:

   Class C
       Shared Sub Test
       End Sub
   End Class

+ "Imports C" at project level

In both cases, you can simply write "Test" anywhere in the project in order
to call Sub Test.

Shared vs instance methods
--------------------------
A: Fields

If you create an object (AKA an instance of a Class), it occupies a block of
memory. It consists of all the instance fields of the Class. More fields,
more memory. Five instances, five times the same sized block of memory.

All Shared fields in the class are there once. Always. From the start til
the end of the process. No matter how many instances exist.

-> memory consumption = 1 x shared fields + n x instance fields

B: Methods

All methods in the class are there only once. This is true for intance
methods and for Shared methods. It wouldn't make sense to have them twice or
more often because the code is always the same. It doesn't matter how many
instances exist.

The difference between shared and instance methods is:
Instance methods can access instance fields. Consequently they need a
reference to an object.
Shared methods can not access instance fields because they don't have a
reference to an object.

Internally, the difference is:
An instance method has an additional, invisible parameter called "Me". Me
points to the object for which the instance method is to be executed for. By
having this parameter, it is obvious that the method can access all the
fields inside the object referenced by "Me". In an instance method, writing
"Me." is optional, therefore writing "ButtonHasBeenClicked" is equal to
"Me.ButtonHasBeenClicked".

Because a shared method does not have this invisible "Me" parameter, it can
not refer to a certain object and therefore it can not access instance
fields. There can be 0, 1 or 1 million objects, but the shared method
wouldn't know which one to access.

Have a look at this class:

   Class C
      Public Value As Integer

      Shared Sub Test1(ByVal TheObject As C)
         TheObject.Value = 17
      End Sub
      Sub Test2()
         Me.Value = 17
      End Sub

   End Class

Usage:
     Dim o As New C
     C.Test1(o)
     o.Test2()

Both methods do the same. It's just the object-oriented language syntax that
makes us see the second call as calling a "method of the object o".

Personally I don't use modules at all, but that's personal taste. I only use
shared methods in classes. The reason is that, with classes, the members are
not auto-imported. As a consequence, I have to specify the class name to
call the method (Classname.Method). I like it more because I will always be
aware of the namespace/class structure. With modules, all member names of
all modules are put into a single big (unstructured) pot. Though, you can
use modules if you prefer them.

If you still have implementation questions, please ask.

Armin

Bob, reading both replys I'm begining to get a better understanding of
what your trying to accomplish, and let me say your desire to separate
common code, from implementation specific code is the correct one.
But, with all due respect, you're approching it the wrong way....

First, I would separate ALL logic involved in mining the websites from
the UI.  That logic is more appropriately placed in a Class.  In fact,
I would most likely move it to it's own class library, so that the
logic is able to be used from multiple different applications/
interfaces.

Second, as for separating out the logic... There are several ways to
approach this, but I think the simplest at this point would to be
through inheritance.  In that case, I would probably create somthing
looked like (air code follows!):

public mustinherit class WebMinerBase

  public overridable sub
DoCoolStuffButAllowSubClassesToAlterBehavior()
     ' common code
  end sub

  public mustoveride sub
DoCoolStuffAndInsistSubClassesProvideAnImplementation()

  ' factory method to create subclass to handle the address
  public shared function CreateWebMiner (byval address as string) as
WebMinerBase
     if address = google then
       retrun new GoogleMiner()
     else if address = ebay then
       return new EbayMiner()
     endif
  end function
end class

public class GoogleMiner
  inherits WebMinerBase

  public override sub
DoCoolStuffAndInsistSubClassesProvideAnImplementation()
     ' google specific implementation
  end sub
end class

public class EbayMiner
  inherits WebMinerBase

  public override sub
DoCoolStuffAndInsistSubClassesProvideAnImplementation()
     ' Ebay specific implementation
  end sub
end class

' client code in form

private sub button_click (byval sender as object, byval e as
eventargs) handles button.click
 dim webminer as WebMinerBase = WebMinerBase.CreateWebMiner(addres)
 webminer.DoCoolStuffButAllowSubClassesToAlterBehavior()
 webminer.DoCoolStuffAndInsistSubClassesProvideAnImplementation()
end sub

Anyway, the point is to abstract common logic into tthe base class,
and the implementation specific into subclasses.  Then you can use a
generic interface, and through polymorphism get specific behavior...

Anyway, just a thought.

--
Tom Shelton