Another basic programming question

[cismajor97]

I'm self teaching myself C# and ASP.NET 2.0 and I'm having a hard time grasping object oriented programming. Can someone explain to me the difference between, a field, property and method? I thought that fields and properties were the same but apparently they are not.

 

[maw]

In the simplest terms a property describes the object, a method acts upon the object. methods are also known as functions.

E.g. if you have a car object, the property color describes the color of the car, while the method start() gets the car to do something.

sorry, not sure how a field fits in with property and methods. Usually i think of fields in terms of databases or arrays.

 

[CefiroZ]

I'm not very fluent with C#, but here's an extremely brief intro to build on what maw said.

First of all, there is Object-Oriented and Object-Based programming. Object-Based is the beginning point, OO builds on it, so we'll begin with it.

An Object is a logical bundling of related data and functions. If you've done C-style structs, Objects are their more evolved descendents. Maw provided a good example of a candidate for a Class/Object, a car. Each car has certain characteristics (properties!) like tire type, color, engine, make, model, etc etc. and would have typical actions (methods!) like turning it on or changing a gear. So you could create many car objects and make them all unique (one a Honda Accord, another a Toyota Camry, etc etc), but also know that you have access to the same information and abilities with each object.

Data concerning the object is called a property and the functions are referred to as methods. Both properties and functions can be considered private or public (there are a few other options like protected but they're beyond the scope of this). The way you begin is writing a Class, an Object is created when you make an instance of the Class. Properties or methods marked private are only available within the code of the Class. Properties marked public can be changed/called from outside of the Class's code. Classes should have "constructors" written that create the objects when an instance of the class is created, sometimes "destructors" are needed depending how the class is written to clean up the object when it is deleted.

Here's some example code (my C# is shaky so it may not be 100% correct):

Class MyClass
{
  public:
    int foo ;

    MyClass( ) 
    // the constructor, it's called the empty constructor because it takes no parameters
    // if code is called like MyClass m ; the empty constructor is called
    // it can also take parameters, and you can have more than one
    // similar to how functions can be overloaded to handle different situations
    {
       reset( ) ;
    }
  
    void add( int adder )
    {  
       foo += adder ;
       bar += adder ;
     }

    void display( )
    { 
       // I forget the C# syntax for console output, used Java
       System.out.println( foo + " "+ bar ) ;
    }
  private:
    int bar ;
 
    void reset( )
    {
       foo = 1 ;
       bar = 2 ;
    }   
}


/* somewhere else in your code, perhaps main */
MyClass c ;  // calls the empty constructor
c.display( ) ;
c.add( 2 ) ;
c.display( ) ;
c.foo = 4 ;
c.display( ) ;

It would output:
1 2
3 4
4 4

Note that because foo and display() are marked as public, your main code can call them directly. The bar and reset() cannot be called by your main code. bar can only be changed within the code of the Class (in this example bar can only be modified by calling adder()) and reset can only be called within the class (like where it gets called in the constructor).

Most data in an Object is typically kept as private so no one else can muck things up if you need it a certain way. This is why "accessors" and "mutators" are typically provided as public methods. Accessors get data from the object and return it, mutators will modify data. As I said, this prevents someone from directly changing your data. The mutators can be written to take the desired information and change the class properties as needed. A completely contrived example would be you have data stored in a custom data structure that the user of your Class will not know. This could happen at a big company, you write the Class and someone else would be in charge of implementing code to use your Class. All they would be provided with is the public declarations of your methods (and properties if any are public). They would never see the implementation of these methods or even know what private properties/methods you have. If you let them directly mess with the Class's data (within your custom data structure) they will mess it up since they do not know how your structure works. But, providing mutators that tell what to change and what to change it to, allows you to write the code to properly do what they desire.

The move from OB to OO is the topic of inheritance. I can explain this to you if you like, but for now I'll leave that for you to look it up since it's a very meaty discussion. To give the basic idea I'll go back to the car example. What if you wanted to instance a truck of some sort? Your Car class couldn't handle it, because trucks have other information like towing capacity. A solution would be to create separate Vehicle, Car, and Truck classes. The Vehicle would be a "parent" of the other two and contain properties and methods that both would have (like engine, make, model, color, turn on, etc etc). The individual Car and Truck classes would inherit this common information from the Vehicle class and add whatever special things they need. This means when a Truck is created, it would (in the constructor) assign what it needs for its own data like towing capacity and then (still in the Truck constructor) would pass the rest of the common information up by calling the Vehicle constructor. In code, you could call anything from the Truck class that is available in the Vehicle class. Ex:

Truck t ; // creates a truck
t.turnOn( ) ; // turns on the truck, this could either be written in the Truck class if it does someting special OR if it is not implemented in the Truck class, would run Vehicle's turnOn method

This is super brief, but hopefully it gets you started. I or others can build on this more if you need more than that.