When or when not to use/build a class?

[mrrrl]

Coming from VB6 and trying to figure out when to use or build a class. Using modules in VB6 was great, so do I convert or build a class where I once used a module?

TIA

 

[chiph]

A module in VB.NET is, behind the scenes, a class with all shared methods (there may be some minor differences).

I would suggest you start learning classes, so that you can extend your career options by picking up some object-oriented programming skills.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[mrrrl]

Well, I was not looking for career advice. I believe this forum was and still is, for asking questions on VB.net.

Let me rephrase the question. When do you make a class? There must be some guidance on when to use/make a class. I can't see making everything into a class. Every book I have read on this never talks about the decision to make a class. Like modules in VB6, I used them when I knew I was going to be reusing the same code again, either in this or some other later project. Is this also a good rationale to make a piece of code into a class?

TIA

 

[ca8msm]

I think Chip was referring to the "object-oriented programming skills" that would teach you when it was appropiate to use a class.

I generally use a class when it would:

1) Be used again (either in the same project or even for later use in a different project)
2) When items/variables/data/objects need to be set from any particular part of the page/form/module
3) When objects belong to another object

To expand a bit on the 3rd point I often use the Students and School scenario (where a student, who has many of his/her own attibutes, belongs to a school which also has it's own attributes). Chip has a good point when he said that classes help you pick up these OO skills and these skills generally make the decision for you as you "know" when it is appropiate to use a Class.

--------------------------------------------------------------------------------------------------------------------------------------------

Need help finding an answer?

Try the search facility (

http://www.tek-tips.com/search.cfm)

or read FAQ222-2244 on how to get better results.

 

[chrissie1]

mrrrl I don't think you need to tell chiph what this forum is all about. I think he understands and contributes a lot. And he has a point. People asking the kind of questions you do. Are bound to come back asking things because they don't know OOP (the basic how to open a form, or how to change elements on the other form).
Modules are a thing of the past.
When would you want to use classes? Always. It's not when you use classes, it's how. Inheritance, overlading, overriding, multiple inheritance... and all the other OOP vocabulairy is something you need to learn and the you will understand when and why to use them.

And now he's going to tell me he already knows OOP.

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[mrrrl]

ca8msm & chrissie1, thanks for your answers. They helped clear up some of the when and why, criticism aside. And no, I don’t fully understand OOP, hence the question, which the books don’t fully cover.

 

[chiph]

Well, I was not looking for career advice. I believe this forum was and still is, for asking questions on VB.net.

Oops, I got in a hurry and skipped a paragraph.

What I meant to include was that since modules in VB.NET are nothing more than classes with all-shared methods, there's no real advantage to using them. You'll gain more flexibility by migrating to using classes for your work. This will allow you to have multiple instances of objects, which will be needed in some development circumstances.

When reading books, they typically spend a lot of time on inheritance. In RealLife(tm), I've found that I seldom have to use that OOP technique, as embedding an instance of one class in another has been able to solve the vast majority of programming problems (this is called encapsulation). I also spend a fair amount of time creating interfaces (a special type of class) that set up an API for other developers to use.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[ThatRickGuy]

I'm with Chrissie for the most part.

We only have 1 module per app, ModMain, and it controls the start-up of the app and that's about it.

We have another class or two that could be a module, they are public classes with public shared functions.

In a few situations we use Structures instead of classes. Primarily for small things that only need a few pieces of data tracked. Things like parameters, where we may need an arrays for 3 different values, instead of using 3 arrays, we can use 1 array of the structure that holds 3 different values.

In pretty much every other situation, it's a class.

Lots of inheritance, lots of encapsulation, and lots of abstraction. We can litterally (and currently are!) pull any class from our business or data layer and use it in a .Net app, a Web app, or a COM app.

-Rick


VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[chrissie1]

I'm with Chrissie for the most part.

That made me very happy.

Christiaan Baes
Belgium

If you want to get an answer read this FAQ faq796-2540
There's no such thing as a winnable war - Sting

 

[ca8msm]

I'm with Chrissie for the most part.

That made me very confused!

--------------------------------------------------------------------------------------------------------------------------------------------

Need help finding an answer?

Try the search facility (

http://www.tek-tips.com/search.cfm)

or read FAQ222-2244 on how to get better results.