Visual Basic took its first step into the world of object-oriented programming when Visual Basic 4 introduced classes. Visual Basic 5 extended the usefulness of classes by introducing the Implements keyword. Judging from the questions and answers I read in the news groups, many Visual Basic programmers don't use classes much. Most who do seem to use them only in a restricted way. They use a class here or there to package some sort of functionality, but they have not formed a rebuild-the-whole-world-in-classes bandwagon.
All this reminds me of the early days of C++. The C++ language is an extension of C so any valid C program is also a valid C++ program. A C++ programmer can use the extra object-oriented features of the language, or continue to develop programs that are pretty much plain C in disguise.
Initially programmers approached C++ cautiously. Many large programs were still procedural with a few classes thrown in where the benefit was greatest. They used classes to encapsulate data and functions where it made the most sense, but they stuck to traditional design methods.
As object-oriented design techniques became more popular, and a new crop of programmers weaned on C++ entered the workplace, programs grew more and more object-oriented--sometimes excessively so. I once worked on a project that died a spectacular death because one major subsystem was too object-oriented. What we needed was step-by-step functional design that took a pile of data through a series of easily defined stages. What we had was a collection of several dozen objects all trying to work together to pass the data around until it was processed. It was an interesting and elegant design, but it was too complicated to implement reliably in a reasonable amount of time.
Some processes are fundamentally procedural and don't need to be translated into classes to work. Programmers survived for decades without classes and object-oriented techniques. There's nothing magic about classes. They are just a syntactic tool like subroutines, property procedures, and For loops.
On the other hand, classes do have something to offer. They can encapsulate data and functionality to hide complexity from the rest of the program. They allow a program to create many copies of similar objects that each have their own separate variables.
So who needs classes? No one and everyone. Nobody really needs classes, but sometimes they make life easier. Use them where they make sense and program procedurally when they don't. In programming, as in life, most things are best in moderation. Those who overuse classes are making as big a mistake as those who ignore them altogether.
Antroy Ashton adds:
I agree with the report and unless you are building components or
resuable objects, then much attention is not given to Classes.
I happen to program both in VB and PB and sometimes make comparison
between the two. PB is truly an Object Oreinted Programming Lanuage -
OOP, supporting all aspects of OOP whereas Vb seems to highlight only a
few of these aspects.
For example: PB uses Non-Visual Objetcs and Visual Objects to achieve
OOP and offers more because one can inherit more than just code but the
GUI and the code.
Shalinder Verma adds:
I also happen to programme both in VB and PB and I agree with Antroy that PB is much more OOPS than VB. Moreover, PFC(Powersoft Foundation CLasses) provided by Powersoft is amazingly powerful. I have a great faith in OOPS and was always in search of true OO front end tool, before i came across PB. It is just GREAT!.
BUT the worst part is that VB is used more than PB.
I would like to know whats great thing in VB for its such wide usage.
Rod Stephens replies:
I think a lot of this has to do with marketing. Microsoft uses VB as its backend to all the Office and Web tools. If you use Access, Excel, Word, PowerPoint, ASP, VBScript, etc. then you are already a VB programmer. That gives them a huge embedded base of potential customers.
And say what you like about Microsoft, it's hard to deny that they have an effective marketing organization.
I haven't used PowerBuilder, but I know a lot of people like it. The system I've used that I would put up against VB is Delphi. It's object-oriented Pascal, a strongly typed language that makes a lot of common VB bugs impossible. I think if Microsoft had written it, it would probably be taking over the world.
My vote for the best object oriented language is Java.
I have been programming in VB for five years and I just started to delve into the world of real objects with JAVA.
As far as for the answer of who needs classes any way. If you are asking this question you should not use them.
I don't think you should program at all.
Rod Stephens replies:
That's a little extreme. I've been programming off and on for 20+ years and somehow the universe got along just fine before Java and classes. Classes are just another abstraction tool. They can make things easier under some circumstances and harder under others.
I share the fact with you that MS employs good marketing techniques.
and thanx for letting me know about delphi. As u said, it is OO Pascal, its
Unfortunately i've never used delphi.
But i find PB very much OO and is written in VC++. I believe VC++ is a very
powerful language so PB inherits that power from it.
For me it does not matter, which tool is hot in the market, but if its OO
way strong, I believe its worth. Here are some features which PB has and VB
does not have or PB implements better than VB :
I request u to make a smilar analysis vis a vis delphi/VB.
and do let me know...
- inheritance of visual and non visual objects
- datawindow - really powerful
- programmer friendly environment
- PFC support is amazing - extends OO power of PB
- support for distributed computing is great
- better graphical query builder tool
- better transaction management
- object library concept
For me it does not matter, which tool is hot in the market,
but if its OO way strong, I believe its worth.
That's a nice goal, but you can never really live that way. If a product is strong, the company has money to continue development and give it new featues. Sometimes Microsoft is too string and they release products full of new features just to try to make you buy a new version when they really haven't added anything useful.
On the other hand, if a product is weaker, it may stagnate due to lack of funds. It may also have a much smaller user base and that reduces the number of books and articles helping you get the most out of it.
I'm not sure which of those features is supported by Delphi. I know it has a good user environment, inheritance, and object libraries. It also produces code that is usually smaller and faster than the code produced by VC++. I haven't used most of its other features, however, so I don't know much about its reporting, data processing, etc.
I dont feel that Braunb's argument is anyway at any extreme but a positive step towards the world of object oriented programming. If we see this whole argument from this point of view that : once there was assembly programing, which was replaced (not completely) with function oriented programming (C, Cobol, Pascal), which is now getting replaced with Object oriented programming. Although, we are in OO age but we can still have many programmers of assembly programming age.
If we go by this view that "somehow the universe got along just fine before java and classes" then we wont we able to progress with further developments.
I view Object Oriented programming as a new paradigm, like Internet.
Remember world was moving fine before internet or take computers.
That wasn't exactly what I meant. My point was, classes are just another way to encapsulate complexity. My algorithm book has a lot to say about good ways to use classes to make certain things easier to implement and debug. They are a very useful technique, but they are not a magic solution.
Some managers think object-oriented programming can fix their bad development process and that's just not true. Just like any other technique, classes can be used and abused. I once worked on a C++ project that was destroyed because a programmer got carried away and designed an elegant class hierarchy to manage interprocess communication, but it was so complex no one could use it.
I've also seen programmers create a class to hold numbers. Instead of just adding 4 and 21, they would create two number objects, instantiate them, initialize one to 4, initialize the other to 21, combine them, and evaluate the results. Why not just add 4 and 21?
I am not trying to say the "good old days were better." I'm just saying that you need to understand when to use classes and when not to. Just because something is new does not mean it is better.
In your "Reply to Essay: Who Needs Classes Anyway?" several people have
discussed which is the better programming language (VB, PB, Delphi,
etc.). I understand this discussion from the programmer’s point of view.
However, the client’s point of view has more impact on my life!
My clients are justifiably concerned about the longevity and
supportability of custom programs and VB is easier to sell because of
Microsoft’s reputation. I don’t believe VB is the best programming
language but my clients believe VB will still be around in 5 years and
consultants will still support it.
Many companies had custom programs written for them (especially in the
DOS days) and many of these programming languages or platforms are no
longer available and no longer supported. That’s life... but clients are
far more cautious today.
Once again, Microsoft’s marketing power may be preventing better
products from gaining the recognition they deserve.
I understand this very well, when I first started programming (about two and a half years ago), I never used classes once, in fact, I hadn't used classes until I got Visual Basic 6.0. I understand how to use them correctly (at least I believe I do).
They are very well used like Rod said for encapsulation of various data types, such as trees of information, they are much easier done with a class then a structure (anything done with a class can be done with a structure, or a type definition).
Classes are by no means absolutely necessary, they are just like a luxury item that makes things go a bit smoother for the programmer. It can organize the code and make it easier to follow.
In my project that I am currently working on, I have projects that the user is responsible for. They consist completely of objects, the designer windows, the code windows, and the script windows (click based code window alternative), and everything else. My point is, without classes the project would literally either fall apart, or take a LOT longer to complete due to the way I would have to end up doing things.
A good example to help demonstrate this would be the following....
If I wanted to access something in the user's active project, I could access it probably like this...
However if I used no objects at all, it would be infinitely (or thereabout) more difficult, it would probably go something like so (if the objects were an alternative defined type definition)...
Now as you see, that would take a lot more typing, in doing so, I would also have to do a lot more to just select a component. If I wanted to look up a component by name, odds are I would have to do a search through the components to determine where the Index of the structure is.
Also, without objects, it would be a bit more difficult for someone desiring to create an add-in for the program to figure out how things work. The first example would be easier discovered then the second (simply my opinion).
What about reusability?
Seems to me the discussion of classes has gone around in circles several
times, with a lot of good points being made by all sides of the
argument. Now I'm just a simple country engineer who happens to be a RAD
project manager. Most good programmers can code circles around me, and
that's the way I want it, because my job is to bring projects to the
CLIENT on spec, on time, on budget.
So lets go back a few steps to what Jon Kurpias had to say. Jon was the
first person that I could see who mentioned the "C" word. Forgive me if
I've missed anyone here. In the software world, the client is king, the
client knows best, the client is always right - because the client pays
the bills. For the purists in the crowd, bite your tongue and live with
it. Its a fact of business life. The client must be happy with whatever
you are doing, or you're not going to be doing it for very long (at
least getting paid to do it).
How does this mesh with the discussion on classes? It relates to the RAD
nature of most major software projects. Whatever is being designed, no
matter what the language of choice (be it C++, VB, Java, PB, etc.), that
design must have some common and significant ingredients to be
acceptable to most major clients: functional, maintainable, reusable,
robust, secure, portable, system-efficient. And of course
cost-effectiveness is the very important side-bar player in every one of
the aforementioned characteristics.
The judicious use of classes serves to enhance all of these
characteristics and thus improve cost-effectiveness. On the other hand,
the religious uses of classes can sometimes (not always) take the
cost-effectiveness curve over its apex and have detrimental effects on
overall program performance.
What every programmer has to be is open minded about the use of any
coding enhancement such as classes. If its good for the client, then use
it well. If its not good for the client, then don't use it, even if your
ego is offended.
Kudos to all for a good discussion string.
Jose L. Perez:
Some way or other, each has a point here. Extreme points of view will be moderated, in their due time, as they learn how to survive in a
I remember, a long time ago (60's - 70's), the whole story about "Structured Programming".
It sounds to me like "Classes". There were some very strong advocates that would
excomulgate anybody using GoTo, and some strong detractors stating the whole thing was a
Nowadays the concepts of structured programming are widely used, judiciously, and most
programmers try to avoid using unnecessary GoTo's, but can use them if required (even
disguised as "Break" or "Exit Loop" or whatever).
On their due time, the Object Oriented
concepts and practices will be widely used, taking from them what is really valuable,
applying them when they are really needed and can enhance the current project. Most
programmers or system designers will NOT jump into the current technology bandwagon just
because some few shout out loud about it. The process of technology and practices
acquisition is slow, just as the learning process.
By the way, I started using Object Oriented concepts around the 80's (there are some
groundbraking articles about SmallTalk in Byte magazine along those years, mainly about
research at Xerox PARC). I used SmallTalk. I liked it a lot. Now I'm a Visual Basic user
-- I must eat (at least once in a while). The concepts I learnt on those years have helped me be a much better programmer/designer nowadays. But I
still use modules and types ... and a GoTo once in a while.
I see one of the main challenges in software development is the managing of complexity.
Usually the customer's business problem requires a "complex solution". The challenge for the developer is to
implement this in a non-complex way.
This is best achieved by breaking the problem down into smaller pieces.
If this is not done then you may end up with single forms containg:
Other programmimng problems in the past, included lack of encapsulation etc.
I suspect one of the reasons OOP has been used more than it should, was to force developers to cure those
- ADD mode
- EDIT mode
- Frames with lbo's/DataLists etc
However it is quite possible, and in fact refreshingly rewarding, to just simply break the complexity down and
solve it with multiple forms, modules, etc, and ENCAPSULATION.
There are definite occasions where classes(VB) are required, such as multiple instances etc.
However the guideline should be Do not use them just to cure your previous bad design/programming problems.
And why shouldn't you use them everywhere?
Back to my original point - you will be introducing more complexity whilst trying to manage all of those
When I first saw this header, I thought "You do, unless you already know it
But, I immediately dove in and read the responses. I agree that the threads
appear to be revolving in circular arguments, and that you would only need
classes for certain reasons in certain places, etc.
I have been programming only for a few years, mostly in VB, some Natural,
COBOL and Clipper. As one threader say, I would be classified as a
Functional programmer. I am always learning about programming, and although
I consider myself to be quite good, I am still a "Newbie" in quite a few
areas. And as a "Newbie", I am hoping that everyone will forgive me when I
ask... "What is a Class and How does one use it?"
The example provided by MicroSoft ("My World") appear to be confusing and
appear irrelevant to real world situations. Something I would like to see
Rod put up is a more definitive and useful description of Classes, the use
of Classes in a real world situation with some proper examples. It would
help to clear up some of the "Newbies" confusion (including my own), and
also provide the "Newbies" with some proper background so they can feel more
knowledgeable and appreciative when reading this essay.
[Take a look at the essay
What Are Classes For and Why Are They Useful?
for an example that may help. I'll try to come up with some example code and post it there. -- Rod]
In regards to the issue of "OOP-always" vs. "Procedures with OOP-sometimes",
I'd like to add something a little abstract perhaps... for me I always like
to go for classes and here's why: writing the classes forces you to
With thought you usually end up with something general purpose that you can
readily reuse later. At the time you write it you may only have one use for
it, but sure enough later on you need it again.
Abstracting/generalizing also sets parts of your brain in motion. A few
months later, after using the classes, it occurs to you how they could be
generalized again to suddenly make them much more powerful. And, with the
next project, you get your chance?
Procedural programming comes about when you find yourself repeating lines of
code and you extract them into a procedure. OOP comes about when you find
yourself repeating ways of doing things and you extract them into general
classes - adding to your 'language'.
Creating a set of classes for a task is a bit like adding more 'language' to
your code libraries which procedural code does not allow (procedures are
like words and class sets are like grammar - as an analogy).
A real example (ref: business object architectures)...
We've all worked with or created 'horrendously complex' GUI forms which
involve multiple datasets and business rules that span datasets. E.g.
calculations, conditional disabling of controls, validations. The funny
thing is that our client comes up and tells us a rule like "dental factor
entry is disabled if payment is monthly" and its a really simple concept.
Its a one-line instruction from them to us. Traditionally though the code
to implement this is many lines spread over multiple places. For example,
you cannot just enable or disable the control so easily because is
enabledness depends on other rules.
As well as rule interactions we have triggered rules - e.g. calculations.
To make a long story short(er) you find code in your form procedures like
"SetEnablednessOfMyControls" which contains logic from multiple rules
together, combined - not good. And logic from one rule is found in multiple
such procedures. I.e. the business logic is highly non-modular. The form
might be wonderfully 'modular' but the real complexity of a real-life data
entry GUI is not in the bringing up of the forms and clicking buttons, it is
in the implementation of the business rules.
We made classes to add a mini 'language' to allow us to specify a business
rule individually without reference to any other business rule or any GUI
element. I.e. we specify "dental factor entry is disabled if payment is
monthly" as a one-liner in the code (c.f. a logical language like Prolog).
The business logic code is just a sequence of one-liners all independent of
one another, enumerated in a non-GUI source code file. We can add and
remove rules very easily in this way. When the time came to implement
security, for example, we just added rules: e.g. "dental and vision factors
are disabled for this security group". This rule interacts with the other
rule, but we add/write them in the system individually without reference to
each other. We were able to express a business rule as simply as it was
given to us.
The forms we coded did not contain any business rule logic and our business
rules did not reference GUI elements. Using classes made this possible,
maintainable, robust, & reusable. Even within the same application the
business rules are 'alive' in multiple forms on the same data, which saved
us from remembering or having to repeat code and maintain the same rule in
I guess my point is that these classes: a) solved a complexity problem
allowing us to simply code business rules for the GUI, & b) would never had
existed if I had not had previously created earlier 'generations' of these
ideas in the past.
I have been developing distributed enterprise systems for the past 5
years, I would agree with many of the points above, one system I worked
on was based around a multi-dimentional OO database which employed
ragged hierarchical data sets, and I cant think of anyway that we could
have programmed this without classes, but I have also seen smaller
systems that have been completely over engineered as the developer was
using classes just for the sake of using classes. I think this all boils
down to the fact that this, is not an issue with visual basic but is an
issue which is inherent in software design and with any language there
will always be issues with, should we use classes, if so how many
classes does the system have, how far do we abstract and so on and so
Also I find it interesting that nobody has mentioned VB.NET yet. Having
played around with the beta version for a while you begin to realize
that every thing is an object (an instantiation of a class). For
example, to get the length of a string in .NET the syntax would be
Joe "Space Invader" Foster:
One of the most compelling things about classes in VB is Class_Terminate.
How many of you forgot to close a file or release some Windows resource
handle in VB 3.0 code? If you wrap the resource with a class, you can't
forget to release the resource when a subroutine exits perhaps because of
a run-time error or use of Exit Sub or Exit Function.
Take a look at this.
Note that Delphi doesn't support RAII except in classes implementing an
interface, while Java and .NET all but guarantee resource leaks unless
you thrash heap memory enough for the garbage collector to kick in often.
Oh well, it's too late now: Visual Basic is dead. It's very sad when it
would be easier to migrate to Delphi or even C++ than to what Microsoft
claims is the current version of Visual Basic! However, Real Software's
RealBasic may offer a viable migration path.