OOPS PROGRAMMING TECHNIQUES

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

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. 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 place to place). 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 influence not only how you solve the problem, but in fact they 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

Classes and Objects:

The most important metaphors in object-oriented programming are the class and the object.

A class defines a new type of thing. The class defines the common characteristics of every object of that new type. For example, you might define a class Car. Every car will share certain characteristics (wheels, brake, accelerator, and so forth). Your car and my car both belong to the class of Cars; they are of type Car.

An object is an individual instance of a class. Each individual car (your particular car, my particular car) is an instance of the class Car, and thus is an object. An object is just a thing.

We perceive the world to be composed of things. Look at your computer. You do not see various bits of plastic and glass amorphously merging with the surrounding environment. You naturally and inevitably see distinct things: a computer, a keyboard, a monitor, speakers, pens, paper. Things.

More importantly, even before you decide to do it, you've categorized these things. You immediately classify the computer on your desk as a specific instance of a type of thing: this computer is one of the type computer. This pen is an instance of a more general type of thing, pens. It is so natural you can't avoid it, and yet the process is so subtle it's difficult to articulate. When I see my dog Milo, I can't help also seeing him as a dog, not just as an individual entity. Milo is an instance, Dog is a class.

The theory behind object-oriented programming is that for computer programs to accurately model the world, the programs should reflect this human tendency to think about individual things and types of things. In C# you do that by creating a class to define a type and creating an object to model a thing.

Defining a Class :

When you define a class you describe the characteristics and behavior of objects of that type. In C#, you describe characteristics with member fields.

class Dog

{

private int weight;  // member field

private String name; // member field

Member fields are used to hold each object's state. For example, the state of the Dog is defined by its current weight and name. The state of an Employee might be defined by (among other things) her current salary, management level, and performance rating.

You define the behavior of your new type with methods. Methods contain code to perform an action.

class Dog

{

private int weight;

private String name;

   public void bark()

   {

      // code here to bark
}
   

A class typically defines a number of methods to do the work of that class. A Dog class might contain methods for barking, eating, napping, and so forth. An Employee class might contain methods for adjusting salary, submitting annual reviews, and evaluating performance objectives.

Methods can manipulate the state of the object by changing the values in member fields, or a method could interact with other objects of its own type or with objects of other types. This interaction among objects is crucial to object-oriented programming.

For example, a Dog method might change the state of the Dog (e.g., weight), interact with other Dogs (e.g., bark and sniff), or interact with People (e.g., beg for food). A Product object might interact with a Customer object, and a Video object might interact with an EditingWindow object.

Designing a good C# program is not unlike forming a good team; you look for players — or objects, in the case of a program — with different skills to whom you can assign the various tasks you must accomplish. Those players cooperate with one another to get the job done.

In a good object-oriented program, you will design objects that represent things in your problem domain. You will then divide the work of the program among your objects, assigning responsibility to objects based on their ability.

Class Relations :

The heart of object-oriented design is establishing relationships among the classes. Classes interact and relate to one another in various ways.

The simplest interaction is when a method in one class is used to call a method in a second class. For example, the Manager class might have a method that calls the UpdateSalary method on an object of type Employee. We then say that the Manager class and the Employee class are associated. Association among classes simply means they interact.

Some complicated types are composed of other types. For example, an automobile might be composed of wheels, engine, transmission, and so forth. You might model this by creating a Wheel class, an Engine class, and a Transmission class. You could then create an Automobile class, and each automobile would have four instances of the Wheel class and one instance each of the Engine and Transmission class. Another way to view this relationship is to say that the Automobile class aggregates the Wheel, Engine, and Transmission classes.

This process of aggregation (or composition) allows you to build very complex classes from relatively simple classes. The .NET Framework provides a String class to handle text strings. You might create your own Address class out of five text strings (address line 1, address line 2, city, state, and zip). You might then create a second class, Employee, which has as one of its members an instance of Address.

related links:

VISUAL STUDIO INTRODUCTION

C SHARP INTRODUCTION

C SHARP OUT LOOK

DOT NET AND C SHARP

C SHARP APPLICATION STRICTURE

OOPS INTRODUCTION

OOPS AND C SHARP

IDE AND C SHARP

INSTANTIATING OBJECTS IN C SHARP

CLASSES AND OBJECTS IN C SHARP

OPERATORS IN C SHARP

SWITCH AND ITERATION IN C SHARP

BRANCHING IN C SHARP

CONSTANTS AND STRING

STATIC AND INSTANCE MEMBERS IN DOT NET