Printable View
Could someone provide an overview of Classes for me please? I could use a few examples to copy and run to see how this works.
I am reading about this topic now and hard to grasp what the importance, benefit it is to writing own object or class.
I may have stated this unclearly.... so please forgive my ignorance on the subject.
Thanks,
YLP
I suggest you ignore it. There is very little that you can do with classes that can't be done another way, and it is a difficult concept to convince people about. When you have more VBA experience, you will either see classes as indispensabel, or no point. But for the moment, I think it will confuse rather than enlighten.
I've used them as an exercise and can see their value, but I've yet to come across a real life situation which requires me to use them.
Thanks guys,
Ok-- I will pass on this topic now. There are many others on the list. This has come up in different articles/books I am reading and thought there was an omen...
Take a gander at this
http://www.windowsdevcenter.com/pub/...8/xcel_mm.html
If it looks interesting, as a learning experience, download and install the toolkit. Then when you attach to a Web Service, Excel will write a 'class' for you. After a few if you decide that a class is like a common set of functions with global/static variables you won't be far off. Stan
Google these keywords:
? OBJECT
? REUSE
? DATA HIDING
? CLASS
? ENCAPSULATION
? ABSTRACTION
? INHERITANCE
? POLYMORPHISM
Unfortunately, the last two do not really apply to VBA. Nevertheless, the advantages offered by the others are, in my opinion, very important. I use classes whenever possible in my development and the results have been worth the effort undertaken to understanding object oriented concepts. One of the main advantages of using classes in an object based, though actually a procedural language, such as VBA is realized when utilizing events. In fact, you must use a class construct to use events in VBA. A very good example of the benefits of classes is seen in the very objects that make up your default VBProject such as the worksheet class. Your worksheet is an "object" that is defined by it properties, methods, and events. There are things that a worksheet object...
...can do
http://home.fuse.net/tstom/041907_1.jpg
...can know or contain or have access to
http://home.fuse.net/tstom/041907_3.jpg
...can respond to
http://home.fuse.net/tstom/041907_2.jpg
In a real OO language such as any of the .net compliant languages, you could actually inherit from and extend this class. (if inheritable).
Back to the worksheet object. Once created, debugged, and tested, you do not have to recreate this object. You just use it. Increasingly, over time, my job is made easier by importing previously constructed objects from my own repository or elswhere and reusing them with a minimal amount of code in current projects. I am using code that is already created, debugged, and tested.
There are other benefits as well.
As I tried to say yesterday during a bout of line madness, I use classes extensively in my code. But I have benn trying to convince my brother of their worth for 5 years now, and he still isn't convinced.Quote:
Originally Posted by mdmackillop
I think you can argue, and this argument is made to me often, that if you create well structured, well modularised, well designed code, then all of the above advantages attributed to classes are obtainable without them. Without inheritance and polymorphism, VBA classes have a big hole, and are difficult to provide a convincing argument for. Classes in themselves do not deliver those benefits, a porly designed, poorly written class is as bad as poorly written, poorly designed procedures.Quote:
Originally Posted by tstom
Don't get me wrong, I am in the pro-lobby, strongly in there, but I am well aware of how difficult a concept that it is to sell. Things are not helped by the useless examples we generally see (the employee class!), that demonstrate the structure of classes, but not the rationale, or the usefulness. I think it is one of those things that, until you get it, you just don't get it.
Bob,
I use classes a bit but in what specific situations do you personally use classes? I only use them with controls on forms but I don't really know enough about the subject. If I have a lot of controls with the same or similar behaviour and I need to 'mark' some of them as essential to a sheet calculation or... whatever, I use a class. Other than that I don't have the time to experiment (contract work).
Glen,
I think you are using classes to control application events, or create pseudo arrays (if I understand you correctly), which is a useful side-effect use of classes (as I would term it).
My use of classes is far more 'standard' in that I look to create class objects, and define all of the attributes of that object as class properties, and all of the actions of that object as methods.
For instance, I am writing an application at the moment that has two discrete sets of data, a baseline set, and a customer specific set, so I create a baseline class and a customer data class. Within these I load/initialise/save all of the data, and then expose it to the application via properties and methods.
The value to me is three fold:
-first, and most importantly, because I think of my class as a discrete object, I feel that it forces me to think very clearly about what that object is, what its properties and methods should be, and therefore do a good design UP-FRONT
-I create my classes independently of the application and test it in a test harness, because it exposes an clearly defined API, this is easy and eases testing, and proves the class before getting it tangled up in the application
- and thirdly, I can change the inputs/outputs very easily without affecting the application. For instance, in my new app we are saving the data in Excel spreadsheets, but we will be changing it to XML files shortly. This will be easy to do, I just add extra save/load procedures and add another property to say whether my data is to be saved as Excel SS or XML. Again no change to my app, the old save method may be deprecated, but it is still supported.
ALl of my apps have what I call an App class as well, where I define things specific to the application, such as messages, titles, app version, etc. etc. Other people would probably define these as global variables, I just prefer the class approach.
BTW, the use you highlight is very useful, but also very restricted. For instance, if you create a textbox event class, the Enter and Exit events are not exposed to the class, which reduces its benefit enormously IMO.Quote:
Originally Posted by moa
Thanks everyone for the continued information....
YLP
yes, thanks xld thats really interesting. Don't suppose you could post a workbook sometime that includes some of the things you talked about. I'd be interested in seeing your 'style' as I'm quite new to Excel and I like your approach.Quote:
Originally Posted by YellowLabPro
Glen,
I will have to create one as you can understand I cannot post my clients applications for confidentiality reasons. I am away for the weekend, so I will 'design' an example over the weekend, and create it next week (it might help with my advanced VBA classes).
At the moment, for teaching/seminars/classes I use an example where I create an MRU list for apps that use specific documents. It is a nice example, but a tad esoteric in my opinion. I will create an self-contained example that has an App class as I described, and a data class with more than one possible data source.
Cheers Bob! Looking forward to it.:)