Chapter 6. Object-Oriented Programming


Windows and web programs are enormously complex programs that 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 that relates to your 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 is filled with objects (things) from the problem domain. For example, if the problem domain is an Automatic Teller Machine for banking, the things (objects) in your domain might include customers, accounts, monthly statements , and so forth.

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 cares only about modeling those that are relevant to the problem domain. Thus, a customer object might be able to make a deposit, transfer funds, withdraw cash, 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. (The monthly-statement object should not know the customer's address, though it might ask the customer object for the customer address. This way, when the customer moves, the responsibility for knowing the new address is located in a single object: the customer .) This ability for an object to own responsibility for its own internal state and actions is known as encapsulation .

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 that we forget they are metaphors. You are used to talking about a window in 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 buttonsthese are all just metaphors.

There are many levels to these metaphors. When you see a window on the screen, the window metaphor is enhanced by an image drawn on your monitor. That image is created by lighting tiny dots, called pixels. These pixels are lit in response to instructions written in your C# program. Each C# instruction is itself a metaphor; there is just a series of 1s and 0s. 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 , we call it 0. Of course, electricity is a metaphor, as are electrons, as is quantum physics. You get the idea.

Good metaphors can be very powerful. The art of object-oriented programming is really the art of conceiving good metaphors to simplify solving complex problems.




Learning C# 2005
Learning C# 2005: Get Started with C# 2.0 and .NET Programming (2nd Edition)
ISBN: 0596102097
EAN: 2147483647
Year: 2004
Pages: 250

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net