Modules versus Class Method

I was talking with another vb programmer who suggested something to me.

At the moment I use a common module to set up global variables ( public rather than dim/private)
This is mainly for flag switching, controls such as recordsets, connections, passing on file position info, etc.

It was suggested that using class methods would be more efficient?
Especially in the process of releasing resources.

My guess is that class methods are part of object oriented methodology, and it presents a different way of coding logic?

Has anyone gone down the object oriented approach, or know a bit about class methods?

I am curious to learn some more.
Maybe object oriented programming is more powerful and produces better results? ?

Two bells ringing (two friend of mine said) :
one (oop) says:
Differece between oop and structured is like what you could
know about well structured and "spaghetti code"

The other (structured) says:
Objects does not even exist, they are only a way to wrap the
structured code and add complexity till you get totally confused

What do I thing?
I believe Oop is wonderful as long as I do not get confused...;)
It is like difference in using FyleSytemObject or do the same using
commands like Dir$ or name,....

Objects may be very useful as long as you can manage them.
Start having a class to hold your global variables as long as they
are state infos, making them properties of the class.

...Remember object will not survive the scope of the variable that
holds an instance of it....

Take a look at collections as holder of classes: you can have a class (say Folders) which holds a collection of another type of
classs (say Folder). Start using class builder to have a look
(=adding a class to a project and choosing the wizard as type of
class)

even if Bas Modules are different things from Class modules,
you can have properties in Bas modules, too....

Thanks, but I couldn't follow your comments Cimperiali, I guess that indicates my lack of understanding on the subject.

I have started reading a book on Analysis and Design for object Oriented applications, I believe it will unlock the mystery, fingers crossed.

Visual Basic isn't an object oriented language.. but I know what you mean because I was programming VB6 in a OOP way (somehow)

I used one bas module for common functions I always need to call like AddSeperators.
And I used VB Classes to manage my code.

For that I just created a Class (let's say it is an Audit class) named Auditing

In the main module I defined

Global clsAudit as new Auditing

And inside the Auditing Class I just defined some private functions and public ones.

For example I had 3 functions
public Sub Init_Audit()
'open the logfile
end Sub

public sub Log(Text as string)
'write the text to the file
end sub

public sub Close()
'close the audit file
end sub

I also declared the fileID as a private byte variable inside the class.
so I opened the file once and saved the fileID ( i got it with FreeFile) to the private variable so I don't have to bother about other classes or source code using that variable.

same was for my database class.

ADO.Connections etc were defined public and I was accessing only public functions that where accessing these things..

and for the recordsets I used a byref recordset to output the data

that's a pretty neat way to get something of a structure into a project.. but what it is exactly good for will always remain a mystery for me.. Maybe it split's into more threads (my project was never multi threaded but when I stated using classes there were 6 threads instead of one)

greetings UNI

Well, usually I use to convert a module into a class whenever I have to reuse the codes/methods/subs/funcs but of different private data/properties in the program. Because a module is just like a static class with one private storage, although you can also create multiple storage in the module using some sort of arraying the set of variables just to behave like a dynamic class, but this is very tedious and eneffecient in the program..

In your case, I think you have only one set of variables (private data storage), no more no less, needed by your program throughout the process. So converting the standard module (bas) into a class module is not that worthy.

Having a Bas module and converting it to Cls one is not that
easy, unless you made the Bas thinking to objects....

An object is a piece of software "self contained" (=incapsulate
rule), that does a particular job (usally methods) and/or holds
infos (usually properties) and /or can notifies (raise events).

For example, supppose you have a table which holds Orders of
our customers and table of Customer.
You might have one object (Order) to deal with orders.
This object can have properties like "KeyId", "Quantity","Value",
"CustomerId" property (but this could be next object property -
the one holding a collection of Order) , "State" (=acccepted,
sealed, rejected,...),... and some methods like "MoveToState",
....
You then could have an object called "Orders", which contains a
collection of "Order". It could have a method that, given a
CustomerId could retrieve all orders by that Customer, or given a
ProductId could give back all orders for that product (but you
could have choosen to have several of this one, one per
customer, and to add them to another object like GlobalOrdres...I
can hear the scream of the structured one, here...) and have
properties like TotalNumberOfOrders(optional StateOfOrder=all)
You usually deal with any Order stepping by "Orders"

ie: Orders(Key).Order.MoveToState(ordStateAccepted)

Same for customer: an object that has properties like
"CustomerId","CustomerFirstName", .... and another Object that
holds a collection of Customer named "Customers" (=generally,
we use singular for basic object and plural for collections of the
basic object, but this is not really a rule, as later here you will
see). This "Customers" object can tell you how many customer
objects you have (it is really easy: collection.count, if you
populated, or a query Select count(*) on Db, if you did not...)
and have methods like "AddNew", "Remove",....

That is: the objects can simplify your job if you develope them
in a correct way. Matter is: Only having clear in mind what each
piece of software should do your software should do you can
develope them well.

In your case, if dealing with flags of app, you sgoudl think about
purpouses of the flags and if there could be an object taht could
holds them (some or all)....Ie: an AppObj is really general, and
could be misguiding. While a "Document" object is a bit more
specific...(and here beweare: you could have also a Paragraph
object, and even a SingleWord object , but it might be too much
to have also a singleChar object, unless you really need to work
with a parser.....The SingleWord could have properties
like "Position in Row", while Paragraph (holding a collection of
SingleWord) could tepll you how many rows, and how many words
(could it be good to have a SingleRow class? Then this last could
hold a collection of word, while Paragraph holds the SingleRow
collection....It depends on job you expect to do....Btw, did you
see a different naming convention, here?)