Intro to Object Orientated Programming - The Basics of a Class

[PlausiblyDamp]

Guide to Object Orientated code in .Net

 

Introduction

This is intended as a guide on the features .Net provides in terms of Object Orientated Programming. This post will cover simple issues such as classes and structures as well as basic terminology used. Later articles will cover other areas such as interfaces and inheritance. Most of the code snippets are in VB.Net but C# will be shown if major differences occur and I will endeavour to include complete projects in both languages.

 

Within .Net everything is an object from the most complex classes you design to a simple Boolean or Integer value .Net treats everything the same. To really understand how to best take advantage of .Net getting to grips with the concepts of Object Orientated Design / Programming is a must.

 

The first difference when coming from a non-OO (Object Orientated) language is there is no longer a separation of Data Structures and Functions that operate on those structures, both concepts are merged into the idea of an object. This introduces two common terms found in nearly all OO literature Encapsulation and Abstraction.

 

Encapsulation is simply a term that means �hiding the implementation details�, if you wish to write useful code that can easily be used by either other developers or even yourself months from now you need to remove the requirement for the user to have intimate knowledge of the inner workings or have to depend on specific implementation details.

e.g. The .Net Framework provides a System.Date class, which provides date related functionality (Add dates and times, subtract Dates and times, convert between local and UTC times amongst others) to use this class you need no knowledge of how it implements this functionality � does it store dates as a single offset from an arbitrary point in time, as a string, as a series of integers? Does it internally use UTC or local time? The point is as a developer using this class you do not need to know � and more importantly do not need to care if it�s internal implementation changes in a later revision � the only important thing is the functionality exposed by the class doesn�t change between revisions.

 

 

Abstraction is the idea of taking a real world object or concept and simplifying it to the point where it is usable from a coding point of view i.e. has enough exposed functionality that it is usable, without being bogged down with irrelevant details. This can be a tricky part of the design process � getting enough functionality into a class without overloading it with irrelevant details.

 

Simple Example

To best illustrate these ideas let�s start with a simple class to model the familiar concept of a bank account.

At a bare minimum all bank accounts require the ability to retrieve the current balance, add money (not often enough) and subtract money (far too often) and have an associated account number.

In a non-OO language like C this would often involve a structure containing the data and several functions that act on this data e.g

Struct BankAccount
{
public int AccountNumber,
public float Balance
}

//stub function
void Credit(BankAccount acc, float Amount)
{
//credit code here
}

 

and though this system works it requires developers to 1) know there is functionality to perform Credits and Debits and 2) be bothered to use them. One major potential problem is that the data members of BankAccount can be accessed without using the provided functionality � any code could modify the balance and bypass any error trapping / validation the Credit / Debit methods provided.

 

A typical VB version of the above would look similar to

Public Class BankAccount

   Private _Balance As Decimal
   Private _AccountNumber As Integer

   Public Sub Credit(ByVal amount As Decimal)
       _Balance += amount
   End Sub

   Public Sub Debit(ByVal amount As Decimal)
       _Balance -= amount
   End Sub

   Public Function GetBalance() As Decimal
       Return _Balance
   End Function

End Class

 

Notice the account number is ignored for now (this will be useful later) and that both it and the _Balance variable are declared Private � this means they are not visible from anywhere outside the BankAccount class, but due to the fact they are declared within the class but outside of a particular function they have what is referred to as Class Scope and can be accessed by any function within this class. We have instantly removed one potential source of bugs � if you need to modify the balance you must do it via either the Credit or Debit Method (OO name for Function, Procedure or Subroutine) which are declared as Public and as such can be accessed anywhere (we will encounter other options in a later article). Although currently our versions are lacking in any validation or error trapping these methods cannot be bypassed, and if we chose to change how the _AccountNumber or _Balance were stored then only the exposed methods would need to be updated � as long as they returned the same data type and accepted the same parameters then no calling code would need be modified.

 

Playtime

I suggest having a quick look at the attached projects and stepping through the code in a debugger � try changing some of the routines and see which pieces of the BankAccount class are accessible from the form and which bits aren�t.

 

Next

Next article we will look at properties

BankCS.zip

BankVB.zip

Edited February 5, 2006 by PlausiblyDamp