Hello,
Please tell me Waht are Classes. What is the benefit of using Classes and what can we do with calsses in VB.
Thanks
Farooq
Printable View
Hello,
Please tell me Waht are Classes. What is the benefit of using Classes and what can we do with calsses in VB.
Thanks
Farooq
That is an excellent question. I have been using classes for years and I'm not sure I could answer it properly.
To me a class is a spot to store code like functions.
The benefit to using classes is that the can be re-used, sometimes with other programs if needed.
That answer was weak...who can take what I said and add 50 points to it? LOL
Class modules are the part of VB that "permits" object-oriented programming (such as it is in Visual Basic (penagate just freaked out at the very notion that OOP and VB was said in the same sentence :D )).
You can write reusable code in class modules to create new objects. These new objects can include your own customized properties and methods.
Actually, forms are just class modules that can have controls.
A class is just like a control you put on a form (since a control really is just a class). A class has properties, events, and methods. You can create reusable code and you can organize this code in a manner that makes sense.
Classes also allow you to abstract the programming underneath it. This means that you don't need to know whats going on under the hood to use it. All you need to know is the names of the properties and what the results methods will give you and when events will be called. Most of these are evident through the name of the method/event/property name.
Can we create our own Menu Bar or Forms through Class with different languages ?
You can actually create your own menu bar or any control by making an activeX control. Make a new ActiveX control project OR add a user control to your project (under the same menu that you add modules, forms, etc). They are somewhat complicated, though.
Here is a link to a thread I started on this same subject: http://www.vbforums.com/showthread.php?t=361329
We should have this question in the FAQ + (what are modules), those 2 questions are asked quite a lot.
You have actually asked a very profound question. Let me offer a non-profound answer. Let's get into our way-back machine and go back to the 1980s. Let's say we have a fascination with gardening. We have a wonderful garden with lots of vegetables and fruits and we try all kinds of new techniques of gardening. It's a wonderful hobby.
So, it's say, 1982 and we are one of the first people on our block to get a computer, and we get a copy of gwbasic (a precursor to VB6). We start to write lots of different utility programs. We write one program to lay out where we are going to plant things, we write another utility to analyze our yield from our crop, etc....the thing is that we write lots of different little program having to do with our garden. Before you know it, we've written about a dozen different utilities, all figuring out something new about our garden.
The thing we notice is that we keep writing the same dang routines over and over again! Every time we write one of these utilities, we cut and paste out of the last program to compute something about our garden. We think to ourselves "This is really stupid, I know I've written this EXACT same routine at least 6 times and I keep having to copy and paste it out of the last program into the next program...or rewrite it from scratch."
Then the 1990s come along and you get a copy of QuickBasic. And you are in heaven because you can now create MODULES! All of a sudden you have this fabulous ability to take those routines that you've written over and over again that have to do with your garden and you can now put them in re-usable modules. So, next time you start to write yet another utility program (maybe this time it tracks flavor based on rainfall and degree-days) you say Eureka! I already have the routines I need in modules! I'll just call those modules. What a great idea! Your code is reusable.
So, you're happy as a clam and then it gets to be the late 20th-early 21st century and somebody says to you, "Hey, why don't you use VB6? You could write classes instead of modules!" So, you ask, what's the difference? Why would I put my gardening code in a class instead of a module?
Your friend says "Modules are defined by HOW things are done." The basic difference between a module which is reusable code and a class which is also reusable code is that MODULES focus more on HOW things are done while classes focus on WHAT a thing can do.
Let's go back and look at that last statement...modules are about HOW to do things, Classes are about WHAT a thing can do. If I want to use my houseshoe to kill a spider, I write a module. That's HOW I kill spiders, I use my houseshoe. It is all about HOW to do something, so it is a module.
On the other hand, let's say I want to describe WHAT my houseshoe can do! It can kill spiders, it can also keep my feet warm, and it can detrimentally odorize the room, among many other things! Now, I'm thinking in terms of classes.
We ask MODULES to do things for us...compute the standard deviation of the following set of numbers. We ask CLASSES WHAT they can do...hey, class, can you compute a standard deviation for these numbers I'm sending you? can you display the results on this control I'm sending you? can you bark like a dog?
Actually, people don't think in terms of classes, only programmers do. People think in terms of objects. An object is just an instance of a class....Take the class of dogs, your puppy is an instance of the class of dogs. You think a lot about your puppy (which is an OBJECT) but you probably don't think a whole lot about the class of dogs.
An OBJECT (your puppy not the class of dogs) is a set of capabilities. Let's repeat that because even programmers who think they write object oriented programs sometimes miss the point....AN OBJECT IS A SET OF CAPABILITIES! Your puppy is capable of sitting, fetching, barking, eating, playing, peeing on the floor. Again, it is all about WHAT it can do.
So, when you write a class, you have to think abstractly, because you don't have the luxury of thinking like most people do. Most people think in terms of objects (my dog, Spot). When you write a class, you define WHAT an object can do!
Ok, enough of that stuff, let's talk about a class you might write. Let's say you're going to write a card game. So, you define a class of deck-of-cards. What can a deck-of-cards do? It's made up of cards. What can cards do? Cards might make up a hand, which might also be a class, what can a hand do?
A deck-of-cards object might suffle itself, bury its hole card, allow itself to be cut by a player, display itself in shuffled order on a requested listbox ...and so on....
A hand object might ante, play a trump card, play a card in suit, fold, fart whenever it knows it's going to lose...
You see, you can make Forms try to do these things. And you can make them work, but you'll write a ton of code and then say to yourself, hmm.. I'd like to write another card game and use the same routines! Well, if you wrote all of your code in forms, you're going to mumble a big "Oops!" because you're going to have to painfully dissect your code to try to reuse it and...it won't be worth it.
You can also make Modules try to do these things. And you can make them work, but you'll write a ton of code an then say to yourself, "Hmm... I'd like to write another card game and use the same routines!" Well, if you wrote all of your code in modules, you'll go on to say "great, I can perform all of the same functions without rewriting them, but I still may have to interpret what the module gives me in the user interface (form)." And frankly, there will be cases where modules are every bit as effective in vb6 as classes.
But, just think about how you'll have to write the code to tell a module to shuffle your cards then bury the hole card and deal! Just how many lines of code will that be in the form?
Finally, you can make CLASSES do these things and then when you want to write another card game you can say...."Wow, I already have a deck that knows how to shuffle itself!"
And the form code in every game from now until kingdom come becomes some variation of:
Dim Deck as Deck-Of-Cards
Set Deck = PinochleDeck
Deck.Shuffle
Deck.BuryHoleCard
Deck.Deal
As a programmer, completely independent of how! I couldn't give a rat's behind how....All I know is that decks have the CAPABILITY of being shuffed, burying their hole card and dealing!
Hopefully this clears things up more than it confuses. Remember, as you read about Object Oriented Programming (OOP), VB6 is NOT OOP...it's just a kissing cousin to OOP. You have the capability (oh, maybe you're an object!) of creating Modules or Classes interchangably or not at all! The only reason for creating classes is to make future projects that use the same concepts much easier to code.
-MagicT
PS Those of you who are expert in OOP feel free to flame away! I know OOP brings out the Nerd in all of us.
Magic, that was genius. You explained in EXTREMELY well. I understand how and when to uses classes SO much better now. I really hope that reply is added to the FAQ. I personally am going to save it to a .DOC so I don't lose track of it.
Bravo!
PS - If I could rate that post 100 times I would!
Maybe a bit more concisely: a class forms the template for an object. All objects are instances of classes. Sometimes you see houses, particularly in new neighbourhoods, that all look the same. The blueprint for that type of house is the CLASS, and each house object is an instance of that class.
Now going a bit beyond the scope of VB6: If we expand on the dog example, you might have a generic Dog class. This seems fairly useless, because of course you can't have a Dog that isn't a particular breed. You would call the Dog your base class - it contains code that is common to all dogs. You can then derive a specific breed from your Dog class by inheritance - which drastically reduces the amount of code you have to write to create a breed of dog. Each breed class you can then instantiate, to create an actual dog.
P.S. - Hack - shock horror :D
That was truly well written - and all brought to a perfect point with that final example.Quote:
Originally Posted by MagicT
All about WHAT can be done.
I agree. :thumb:Quote:
Originally Posted by szlamany