Programming Visual Basic .NET, Second Edition

Chapter 4. Object-Oriented Programming

Windows and web programs are enormously complex. Programs present information to users in graphically rich ways, offering complicated user interfaces, complete with drop-down and pop-up menus, buttons, listboxes, and so forth. Behind these interfaces, programs model complex business relationships, such as those among customers, products, orders, and inventory. You can interact with such a program in hundreds, if not thousands, of different ways, and the program must respond appropriately every time.

To manage this enormous complexity, programmers have developed a technique called object-oriented programming. It is based on a very simple premise: you manage complexity by modeling its essential aspects. The closer your program models the problem you are trying to solve, the easier it is to understand (and thus to write and to maintain) that program.

Programmers refer to the problem you are trying to solve and all the information you know about that problem as the problem domain . For example, if you are writing a program to manage the inventory and sales of a company, the problem domain would include everything you know about how the company acquires and manages inventory, makes sales, handles the income from sales, tracks sales figures, and so forth. The sales manager and the stock room manager would be problem domain experts who can help you understand the problem domain.

A well-designed object-oriented program will be filled with objects from the problem domain. At the first level of design, you’ll think about how these objects interact, and what their state, capabilities, and responsibilities are.

State

A programmer refers to the current conditions and values of an object as that object’s state. For example, you might have an object representing a customer. The customer’s state includes the customer’s address, phone number, and email, as well as the customer’s credit rating, recent purchase history, and so forth.

Capabilities

The customer has many capabilities, but a developer only cares about modeling those that are relevant to the problem domain. Thus a customer object might be able to buy an item, return an item, increase his credit rating, and so forth.

Responsibilities

Along with capabilities come responsibilities. The customer object is responsible for managing its own address. In a well-designed program, no other object needs to know the details of the customer’s address. The address might be stored as data within the customer object, or it might be stored in a database, but it is up to the customer object to know how to retrieve and update his own address.

Of course, all of the objects in your program are just metaphors for the objects in your problem domain.

Metaphors

Many of the concepts used throughout this book, and any book on programming, are actually metaphors. We get so used to the metaphors we forget that they are metaphors. You are used to talking about a window on your program, but of course there is no such thing; there is just a rectangle with text and images in it. It looks like a window into your document so we call it a window. Of course, you don’t actually have a document either, just bits in memory. No folders, no buttons, these are all just metaphors.

There are many levels to these metaphors. The window metaphor is enhanced by an image drawn on your monitor. That image is created by lighting tiny dots on the screen, called pixels. These pixels are lit in response to instructions written in your VB.NET program. Each VB.NET instruction is really a metaphor; the actual instructions read by your computer are in assembly language, low-level instructions that are fed to the underlying computer chip. These assembly instructions map to a series of 1s and 0s that the chip understands. Of course, the 1s and 0s are just metaphors for electricity in wires. When two wires meet, we measure the amount of electricity and if there is a threshold amount we call it 1, otherwise 0. You get the idea.

Good metaphors can be very powerful. The art of object-oriented programming is really the art of conceiving of good metaphors.

Creating Models

Humans are model-builders. We create models of the world to manage complexity and to help us understand problems we’re trying to solve. You see models all the time. Maps are models of roadways. Globes are models of the Earth. Chemical symbols are models of chemical interactions. Atomic models are representations of the interaction of sub-atomic particles.

Models are simplifications. There is little point to a model that is as complex as the object in the problem domain. If you had a map of the United States that had every rock, blade of grass, and bit of dirt in the entire country, the map would have to be as big as the country itself.^[5] Your road atlas of the U.S. eschews all sorts of irrelevant detail, focusing only on those aspects of the problem domain (e.g., the country’s roads) that are important to solving the problem (e.g., getting from one place to another). If you want to drive from Boston to New York City, you don’t care where the trees are; you care where the exits and interchanges are located. Therefore, the network of roads is what appears on the atlas.

Albert Einstein once said, “Things should be made as simple as possible, but not any simpler.” A model must be faithful to those aspects of the problem domain that are relevant. For example, a road map must provide accurate relative distances. The distance from Boston to New York must be proportional to the actual driving distance. If one inch represents 25 miles at the start of the trip, it must represent 25 miles throughout the trip, or the map will be unusable.

A good object-oriented design is an accurate model of the problem you are trying to solve. Your design choices will influence not only how you solve the problem, but in fact they will influence how you think about the problem. A good design, like a good model, allows you to examine the relevant details of the problem without confusion.

---

^[5] To borrow a joke from comedian Steven Wright: “I have a map of the world. One inch equals one inch. I live at E5.”