Hi Jonathan,
More than likely you will cringe when you see this reply from me, but it
isn't bad; in context, so there is no need. Anyway...
One should use a module when there is no "object" associated with the
functions you are writing.
Exactly, everything has a purpose and there is no right or wrong way
about programming. Some techniques prove much better for certain uses than
OOP does. It all depends on what you are trying to achieve.
Too often people become enamored with "Object Orientated" and forget that
objects are not everything, they are just another tool. And like all
tools,
there are times when they should not be used.
ACK.
Off the top of my head, VB's FileSystemObject. You have to create an
instance of the FSO before using it, even though you will never need more
than one FSO. In fact, you could create a hundred of them and they would
all
be exactly the same.
I'm a little OT, but I started using JAVA before I used the beta of
VB.NET and I am rather surprised as to how close the JAVA "run-time" is to
the .NET Framework, the way the class hierarchy is laid out is almost
identical in certain circumstances. I'm sure Microsoft had a lot to say but
it just goes to show how much the CLR is needed! I crated my own file
objects for VB6 that are almost identical to VB.NET, it's weird how an
inferior "desktop" language has come up with far better ideas!
I cringe whenever I someone mentions a "singleton" pattern. In all most
all
cases, your so-called singleton is really just a global variable that
people
pretend is a class.
But even they have their uses. For example, if you are sharing objects
between instances then sometimes a singleton is essential! For example, if
I create a singleton object for my application it would make it much easier
for me to maintain only 1 running instance. This appears to be something
that is really overlooked by people that utilize command line arguments, a
singleton is essential! What's the point in having an MDI application with
multiple instances?
Nick.