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.

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.

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.

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.

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 great.

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 :

1. inheritance of visual and non visual objects
2. datawindow - really powerful
3. programmer friendly environment
4. PFC support is amazing - extends OO power of PB
5. support for distributed computing is great
6. better graphical query builder tool
7. better transaction management
8. 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.

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... m_gl_Environment.ActiveProject.Components(DesiredComponentName).PropertyName

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)... m_gl_Environment.Projects(m_gl_Environment.ActiveProjectIndex).Components(DesiredComponentIndex).TypeDefPropName

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.

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 normal economy.

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 fad.

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:

• 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 classes.

When I first saw this header, I thought "You do, unless you already know it all." ;-)

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 abstract/generalize.

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 multiple forms.

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 on....

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 String.len.

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.

Respond