Articles Weblogs Books School Short Cuts Podcasts

Listen Print Subscribe to Windows Subscribe to Newsletters

ShareThis
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. Related Reading

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), VB.NET Core Classes in
later completed the first OOP language in the world. The language
a Nutshell
is called Simula 67, short for simulation language.
By Budi Kurniawan,
Ted Neward
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 a senior J2EE architect and author.

References

Dhal, Ole-Johan Dhal and Nygaard, Kristen. "SIMULA-An Algol-based Simulation

Language," Communication of the ACM, vol. 9, no. 9, September 1966, pages 671-
678. A PDF version of this paper is available.

Gamma, Erich; Helm, Richard; Johnson, Ralph; and Vlissides, John. Design Patterns:
Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

Kölling, M. "The Problem of Teaching Object-Oriented Programming Part 1:

Languages," Journal of Object-Oriented Programming, 11(8), 8-15, 1999. A PDF
version of this paper is available.

Meyer, Bertrand. Object-Oriented Software Construction, Second Edition, Prentice Hall

PTR, 1997.

Return to .NET DevCenter

Recommended for You

 Tapworthy Print: $39.99 Ebook: $31.99

JavaScript Cookbook Print: $49.99 Ebook: $39.99

Learning Python

Print: $54.99 Ebook: $39.99

Tagged Articles
Be the first to post this article to del.icio.us

Sponsored Resources

• Inside Lightroom

Related to this Article

Introducing Silverlight 1.1

by Todd Anglin
October 2007
$9.99 USD

AutoIt v3: Your Quick Guide

by Andy Flesner
September 2007
$7.99 USD
 About O'Reilly Content Archive More O'Reilly Sites
Academic Solutions Business Technology O'Reilly Radar
Authors Computer Technology Ignite
Contacts Tools of Change for Publishing
Customer Service Google Digital Media
Jobs Microsoft Inside iPhone
©2010, O'Reilly Media,
Newsletters Mobile makezine.com
Inc.
O'Reilly Labs Network craftzine.com
(707) 827-7000 / (800)
Press Room Operating System hackszine.com
998-9938
Privacy Policy Digital Photography perl.com
All trademarks and
RSS Feeds Programming xml.com
registered trademarks
Terms of Service Software
appearing on oreilly.com
User Groups Web Partner Sites
are the property of their
Writing for O'Reilly Web Design InsideRIA
respective owners.
java.net
O'Reilly Insights on Forbes.com