Introduction to OOP in VB.NET

 

by Budi Kurniawan
09/23/2002

Visual Basic .NET offers its users, among many other things, a fully object-oriented programming (OOP) experience. Some former VB6 developers have prepared themselves well to embrace this new version of the language. Others, however, need more time and guidance in taking on this new challenge and opportunity. In this VB.NET OOP series, Budi Kurniawan introduces many facets of object-oriented design and programming to VB programmers new to OOP. Discussions focus more on OO concepts rather than OO techniques. In the first article of this series, Budi answers what is probably the most often asked question by newcomers to OOP: Why OOP? Finally, we look at why VB6 programmers often find it hard to shift to OOP when the OOP itself is not difficult.

Microsoft launched the .NET Framework early this year and overhauled its most popular language: Visual Basic. With the introduction of the Framework, the language was reconstructed and given a new name: VB.NET. It's now a language that fully supports object-oriented programming. It is true that VB6 supported some notion of objects, but lack of support for inheritance made it unfit to be called an OOP language. For Microsoft, changing VB is more of a necessity than a choice, if VB is to become one of the .NET Framework languages and in order for VB programmers to be able to use the .NET Framework Class Library.

With the change to the language, many VB fans might think that OOP is a natural progression from procedural programming, and that OO technology is a new technology. Surprisingly, this is not the case. OO concepts were first introduced in 1966 in a journal paper titled "SIMULA-An Algol-based Simulation Language." Its authors, Ole-Johan Dhal and Kristen Nygaard from the University of Oslo and the Norwegian Computing Center (Norsk Regnesentral), later completed the first OOP language in the world. The language is called Simula 67, short for simulation language.

You may find it hard to believe that a full-fledged OO language was implemented before structured programming and when, as OO expert Bertrand Meyer puts it in his book, Object Oriented Software Construction, "The Vietnam War was still a page 4 item; barricades had not yet sprung up in the streets of Paris; a mini-skirt could still cause a stir." However, OO technology did not become popular until the early 1980s, because at the time of invention, it was considered too radical for practical use. VB only became a fully OOP officially in 2002 and the inventors of this technology, Ole-Johan Dhal and Kristen Nygaard, only got their Turing Award, considered the Nobel prize of computer science, in 2001 "for ideas fundamental to the emergence of object-oriented programming, through their design of the programming languages Simula I and Simula 67."

Why OOP?

OK, enough history. Now, let's discuss why OOP in VB is a good thing. There are many benefits of OOP that make the technology so popular and the computing science society grateful to its inventors. Below, I will mention the three most important ones, in no particular order.

Modularity is Inherent in OOP

Modern software applications tend to become larger and larger. Once upon a time, a "large" system comprised a few thousand lines of code. Now, even those consisting of one million lines are not considered that large. When a system gets larger, it starts giving its developers problems. Bjarne Stroustrup, the father of C++, once said something like this: a small program can be written in anything, anyhow. If you don't quit easily, you'll make it work, at the end. But a large program is a different story. If you don't use techniques of "good programming," new errors will emerge as fast as you fix the old ones.

The reason for this is there is interdependency among different parts of a large program. When you change something in some part of the program, you may not realize how the change might affect other parts. Modularity makes maintenance less of a headache. Modularity is inherent in OOP because a class, which is a template for objects, is a module by itself. What is the problem for those new to OOP is how to determine what methods and data should make up a class. This is another topic of its own, though. A good design should allow a class to contain similar functionality and related data. An important and related term that is used often in OOP is coupling, which means the degree of interaction between two classes (modules).

OOP Promotes Reusability

Reusability means that code that has previously been written can be reused by the code writer and others who need the same functionality provided by the code. It is not surprising, then, that an OOP language often comes with a set of ready-to-use libraries. In the case of VB.NET, the language shares the .NET Framework Class Library with other .NET languages. These classes have been carefully designed and tested. It is also easy to write and distribute your own library. Support for reusability in a programming platform is very attractive, because it shortens the time taken to develop an application. In the world where good programmers are expensive, what else is more appealing?

One of the main challenges to class reusability is creating good documentation for the class library. How fast can a programmer find a class that provides the functionality he/she is looking for? Is it faster to find such a class or to write a new one from scratch? In the .NET Framework Class library, classes and other types are grouped into namespaces. For instance, the System.Drawing namespace contains the collection of types used for drawing.

VB.NET programmers are lucky, because the .NET Framework comes with good documentation, with proper indexing and structured and searchable content. Reusability does not only apply to the coding phase through the reuse of classes and other types; when designing an application in an OO system, solutions to OO design problems can also be re-used. These solutions are called design patterns, and to make it easier to refer to each solution, the pattern is given a name. For example, if you need to make sure that a class can only have one instance, there is already a solution to it, which is called the "singleton" design pattern. The early catalog of reusable design pattern can be found in Design Patterns: Elements of Resusable Object-Oriented Software. In future articles, I will also discuss the use of these patterns.

OOP Supports Extendibility

Every application is unique. It has its own requirements and specifications. In terms of reusability, sometimes you cannot find an existing class that provides the exact functionality that your application requires. However, you will probably find one or two that provide part of the functionality. Extendibility means that you can still use those classes by extending them so that they provide what you want. You still save time, because you don't have to write code from scratch.

In OOP, extendibility is achieved through inheritance. You can extend an existing class, add some methods or data to it, or change the behavior of methods you don't like. If you know the basic functionality that will be used in many cases, but you don't want your class to provide very specific functions, you can provide a generic class that can be extended later to provide functionality specific to an application.

A good example is the System.Windows.Forms.Form class, which provides basic methods, properties, and events for a Windows form. To create a form in a Windows application, you extend this class. Because your application has specific requirements that do not necessarily exist in other applications' specifications, you can add the methods and data specific to your need. You save time and programming (and debugging) efforts because you get the basic functionality of a form for free by extending System.Windows.Forms.Form.

As another example, take a look at the Control class in the System.Windows.Forms namespace. This class provides basic functionality for a Windows control. For instance, it has the BackColor property that will be needed by all Windows controls. Other classes that extend it get this property for free. Examples of classes that extend the Control class are Label, MonthCalendar, ScrollBar, etc. These classes need the BackColor property as part of their user interface.

Not every control needs the SetCalendarDimensions method, however; only MonthCalendar does. Therefore, the designer of the .NET Framework class library didn't put this method in the Control class, but in the MonthCalendar class. If you create your own custom control by extending the Control class, your class, too, will get the BackColor property for free.

VB6 Programmers and OOP

Now, I hope you agree with me that to work within the .NET Framework, VB programmers need to master OOP. In the light of this, there is bad news and good news. The bad news is, the VB versions prior to VB .NET, including VBScript and Visual Basic for Applications (VBA), are not fully OOP languages. It is true that you could use and write COM components, which are basically objects; this is probably the reason that some people insist that VB6 is an OOP language. The lack of other OOP features such as inheritance, however, disqualify previous versions of VB from being an OOP language (for the criteria of an OO system, see Chapter 2 of Bertrand Meyer's Object-Oriented Software Construction, Second Edition).

It is probably more appropriate to categorize the old VB into something between a procedural language and an OOP language. This is bad news for those wanting to learn VB.NET. Researchers have been arguing about the best way to teach OOP at school; some argue that it is best to teach procedural programming before OOP is introduced. In many curricula, we see that the OOP course can be taken when a student is nearing the final year of his/her university term.

More recent studies, however, have revealed the contrary. Michael Kolling, from the School of Computer Science and Computer Engineering, Monash University, Australia, explained in one of his papers why learning OOP seems harder than learning structured programming. He and other experts argue that it is how OOP is taught, not OOP itself, that makes it such a difficult task.

Someone with procedural programming skill thinks in a paradigm very different from how OO programmers view and try to solve problems. When this person needs to learn OOP, he/she has to go through a paradigm shift. It is said that it takes six to 18 months to switch your mindset from procedural to object-oriented paradigms. Another study shows that students who have not learned procedural programming do not find OOP that difficult.

Now the good news. VB.NET is a relatively easy language to program with. VB.NET programmers do not need to worry about pointers, don't have to spend precious time solving memory leaks caused by forgetting to destroy unused objects, etc. The .NET Framework also comes with a very comprehensive class library with relatively very few bugs in its early version. Once you know the nuts and bolts of OOP, programming with VB.NET is easy.

Conclusion

This article has presented the main benefits of OOP and why procedural programmers find it hard to learn OOP. OOP is great for writing many types of applications. A word of caution, though: OOP is not everything. For example, some people cannot be convinced that using OOP is better at solving engineering or quantum mechanics problems than procedural programming.

Budi Kurniawan is an IT consultant specializing in Internet and object-oriented programming, and has taught both Microsoft and Java technologies.