It is not enough just to know how to write object-oriented programs; you also have to know how to write object-oriented programs well. As you gain experience writing object-oriented programs, you will discover certain programming idioms that are used over and over again. These idioms are called design patterns.

DESIGN PATTERNS

Design patterns were first described in Design Patterns—Elements of Reusable Object-Oriented Software (Gamma 1995). A design pattern is a solution to a recurring problem in object-oriented design and implementation. There are four parts to a design pattern, as described in Gamma et al.'s book (Gamma 1995, p. 3):

• Pattern name—A name for making it easier to discuss using the pattern.

• Problem—An explanation of the problem and its context.

• Solution—An abstract description of the design problem and how to use VB.NET code to solve it.

• Consequences—The pros and cons of implementing the design pattern.

The Shared Factory Method

Using constructors to create instances of classes is not always the preferred approach to instantiating class objects. One problem with constructors is that they don't have names, which can lead to confusing code. Another problem with constructors is that each constructor has to have its own signature, meaning that only one type of class object can be instantiated for each signature.

We can work around these problems by writing methods that create objects. This is a design pattern known as a factory method. In this case, we create a Shared Factory method that can be called without needing an instance of a class.

This chapter introduces the class, the primary means of implementing OOP in VB.NET. The class framework provides the programmer with many techniques for exploiting the three main principles of OOP—encapsulation, inheritance, and polymorphism.

Classes are somewhat similar to structures in that they allow you to combine data members and methods in the same unit. Classes, though, are much more powerful than structures because they have many more tools available to them. These tools include constructor methods for creating new objects and the capabilities of having multiple methods with the same name and inheriting the definition of one class in another class.

This chapter begins with an overview of class construction, followed by the step-by-step creation of a class, and finally ending with several more examples of creating and using classes. The next few chapters in the book will explore many of the topics we introduce in this chapter.

BUILDING A CLASS

Class construction follows naturally from a well-designed ADT. There are some modifications we'll have to make to our ADT design to incorporate some concepts found in classes but not in structures. Still, a complete ADT makes building a class much easier than if you start from scratch.

The Class Heading

Like a structure, a class definition begins with its heading. The heading of a class consists of an access modifier, the reserved word Class, and a name for the class.

Visual Basic is arguably the most popular application development programming language in use today. Thousands, if not millions, of programmers use it every day to build both commercial and scientific applications. The language is also one of the most maligned programming languages, second perhaps only to Cobol.

The newest version of Visual Basic, Visual Basic.NET (VB.NET), should eventually quiet many of those who call Visual Basic a toy language. Microsoft performed a major redesign of Visual Basic and added many features that put the language on equal footing with the other major.NET language, C#, and with other contemporary languages, especially Java.

One area of the language that has seen significant improvement is VB.NET's object-oriented programming features. In previous versions of Visual Basic, many of these features were partially implemented, not implemented at all, or implemented in a wrong-headed manner. VB.NET provides the programmer with a complete set of object-oriented tools. This book explains in detail how to use these features.

The book is informally partitioned into three parts. Chapters 1 through 6 present the fundamentals of object-oriented programming (OOP) using VB.NET. Chapter 1 provides a review of the syntax of VB.NET. This chapter is especially useful for readers who have experience with an older version of Visual Basic. Chapter 2 discusses the philosophy of OOP, including some sections on object-oriented design and abstract data types. Chapter 3 covers programming with structures, which are similar to user-defined types (UDTs) in Visual Basic 6.

Serialization is the process of capturing the current state of a class object and writing the state to disk. Serialization allows you to make a class object persistent, which means that you can save the current state of an object while a program is running and at a later time retrieve that state and continue using the object. In this chapter, we'll show you how to perform both serialization and deserialization, which is retrieving an object's state from disk.

SERIALIZATION DEFINED

Serialization in VB.NET involves writing out the state of a class object as a series of bytes to a byte stream. The CLR writes out a class object as an object-graph, which consists of the class object and all the member data associated with the object. To let the CLR know that a class can be serialized, it must be marked with the Serializable attribute.

Although classes must be marked to be serialized, primitive types do not have to be marked as such. Therefore, all the primitive types within your class definition will be serialized automatically when the class is marked Serializable. Other objects (such as nested classes) within a class definition must be tagged with the Serializable attribute if they are to be serialized with the rest of the class types.

A class is physically serialized using a formatter. A formatter, as its name suggests, defines the format of the data stream that is written to disk.

ABSTRACT CLASSES

As you write more and more complex programs, you will find situations where you want to define classes that are so abstract that you will not want users to implement them directly. Instead, you will want to derive classes from these abstract classes that define more specific data and behavior. Abstract classes are implemented in VB.NET using the MustInherit keyword.

A simple example that beautifully illustrates the concept of abstract classes is food. When you go to a restaurant, you don't order just food. You order some type of food, such as steak, or a salad, or apple pie. Each of these is a specific instance of food, sharing some characteristics with the others, while obviously also differing from the others in substantial ways. Abstract classes let us define a high-level abstract object, such as food, that we can then use as a base class for many different derived classes. Because we would never want to instantiate the abstract class, we mark it abstract (MustInherit) so that it is clear the class is to be used as a base class only.

Creating Abstract Classes

To designate a class as an abstract class in VB.NET, we use the MustInherit keyword. Once a class is defined this way, we can only use the class as a base class for other derived classes.

Within an abstract class, we can declare the usual private data members, constructor methods, property methods, and so on.

One of the most confusing aspects of OOP is determining the proper access modifier to use for classes and class data members and methods. If you provide too much scope for a data member or method, you risk violating data encapsulation, leading to unwanted data access. If your scope is too restrictive, other classes that need access to a class's data or methods won't be able to access them. In this chapter we discuss the different access modifiers, how they are used to manage class member and method scoping, and when to use each modifier. At the end of the chapter we discuss how these access modifiers work with classes themselves.

The access modifiers available in VB.NET are the following:

• Public

• Private

• Protected

• Friend

• Protected Friend

We also discuss the modifier Shadows in this chapter. A method declared as Shadows in a derived class hides any methods in the base class with the same name. In effect, a method that shadows another method redefines the shadowed method's behavior.

PUBLIC ACCESS

A class member or method marked as Public can be accessed by any part of the class body, by any part of the project in which the class definition is located, or from an assembly built from the project containing the class definition. This is the least restrictive access and is frequently misused by many programmers.

Reflection refers to the ability of a VB.NET program to access the metadata stored in both running and existing assemblies. Using these metadata, you can examine the contents of a program, manipulate the metadata in the assembly, and even dynamically create and execute objects at runtime. Reflection allows us to dynamically invoke class member functions and even instantiate class objects dynamically.

Attributes are custom-written metadata you can add to an existing assembly. Attributes are used for several purposes:

• to indicate whether a class is serializable (see Chapter 13 for information on what this means);

• to indicate individual class fields that are not serializable;

• to perform conditional compilation; and

• to create strongly named types.

Attributes are created as classes that inherit from the System.Attribute class. Attributes are accessed using reflection, so these two topics build on each other.

USING REFLECTION

As we've already stated, reflection allows us to examine the metadata found in our VB.NET programs. To use reflection, we have to import the System. Reflection class into our application. From there, we have to decide which assembly we want to inspect and which metadata we want to look at in the assembly.

Returning Metadata from an Assembly

Assembly metadata can be returned from assemblies that exist on a machine and assemblies that are currently running on a machine. An assembly's metadata are stored in the assembly's manifest, either in a PE (portable executable) file with the MSIL code for the assembly or in a standalone PE file.

This chapter presents an overview of the syntax and primary constructs of the Visual Basic.NET (VB.NET) language for programmers unfamiliar with VB.NET. This is not a tutorial chapter, however, so if you are new to programming you should study another text on VB.NET before continuing with this book. If, though, you are coming to VB.NET from some other language, such as C++ or Java or even Visual Basic 6, you should read through this chapter to familiarize yourself with the language.

NET PROGRAMS

There are two ways to build programs in VB.NET. One is to use the Visual Studio.NET Integrated Development Environment (IDE). The other is to use the command-line compiler packaged as part of the.NET Framework Software Development Kit (SDK). In this section we'll discuss developing programs with the command-line compiler, since this software is free and can run on any of the modern Windows operating sysems (Windows 98 and beyond).

VB.NET Program Types

With VB.NET, you can write many different kinds of programs. A VB.NET program that makes use of a graphical user interface (GUI) is a Windows application. A VB.NET program that uses the command-prompt console for input and output is called a Console application. You can also write Internet applications, Windows Services applications, and other types of applications.

A Windows application is by necessity written in an object-oriented manner. This chapter discusses the code generated by VS. NET when a Windows application is built. We'll examine both the code generated by VS. NET and the code created when a programmer builds an application. We will also examine how to use object-oriented principles in the code the programmer adds to the application.

As the noted computer scientist and education theorist Seymour Paper once stated, “You can't think about thinking without thinking about thinking about something.” Likewise, you can't examine building a Windows application without having a Windows application to build. To that end, the application we'll use to illustrate how object-oriented principles aid the creation of a Windows application is a basic calculator, similar to the one found in Windows. By picking a rather simple application that uses many widely employed Windows features (e.g., textboxes, buttons, and labels), we can focus on how taking an object-oriented approach makes the development easier and more efficient. We should also mention that this chapter is not designed to teach a novice how to create a Windows application; rather it teaches how to create a Windows application in an object-oriented way. We assume the reader already knows how to place controls on a form and already knows the basics of writing event-driven code.

Software development is a complex endeavor. You create a variety of artifacts throughout a project, some of which you keep and some you do not. Regardless of whether you keep the artifact, the reason why you create it (I hope) is because it adds some sort of value. Perhaps you create a model in order to explore a business rule, a model that may then be used to drive your coding efforts. If the model is wrong then your code will be wrong too. If it is a complex business rule, one that requires a significant amount of time to implement, you might be motivated to validate your model before you act on it. If it's a simple business rule you might instead trust that your code-testing efforts will be sufficient. You will also find that many artifacts, such as user manuals and operations manuals, never become code yet still need to be validated. The point is that you will need testing techniques that enable you to validate the wide range of artifacts that you create during software development.

In this chapter I explore the following:

• The cost of change;

• Testing philosophies;

• The FLOOT methodology;

• Regression testing;

• Quality assurance;

• Techniques for validating models;

• Techniques for testing code;

• Techniques for system testing;

• Techniques for user-based testing; and

• Test-driven development (TDD).

THE COST OF CHANGE

A critical concept that motivates full-lifecycle testing is the cost of change.

The predominant development technologies are object technology for implementing business logic and relational database (RDB) technology for storing information. You have other options—procedural technologies such as COBOL for implementing business logic and XML-based or object-oriented databases for storage, for instance. COBOL is beyond the scope of this book and XML databases and object databases are at best niche technologies (albeit very interesting ones). My focus is on mainstream, modern development, and that means objects on the front end and RDBs on the back end.

The fit between object technology and RDB technology is not perfect. In the early 1990s, the difference between the two approaches was labeled the object/relational impedance mismatch, also referred to as the O/R impedance mismatch or simply the impedance mismatch, terms still in common use today. Why does a technological impedance mismatch exist? The object-oriented paradigm is based on proven software engineering principles. The relational paradigm, however, is based on proven mathematical principles. Because the underlying paradigms are different, the two technologies do not work together seamlessly. The impedance mismatch becomes apparent when you look at the preferred approach to access: With the object paradigm you traverse objects via their relationships, whereas with the relational paradigm you join rows of tables. This fundamental difference results in a nonideal combination of the two technologies, although when have you ever used two different things together without a few hitches?

Agile software development has moved from the fringes of the software development community to the mainstream. This movement is driven by the need to produce better software faster, which is integral to developing competitive advantage in the global software community. From North America to Asia and everywhere in between, the ability to deliver software that delights the customer has become a critical success factor. The agile community particularly focuses on that customer and ensures that he or she receives maximum value.

Much of the way that we traditionally built software was based on the constraints posed by the systems of old. The amount of time needed to compile these systems was large and software development processes were built around this activity. Getting the code right the first time was important to maximize productivity in this environment. However, many of today's integrated development environments (IDEs) no longer require us to compile the whole system to add some new functionality. In fact, newer compilers often help us get the syntax of our programs correct as we are writing it.

The agile software development movement is taking advantage of the lifting of these constraints. All agile software development processes focus on creating small increments of functionality using an iterative approach. This new approach is in contrast to the “big bang” or waterfall approach where the software is delivered all at one time. Again, today's technology and software development processes allow us to lift another constraint.