Honestly I see no point to it..I can do the same thing with a UDT and a module without a whole bunch of let + sets..Can anyone give me an advantage here?
Printable View
Honestly I see no point to it..I can do the same thing with a UDT and a module without a whole bunch of let + sets..Can anyone give me an advantage here?
- Reusability.
- Variables and methods will work from inside a particular object.
i.e.
VB Code:
Dim MyObject As clsMyClass Set MyObject = New clsMyClass MyObject.Prepare(SomeParameterIfYouWant) MyObject.Process() MyObject.PrintOut() Set MyObject = Nothing
- It is true that the same can be achieved with UDTs + modules, but when there is many code involved, it's much easier using classes.
When using many objects It's common to use Collections to store them.
Modules are faster than classes, but when you have many many things to do in a program, it's better to spend some days preparing classes before you start with the entertaining part.
Classes help describe real world objects.
Class is the blueprint for objects...
Creating more instances of one object!
To my mind, this is the purpose of a class module. Project specific code can, and should, be dealt with in a .bas module, or a UDT or some other project specific form. Code in a class module is code that can be used across multiple projects, and can be use across multiple projects by mutliple programmers.Quote:
Originally Posted by jcis
Okay, so really I have no uses for it then. Thankyou guys :wave:
The best reason to use classes that I can think of is to have different distinct types that use a common interface. For example, if you have to deal with a group of students, you could create a student interface that is implemented by different types of students (ie underclass, graduate, audit). All of these might share a common .AddClass method, but say audit students get charged half tuition, underclass have to check for pre-requisites, etc. Given a collection of student objects, each one would be able to be processed with the same generic code.
Another reason is to enforce data integrity. A class should only allow access to it's data through it's interface, and this lets you control referational integrity. Let's say you have an SafeArray class with an element size property, a number of elements property, and a datasize property. Changes to any of these properties will effect the others. It also lets you easily validate data, as you can force a validation any time a property changes. If you combine these two ideas, it makes it a lot easier to check data who's acceptable values vary with other variables.
Finally, classes are the only way to implement event driven programs.
If you move to the dark side (.Net) you will see that classes become much much more useable, Vb 6 was week when it came to clases they were pretty slow if I remmber correctly.
Classes are awsome, for orginising code etc!
Where did you get that idea from? :rolleyes:Quote:
Originally Posted by Comintern
@Pino,Quote:
Originally Posted by Pino
Please do not start another religious war - there is one already in VB.Net forum. Your current answer shows your weekness. Sorry.
I wonder how?Quote:
Originally Posted by nkad
@Rhino,Quote:
Originally Posted by RhinoBull
Is it not true that classes in vb6 are slow?
Got it from the fact that you can only raise an event from an object module.Quote:
Originally Posted by RhinoBull
They are even slower in .Net so please I insist that if you want to continue arguments then do not mention VB.Net anymore.
You've got to be kidding me - VB since its first releases is an EVENT driven language and that's how it was designed - objects respond to events that could be trapped. What you reffer is simply a custom events that could be added to some objects.Quote:
Originally Posted by Comintern
Well seriously i'm interested to know since the subject is clasess, I didnt relise they were slower in .Net? Is there any test on this I could read?
I know classes have become a lot more 'used' in .Net
Be interesting to see non-theless
RhinoBull, you cannot compare classes in VB6 to classes in .net. VB6 does not have real classes, not by ANY stretch of the imagination. They don't even remotely count as objects either.Quote:
Originally Posted by RhinoBull
Admittedly, .NET wouldn't win the 100 metres OOP sprint (not with C++ hogging the track), but VB6 wouldn't even get into the qualifying rounds. VB6 is so archaic its not even funny any more. So please don't pretend that VB6 is somehow better simply because you have a fondness for VB6. Pino has much VB6 experience and is learning .net at a geometric rate, he knows more about it than you do so just shut up.
No, actually I'm not kidding you. Do you actually think there is some real distinction between the events that VB has built into it's objects and custom events programmed into custom objects? A form is just a class with some baggage attached to it. If you have some sample code that is event driven with only modules in it, I'd be delighted to see it.Quote:
Originally Posted by RhinoBull
Religious wars tend to get started by self-righteous idiots, and I think your general attitude on this thread would show your weakness.Quote:
Originally Posted by RhinoBull
Sorry Pino but I am not upto benchmarking at the moment.
...or indeed justifying your argument.Quote:
Originally Posted by RhinoBull
@Comintern:
I'd be carefull in using strong expressions if I was you.
Dude, are you drunk?Quote:
Originally Posted by RhinoBull
This is not a chit-chat wossy and this not amusing. I would expect apologies from you.Quote:
Originally Posted by wossname
We have a VB6 "general maintenance program" that allows us to build entry forms at run time from tables in SQL. We did all this work with ARRAY's and UDT's and function/subs in a MODULE.
It was a huge mistake - that we continue to pay for.
First - enhancing the program is a nightmare - adding columns to an array to store new information about behaviour.
Second - it's an MDI app - so each child form has an entry in the array's...
It would have been so much easier to use a CLASS - and creating a new occurrance of the object for each child form.
The SET/GET part makes so much sense now - you can validate and put all kinds of business logic in the property code.
We are now doing a "report writer user interface" in VB.Net and fully embracing the class concept. Writing up a property to get and set a value might take a bit of time - but it's a really, really good way to organize a large program that will have a future of enhancing.
I've always supported black-box concepts - creating functions to hide logic from the main code. A class is just a really clean way to achieve that goal and a whole lot more.
Okay let me put my project, can you tell me if I would need a class for it?
I have a UDT Named person:
[Example]
VB Code:
Public Type Person FName as string LName as string Address as string Town as string End Type
Okay, and now I have another type:
VB Code:
Public Type Location Hemisphere as string Country as string X as long Y as long End Type
VB Code:
Dim tPerson as Person Dim tLocation as Location
So in my form, I send some of the info in a strange order to my server
VB Code:
With winsock1 .senddata tPerson.FName & tPserson.LName & Chr(0) & tPerson.Address & chr(0) & tLocation.Country End with
I fill in the value with previous winsock requests/sends..Is there reason to use a class? I have some other UDT's with permanent values also that I send in some winsocks also.
Is this reason enough to use a class or should I stick with the UDT + other code?
UDT can only hold variables a class can hold routines.
If people was a class you could do somthing like
Dim People as New ClassPeople
msgbox people.find("John")
You dont need a class for anything you should just use it when you need it ;)
Pino
If you want to enforce any rules on the data (such as Hemisphere must be "North" or "South", and LName must be at least 2 characters) then classes are a good way to do it.
If you are only storing data (and dont care what values are stored) then use of a class is a matter of opinion - mine is that it would be OTT, and that a UDT is better.
Believe it or not, Hack, I have regular .bas modules that are typically reuseable. It all depends on what you are coding really, in my case, games. ;)Quote:
Originally Posted by Hack
Based on many performance tests that I have done, yes they are slow. Here's the order from fastest to slowest that code is executed:Quote:
Originally Posted by Pino
.bas modules
.frm form modules
.cls class modules
That's why I typically use regular modules in my projects cause the code is executed so fast. And some of them are even reusable.