Finished - onward and upward!

Having now finished Chunk 59 I am going to (hopefully) have a crack at Chunk 8. Unless anybody else has dibs on it.

Onwards and upwards.

My Finished Chunk 59

I have now finished my chunk and here it is.

If you have any suggestions/comments please feel free to post them.

---

An Introduction to Object Oriented Programming (OOP)

What is OOP?

Traditional programming languages, such as Pascal, COBOL, C and Visual Basic (amongst others) are procedural languages. In a procedural language you develop the code in a linear format, like a shopping list for example. You define your function and procedures in terms of (essentially) a list of instructions, building libraries of functions and procedures that perform specific tasks which allows you (the programmer) to modularise your code.

OOP uses a different paradigm and introduces a whole new plethora of terminology and we will only cover a few of these terms here. The three main terms we will become familiar with are class, method and message. However, we will also discuss properties, instances and inheritance. A few other terms will popup but will only be discussed in very basic detail.

OOP uses the concept of objects that describe “real world” things such as a person, an animal or a shape such as a square. It still employs procedures and functions but these are now called methods (more on this later). In procedural programming you have variables which allow for such things as counting and storage of data, in OOP these are now termed properties (again more on this later). When a function or procedure was called you would issue a command such as foo(some argument [,maybe some more arguments]). In OOP you achieve similar goals by issuing messages to the object.

When an object is created from a class (more shortly) you can pass messages to it, the object can perform calculations and pass messages back which can be processed by other objects. A properly programmed class will know (also known as anthropomorphism) about itself. For instance, a class created to store the details of a person may have the facility to answer how tall it is; i.e. it knows its own height (this is something of an oversimplification; the object has to be told its height in the first place – but I hope you get the gist)!

To interact with the object and call its functions and access it properties you use the objects interface. The interface defines all publicly accessible methods and properties of the class. As with procedural languages where you can create libraries of functions and procedures, you may also create libraries of classes that can be used in different programming projects.

Why would we use classes? Once a class is developed and tested it can be used in many different projects. OOP allows inheritance so if additional requirements are specified the class can be extended and new functionality added without modification to the original class. What does this achieve? Less bugs and a high reusability factor!

The purpose of this short tutorial is to explain various basic concepts of classes with no reference to actual code, be it Java or otherwise. Be rest assured that if you do not understand these terms already that they will be covered in greater detail shortly.

What is a Class?

When programming in OOP you begin by creating a description of the object, this is known as a class and this can be likened to a blueprint that describes everything about the object to be created and contains all the necessary functioning components (i.e. methods and properties) to make the object work. However, classes cannot be directly worked with and instances of the class (discussed later) need to be created.

A very simplistic example could be that of a cookie cutter (no OOP terminology here I really mean a real life cookie cutting implement!). The cookie cutter itself represents the class definition (the shape of a car, or animal, for example), and the resultant piece of cookie dough being an instance of the class. In one sense the act of cooking the dough could be considered a message and condition of the dough could be considered a property (cooked or uncooked); sending the message you are being cooked could change the property from uncooked to cooked!

The class definition can also be used to define and enforce business rules, or rules in general that apply. For instance, if you had a class defining a person, then a rule could be that the persons age must be greater than 0 (zero) or their gender must be male or female.

As previously mentioned a class has an interface. The interface describes how the class’s instances and method’s may be accessed. For instance (excuse the pun!), when creating the Person class you may well define a property which describes the date of birth of the person, dateofbirth, in addition you would define methods (described shortly) that allow the users of the class to both get and set the value of this property, for instance setDob and getDob. The setDob and getDob methods are part of the interface of the class.

Figure 1: Class defining a person

Figure 1 represents the relationship between a class and an object. The “blueprint” image to the left represents the class, which encapsulates all the properties and methods (the interface) of that class, and the figures to the right represent several objects created from the class.

Remember – you can create more than one object from a class.

The actual techniques used to implement classes are discussed in detail in Chunk 60 and 61.
What is a Method?

Methods are the means by which a class can perform tasks. A method is essentially the same as a function or procedure in a procedural language. However, depending on how the method is defined within the class it may or may not be a visible part of the interface (which is beyond the scope of this basic tutorial). Suffice to say that not all methods are accessible to the calling object.
For instance, given the above somewhat simplistic class defining a person, we have a setDob and getDob method which allows the date of birth of the person to be defined and accessed.

What about calculating the age of the person?

We could of course call the getDob method and calculate it manually, but what about a method to calculate and return the person’s age? We could create a method within the class that calculates and returns the person’s age. Perhaps call it getage(). When this method is called it simply calculates the age based on the system clock (or some other influence) and the date of birth stored within the object; passing the result back to the calling object.

One of the important advantages to remember about objects created from a class is that the methods are also created. They are not shared amongst all the objects; each object has its own copy. So for instance if two objects of type people are created and the getage() method is invoked it will return the value relevant to the object it is called upon.

There are exceptions to this rule but that is beyond the scope of this chunk. An in depth discussion of methods and their implementation can be found in Chunks 63 and 64.

What is a Message?

We have methods that are defined in our class and instantiated as part of an object. But how do we use these methods?

As stated previously methods are essentially the same as functions and procedures in procedural programming. However, whereas in procedural programming you would simply call the function/procedure with arguments (if any), in OOP you pass the object a message which may or may not contain arguments (obviously dependant on the definition of the method).

Essentially this is the same as procedural programming. Generally you would use the dot notation to pass the message; i.e. if you have a class named person, from which you have created an object named teamLeader, and a method called setDob which takes an argument of the form date then the calling message would be something like:

teamLeader.setDob(“27/10/1970”)

Objects can also return data to the calling object. Using the teamLeader example if we wanted to return the teamLeader’s age we would use a message of the form:

age = teamLeader.getAge()

Obviously the actual syntax involved would be language specific and this is only a very general description.

Having now covered three of the fundamentals of OOP, class, method and message, we will now move on to cover several other topics, namely properties, instances and inheritance.

Properties

Properties are very much akin to variables in traditional non OOP programming languages. A property can be likened to a “pigeon” hole in a snail-mail system; something is deposited in to the pigeon hole for later access and processing. That something could be a parcel, a letter or a memo for example. Parcel, letter and memo represent examples of different types of properties.
In computing terms properties can take the form of (for example) integers, characters and strings. There are many others to choose from and the type of property chosen obviously depends on the purpose of the property; you wouldn’t have a property that holds a name declared as an integer for instance, this would most likely be a string.

The various types that are available to define the type of property are beyond the scope of this short tutorial and I just want you to appreciate that there are different types to choose from and that careful thought should be given in choosing a type.

Generally speaking when defining a property in a class there would be (at least) two methods of accessing this property and this property would be declared as private (it can’t be seen outside of the class); there would be a get method for accessing the content of the property and a set method for assigning values to the property (these provide a public interface to a private property). Together the get and set methods are known as the accessor pair. This technique also allows you to enforce rules on what can (and can’t) be done with the property.

The syntax for creating properties and techniques involved in using them is covered elsewhere in this book.

Instances

Where we have a class that defines the object to BE created (remember we can’t work on a class directly), the term instance is used to describe the object once it has been created at runtime.

For instance, the simplistic class discussed above describes how the class is constructed in terms of attributes and methods but cannot be worked on directly. You have to create an instance of the class to work on; this is known as instantiation and gives us the object.
Inheritance

Inheritance can be a difficult topic to understand, and hopefully this very simple introduction will assist in clearing the mud from the waters.

The somewhat simplistic class introduced earlier has many attributes missing in relation to defining the properties of a person. For instance, what do ALL people share in common? One important thing would be that of gender; is the person a male or a female (there is a third option androgynous but let’s not go there!).

Admittedly this property would probably have been encapsulated within the Person class had it been properly designed, but for the sake of argument let’s assume it wasn’t a requirement of the original class structure.

The actual implementation details of inheritance are language specific; i.e. each language has its own method of achieving inheritance and I have no intention of detailing any specific method here.

When you as the programmer create a class that is based on another class you are said to inherit the properties and behaviours of the parent class and the class you create is known as a sub-class. This sub-class not only takes on all the functionality of the parent class, but can actually introduce additional properties and behaviour thus extending the class’ capability. Depending on how the parent class is defined it may even be possible to replace the methods (known as overriding) in the parent class (or extend them) in your child class.

So, given the Person class above we could create a sub-class that inherits from Person and maybe call it EnhancedPerson. In this sub-class we could then define a property to hold the gender of the person and create a matching pair of get and set methods to allow access to this property; maybe call them setGender() and getGender().

Can we inherit from multiple classes?

It is possible, with some languages, to perform multiple inheritance; inheriting from more than one class to create a sub-class. However, this tends to be frowned upon as implementation can be difficult and problematic, as can use of the class that has been created via multiple inheritance. I am not going to say anymore about this other than it exists.

What are the advantages of inheritance in OOP?

Code sharing, reduction in bugs in the code and reduced complexity to name some. If a class is sufficiently similar enough to an existing one, then inheritance allows the possibility of extension and modification (not directly – but by the child-class) to allow re-usability.

Assuming the base class has been thoroughly tested, you can be (almost) guaranteed a consistent behaviour, in that you will know what to expect of the called method.

Rapid Application Development (RAD) is another prime example of an advantage. Let’s say you develop software applications that have a similar theme and you seem to always be developing the same code over and over (say code to handle the details of a person). By creating a class that provides the necessary functionality, the code will have been developed and (hopefully) tested, and can be distributed to other programmers for their use, thus saving them development time and reducing development cost.

There are other valid advantages of OOP development but I hope this gives you an appreciation of OOP.

Because we have a taken a cursory glance at the positive sides of OOP, are their any negative aspects (I like playing Devil’s advocate!)?

Some do consider that execution speed of the program can take a hit when OOP techniques are used. In part due to the class specific code being more general purpose than the derived class’s code which is probably more specific and refined. However, using the OOP techniques (to reduce complexity) combined with optimisation techniques (to highlight bottlenecks in the code) can alleviate these concerns.

It is possible that applications developed using OOP may contain more lines of code than if they were developed using procedural techniques. However, due to the cheap (relatively speaking) nature of hardware and specifically RAM these days, application size is less important. Although I would like to add at this point that I still believe that developing tight code which uses less memory is very important. Otherwise we end up with what is commonly referred to as bloatware! In monetary terms though, development in OOP is more than likely a lot cheaper than development in a procedural language.

Overuse of inheritance can create a complex and highly daunting hierarchy of classes. The class structure can become so complex and cumbersome it can be difficult to see what derives from where and finding the relevant required class becomes very difficult.
More examples

To reinforce your understanding of the concepts explained above I would now like you to think about something that you understand that is not a computer program and how you would model this thing in OOP terms (my example will be a bread toaster). When you have a couple of ideas (you can use my own idea if you wish) of what you would like to model and what you think their properties and methods would be, come back and take a look at my example.

Carry on reading when you have thought about this some more.
This table represents my initial thoughts on what properties and methods (representing the interface) would be required to model a toaster in OOP. It may not be exhaustive or indeed accurate and would undoubtedly require additional design considerations before being implemented.

OOP Example

Toaster class:

Properties:

Temperature
Time before ejecting bread
Is bread inserted
Overheating
Turned on/off

Methods (Interface) :

Insert bread
Remove toast
Lower bread
Eject toast
Change temperature
Change ejection time
Switch toaster on/off
Is toaster overheating

Note: The names used above for the properties and methods are for illustration purposes only.

How did I come up with this list? Initially I sat and thought about how you use a toaster and the controls that are on a toasting machine. But there’s more to it than that. Toasters have sensors to (hopefully) prevent the toast from being burnt (after all who likes burnt toast?) and temperature control, etc.

So I figured for a (basic) toaster you need properties that represent when the toaster is turned on or off, its current temperature, is there any bread inserted, how long to cook the bread for before ejecting and whether the toaster is overheating. You may well think of some more but I feel that’s enough for illustrative purposes.

From an interface point of view I initially came up with the methods listed in the table above, you may well come up with some more. Again, thinking about how a toaster works (in the practical sense) provided an idea of potential methods. We would need methods to control the input and output of the toaster (Insert Bread, Eject toast, etc.) and methods to control the state of the toaster (Change temperature, Change ejection time, Is toaster overheating, etc.).

Try and come up with some other examples; for instance think about an ATM (cash machine) and what properties and methods that would require, or perhaps model a car thinking about what properties may be involved (for instance temperature, fuel level, etc.) and methods (accelerator pedal, break pedal, etc.).

Summary

Object Oriented Programming provides a rich and powerful way to develop software. It has many advantages over the traditional procedural methodology; it can also come at a cost if proper design and development is not adhered to.

Despite any negative aspects of OOP, it is a powerful method of software development and well worth learning. I hope this basic discussion has given you an insight into OOP which has convinced you that this is the way forward in software development. At least until the next major software development paradigm is discovered.

One last very important piece of advice on this topic – enjoy it!

My 2500 words

Right then - I have written my 2500 words but do not know whether it is of acceptable quality, over detailed or even under detailed and would appreciate some feedback.

Please ignore the graphic - my graphic designer friend is letting me down so I cobbled something together. I hope to improve it (or replace if he gets his act together), or failing that I will rewrite that small section and remove the image.

Please be kind.

---

An Introduction to Object Oriented Programming (OOP)

What is OOP?

Traditional programming languages, such as Pascal, COBOL, C and Visual Basic (amongst others) are procedural languages. In a procedural language you develop the code in a linear format, like a shopping list for example. You define your function and procedures in terms of (essentially) a list of instructions, building libraries of functions and procedures that perform specific tasks which allows you (the programmer) to modularise your code.

OOP uses a different paradigm and introduces a whole new plethora of terminology and we will only cover a few of these terms here. The three main terms we will become familiar with are class, method and message. However, we will also discuss properties, instances and inheritance. A few other terms will popup but will only be discussed in very basic detail.

OOP uses the concept of objects that describe “real world” things such as a person, an animal or a shape such as a square. It still employs procedures and functions but these are now called methods (more on this later). In procedural programming you have variables which allow for such things as counting and storage of data, in OOP these are now termed properties (again more on this later). When a function or procedure was called you would issue a command such as foo(some argument [,maybe some more arguments]). In OOP you achieve similar goals by issuing messages to the object.

When an object is created from a class (more shortly) you can pass messages to it, the object can perform calculations and pass messages back which can be processed by other objects. A properly programmed class will know (also known as anthropomorphism) about itself. For instance, a class created to store the details of a person may have the facility to answer how tall it is; i.e. it knows its own height (this is something of an oversimplification; the object has to be told its height in the first place – but I hope you get the gist)!

To interact with the object and call its functions and access it properties you use the objects interface. The interface defines all publicly accessible methods and properties of the class. As with procedural languages where you can create libraries of functions and procedures, you may also create libraries of classes that can be used in different programming projects.

Why would we use classes? Once a class is developed and tested it can be used in many different projects. OOP allows inheritance so if additional requirements are required the class can be extended and new functionality added without modification to the original class. What does this achieve? Less bugs and a high reusability factor!

The purpose of this short tutorial is to explain various basic concepts of classes with no reference to actual code, be it Java or otherwise.

What is a Class?

When programming in OOP you begin by creating a description of the object, this is known as a class and this can be likened to a blueprint that describes everything about the object to be created and contains all the necessary functioning components (i.e. methods and properties) to make the object work. However, classes cannot be directly worked with and instances of the class (discussed later) need to be created.

The class definition can also be used to define and enforce business rules, or rules in general that apply. For instance, if you had a class defining a person, then a rule could be that the persons age must be greater than 0 (zero) or their gender must be male or female.

As previously mentioned a class has an interface. The interface describes how the class’s instances and method’s may be accessed. For instance (excuse the pun!), when creating the Person class you may well define a property which describes the date of birth of the person, dateofbirth, in addition you would define methods (described shortly) that allow the users of the class to both get and set the value of this property, for instance setDob and getDob. The setDob and getDob methods are part of the interface of the class.

Figure 1 represents the relationship between a class and an object.

Figure 1: Class defining a person

The “blueprint” image to the left represents the class, which encapsulates all the properties and methods (the interface) of the class, and the image to the right represents an instantiation of the class, i.e. an object created from the class.

The actual techniques used to implement classes are discussed in detail in Chunk 60 and 61.

What is a Method?

Methods are the means by which a class can perform tasks. A method is essentially the same as a function or procedure in a procedural language. However, depending on how the method is defined within the class it may or may not be a visible part of the interface (which is beyond the scope of this basic tutorial). Suffice to say that not all methods are accessible to the calling object.
For instance, given the above somewhat simplistic class defining a person, we have a setDob and getDob method which allows the date of birth of the person to be defined and accessed.

What about calculating the age of the person?

We could of course call the getDob method and calculate it manually, but what about a method to calculate and return the person’s age? We could create a method within the class that calculates and returns the person’s age. Perhaps call it getage(). When this method is called it simply calculates the age based on the system clock (or some other influence) and the date of birth stored within the object. Passing the result back to the calling object.

One of the important advantages to remember about objects created from a class is that the methods are also created. They are not shared amongst all the objects; each object has its own copy. So for instance if two objects of type people are created and the getage() method is invoked it will return the value relevant to the object it is called upon.

There are exceptions to this rule but that is beyond the scope of this chunk. An in depth discussion of methods and their implementation can be found in Chunks 63 and 64.

What is a Message?

We have methods that are defined in our class and instantiated as part of an object. But how do we use these methods?

As stated previously methods are essentially the same as functions and procedures in procedural programming. However, whereas in procedural programming you would simply call the function/procedure with arguments (if any), in OOP you pass the object a message which may or may not contain arguments (obviously dependant on the definition of the method).

Essentially this is the same as procedural programming. Generally you would use the dot notation to pass the message; i.e. if you have a class named person, from which you have created an object named teamLeader, and a method called setDob which takes an argument of the form date then the calling message would be something like:

teamLeader.setDob(“27/10/1970”)

Objects can also return data to the calling object. Using the teamLeader example if we wanted to return the teamLeader’s age we would use a message of the form:

age = teamLeader.getAge()

Obviously the actual syntax involved would be language specific and this is only a very general description.

Having now covered three of the fundamentals of OOP, class, method and message, we will now move on to cover several other topics, namely properties, instances and inheritance.

Properties

Properties are very much akin to variables in traditional non OOP programming languages. A property can be likened to a “pigeon” hole in a snail-mail system; something is deposited in to the pigeon hole for later access and processing. That something could be a parcel, a letter or a memo for example. Parcel, letter and memo represent examples of different types of properties.
In computing terms properties can take the form of (for example) integers, characters and strings. There are many others to choose from and the type of property chosen obviously depends on the purpose of the property; you wouldn’t have a property that holds a name declared as an integer for instance, this would most likely be a string.

The various types that are available to define the type of property are beyond the scope of this short tutorial and I just want you to appreciate that there are different types to choose from and that careful thought should be given in choosing a type.

Generally speaking when defining a property in a class there would be (at least) two methods of accessing this property and this property would be declared as private (it can’t be seen outside of the class); there would be a get method for accessing the content of the property and a set method for assigning values to the property (these provide a public interface to a private property). Together the get and set methods are known as the accessor pair. This technique also allows you to enforce rules on what can (and can’t) be done with the property.

The syntax for creating properties and techniques involved in using them is covered elsewhere in this book.

Instances

Where we have a class that defines the object to BE created (remember we can’t work on a class directly), the term instance is used to describe the object once it has been created at runtime.

For instance, the simplistic class discussed above describes how the class is constructed in terms of attributes and methods but cannot be worked on directly. You have to create an instance of the class to work on; this is known as instantiation and gives us the object.
Inheritance

Inheritance can be a difficult topic to understand, and hopefully this very simple introduction will assist in clearing the mud from the waters.

The somewhat simplistic class introduced earlier has many attributes missing in relation to defining the properties of a person. For instance, what do ALL people share in common? One important thing would be that of gender; is the person a male or a female (there is a third option androgynous but let’s not go there!).

Admittedly this property would probably have been encapsulated within the Person class had it been properly designed, but for the sake of argument let’s assume it wasn’t a requirement of the original class structure.

The actual implementation details of inheritance are language specific; i.e. each language has its own method of achieving inheritance and I have no intention of detailing any specific method here.

When you as the programmer create a class that is based on another class you are said to inherit the properties and behaviours of the parent class and the class you create is known as a sub-class. This sub-class not only takes on all the functionality of the parent class, but can actually introduce additional properties and behaviour thus extending the class’ capability. Depending on how the parent class is defined it may even be possible to replace the methods (known as overriding) in the parent class (or extend them) in your child class.

So, given the Person class above we could create a sub-class that inherits from Person and maybe call it EnhancedPerson. In this sub-class we could then define a property to hold the gender of the person and create a matching pair of get and set methods to allow access to this property; maybe call them setGender() and getGender().

Can we inherit from multiple classes?

It is possible, with some languages, to perform multiple inheritance; inheriting from more than one class to create a sub-class. However, this tends to be frowned upon as implementation can be difficult and problematic, as can use of the class that has been created via multiple inheritance. I am not going to say anymore about this other than it exists.

What are the advantages of inheritance in OOP?

Code sharing, reduction in bugs in the code and reduced complexity to name some. If a class is sufficiently similar enough to a newly required one, then inheritance allows the possibility of extension and modification (not directly – but by the child-class) to allow re-usability.

Assuming the base class has been thoroughly tested, you can be (almost) guaranteed a consistent behaviour, in that you will know what to expect of the called method.

Rapid Application Development (RAD) is another prime example of an advantage. Let’s say you develop software applications that have a similar theme and you seem to always be developing the same code over and over (say code to handle the details of a person). By creating a class that provides the necessary functionality, the code will have been developed and (hopefully) tested, and can be distributed to other programmers for their use, thus saving them development time and reducing development cost.

There are other valid advantages of OOP development but I hope this gives you an appreciation of OOP.

Because we have a taken a cursory glance at the positive sides of OOP, are their any negative aspects (I like playing Devil’s advocate!)?

Some do consider that execution speed of the program can take a hit when OOP techniques are used. In part due to the class specific code being more general purpose than the derived class’s code which is probably more specific and refined. However, using the OOP techniques (to reduce complexity) combined with optimisation techniques (to highlight bottlenecks in the code) can alleviate these concerns.

It is possible that applications developed using OOP may contain more lines of code than if they were developed using procedural techniques. However, due to the cheap (relatively speaking) nature of hardware and specifically RAM these days, application size is less important. Although I would like to add at this point that I still believe that developing tight code which uses less memory is very important. Otherwise we end up with what is commonly referred to as bloatware! In monetary terms though, development in OOP is more than likely a lot cheaper than development in a procedural language.

Overuse of inheritance can create a complex and highly daunting hierarchy of classes. The class structure can become so complex and cumbersome it can be difficult to see what derives from where and finding the relevant required class becomes very difficult.

Summary

Object Oriented Programming provides a rich and powerful way to develop software. It has many advantages over the traditional procedural methodology; it can also come at a cost if proper design and development is not adhered to.

Despite any negative aspects of OOP, it is a powerful method of software development and well worth learning. I hope this basic discussion has given you an insight into OOP which has convinced you that this is the way forward in software development. At least until the next major software development paradigm is discovered.

One last very important piece of advice on this topic – enjoy it!

My First 1200(ish) words...

OK - Here is my first 1200(ish) words. Please ignore the graphic (figure 1), it is obviously wrong. I am waiting on my graphic designer friend/colleague to draw me something here.

Please feel free to be critical of the content.

------------------------------------------------------------------------------------

An Introduction to Object Oriented Programming (OOP)

What is OOP?

Traditional programming languages, such as Pascal, COBOL, C and Visual Basic (amongst others) are procedural languages. In a procedural language you develop the code in a linear format, like a shopping list for example. You define your function and procedures in terms of (essentially) a list of instructions, building libraries of functions and procedures that perform specific tasks which allows you (the programmer) to modularise your code. Thus providing the facilities to create libraries of functions for reuse.

OOP uses a different paradigm and introduces a whole new plethora of terminology and we will only cover a few of these terms here. The three main terms we will become familiar with are class, method and message. However, we will also discuss properties, instances and inheritance. A few other terms will popup but will only be discussed in very basic detail.

OOP uses the concept of objects that describe “real world” things such as a person, an animal or a shape such as a square. It still employs procedures and functions but these are now called methods (more on this later). In procedural programming you have variables which allow for such things as counting, in OOP these are now termed properties (again more on this later). When a function or procedure was called you would issue a command such as foo(some argument [,maybe some more arguments]). In OOP you achieve similar goals by issuing messages to the object.

When an object is created from a class (more shortly) you can pass messages to it, the object can perform calculations and pass messages back which can be processed by other objects. A properly programmed class will know (also known as anthropomorphism) about itself. For instance, a class created to store the details of a person may have the facility to answer how tall it is; i.e. it knows its own height!

To interact with the object and call its functions and access it properties you use the objects interface. The interface defines all publicly accessible methods and properties of the class. As with procedural languages where you can create libraries of functions and procedures, you may also create libraries of classes that can be used in different programming projects.

Why would we use classes? Once a class is developed and tested it can be used in many different projects. OOP allows inheritance so if additional requirements are required the class can be extended and new functionality added without modification to the original class. What does this achieve? Less bugs and a high reusability factor!

The purpose of this short tutorial is to explain various basic concepts of classes with no reference to actual code, be it Java or otherwise.

What is a Class?

When programming in OOP you begin by creating a description of the object, this is known as a class and this can be likened to a blueprint that describes everything about the object to be created and contains all the necessary functioning components (i.e. methods and properties) to make the object work. However, classes cannot be directly worked with and instances of the class (discussed later) need to be created.

The class definition can also be used to define and enforce business rules, or rules in general that apply. For instance, if you had a class defining a person, then a rule could be that the persons age must be greater than zero or their gender must be male or female.

As previously mentioned a class has an interface. The interface describes how the class’s instances and method’s may be accessed. For instance (excuse the pun!), when creating the Person class you may well define a property which describes the date of birth of the person, dateofbirth, in addition you would define methods (described shortly) that allow the users of the class to both get and set the value of this property, for instance setDob and getDob. The setDob and getDob methods are part of the interface of the class.

Figure 1 represents the relationship between a class and an object.

Figure 1: Class defining a person

The “blueprint” image to the left represents the class, which encapsulates all the properties and methods (the interface) to class, and the image to the right represents an instantiation of the class, i.e. an object created from the class.

What is a Method?

Methods are the means by which a class can perform tasks. A method is essentially the same as a function or procedure in a procedural language. However, depending on how the method is defined within the class may or may not be a visible part of the interface (which is beyond the scope of this basic tutorial).

For instance, given the above somewhat simplistic class defining a person, we have a setDob and getDob method which allows the date of birth of the person to be defined and accessed. But what about a method allowing you to access the person to age instead of simply retrieving their date of birth?

We could of course call the getDob method and calculate it manually, but what about a method to return the person’s age? We could create a method within the class that calculates and returns the person’s age. Perhaps call it getage(). When this method is called it simply calculates the age based on the system clock and the date of birth stored within the object.

One of the important advantages to remember about objects created from a class is that the methods are also created. They are not shared amongst all the objects; each object has its own copy. So for instance if two objects of type people are created and the getage method is invoked it will return the value relevant to the object it is called upon.

There are exceptions to this rule but that is beyond the scope of this tutorial.

What is a Message?

We have methods that are defined in our class and instantiated as part of an object. But how do we use these methods?

As stated previously methods are essentially the same as functions and procedures in procedural programming. However, whereas in procedural programming you would simply call the function/procedure with arguments (if any), in OOP you pass the object a message which may or may not contain arguments (obviously dependant on the definition of the method).

Essentially this is the same as procedural programming. Generally you would use the dot notation to pass the message; i.e. if you have a class named person, from which you have created an object named teamLeader, and a method called setDob which takes an argument of the form date then the calling message would be something like:

teamLeader.setDob(“27/10/1970”)

Objects can also return data to the call object. Using the teamLeader example if we wanted to return the teamLeader’s age we would use a message of the form:

age = teamLeader.getAge()

Obviously the actual syntax involved would be language specific and this is only a very general description.

Having now covered three of the fundamentals of OOP, class, method and message, we will now move on to cover several other topics, namely properties, instances and inheritance.

At last...

Yay!!!

I have finally had an email off Waterstones to say my book has been dispatched.

Should hopefully have it then by end of the week.

My First 500(ish) Words - Please be kind!!

OK - Here are my first 500(ish) words for Chunk 59.

I would appreciate it if everyone could take a look and be constructively critical of it.

-------------------------------------------------------------------------------------------------------

An Introduction to Object Oriented Programming (OOP)

What is OOP?

Traditional programming languages, such as Pascal, COBOL, C and Visual Basic (amongst others) are procedural languages. In a procedural language you develop the code in a linear format, like a shopping list for example. You define your function and procedures in terms of (essentially) a list of instructions, building libraries of functions and procedures that perform specific tasks which allows you (the programmer) to modularise your code. Thus providing the facilities to create libraries of functions for reuse.

OOP uses a different paradigm and introduces a whole new plethora of terminology and we will only cover a few of these terms here. The three main terms we will become familiar with are class, method and message. However, we will also discuss properties, instances and inheritance. A few other terms will popup but will only be discussed in very basic detail.

OOP uses the concept of objects that describe “real world” things such as a person, an animal or a shape such as a square. It still employs procedures and functions but these are now called methods (more on this later). In procedural programming you have variables which allow for such things as counting, in OOP these are now termed properties (again more on this later). When a function or procedure was called you would issue a command such as foo(some argument [,maybe some more arguments]). In OOP you achieve similar goals by issuing messages to the object.

When an object is created from a class (more shortly) you can pass messages to it, the object can perform calculations and pass messages back which can be processed by other objects. A properly programmed class will know (also known as anthropomorphism) about itself. For instance, a class created to store the details of a person may have the facility to answer how tall it is; i.e. it knows its own height!

To interact with the object and call its functions and access it properties you use the objects interface. The interface defines all publicly accessible methods and properties of the class. As with procedural languages where you can create libraries of functions and procedures, you may also create libraries of classes that can be used in different programming projects.

Why would we use classes? Once a class is developed and tested it can be used in many different projects. OOP allows inheritance so if additional requirements are required the class can be extended and new functionality added with modification to the original class. What does this achieve? Less bugs and a high reusability factor!

The purpose of this short tutorial is to explain various basic concepts of classes with no reference to actual code, be it Java or otherwise.

My book token has arrived - yay!

Tried to get the book from Waterstones - boo!

According to their website they have 4 copies on the shelves - none of which are near me. Their advice was to order on-line. Which I promptly did assuming that one of the stores would dispatch their copy to me.

What is it I hear you say about assumption? Something about it being the mother of all foul (clean version) ups.

Their web-site says they have placed an order with the publishers and a copy will be despatched ....... whenever they have it!!

Ah well, on wards and upwards.

At least I have written my first 500(ish) words and am currently editing it and will hopefully place it on the blog soon.

OK - so I went to try and get Ira's book today and they hadn't got it. Not a surprise.

So I asked if I could order it - "Um - currently unavailable" was the reply. "It should be available on the 29th October" she went on to say.

My mood lifted a little.

"But that isn't guaranteed" she added. Mood goes down a little further!!

Ah well. I shall continue attempting to get my hands on it and continue researching my chunk (which is 59 by the way).

My choice...I hope

Having mulled it over, over night I think I definitely would like to take on Chunk 59 for my part of the project.

I had to do a similar type of tutorial for a college course a few years ago and feel that this may play to my strengths.

Mass Writing Project

OK - Having been accepted on to Darrel Ince's Mass Writing project (23/10/08) I have been perusing the profiles of some of the other members (or actually I have looked at all the ones available), and am now thinking "Oh My God! What have I let myself in for?!".

I am already wondering whether I am in over my head. I hope not. I am really excited about this and want to do well in it.

So far I have downloaded the Processing software, albeit at work so I won't get much chance to tinker with it, but I will download it again at home this evening.

I have been looking at the various chunks and mulling over which one I fancy a crack at.
So far I am pondering the following (but leaning towards chunk 59):

CHUNK 76
TITLE Loading and tiling images
DESCRIPTION This is the start of the part of the book that deals with image manipulation. It shows you how load images and set and get the pixels in an image.

CHUNK 66
TITLE Shapes--an introduction
DESCRIPTION This part of the book introduces some of the 2D Processing shapes. Describe rectangle, ellipse, arc and triangle

CHUNK 59
TITLE An introduction to object-oriented programming
DESCRIPTION Make this an introduction, dont show the code for any classes, just get the student to understand there are objects and there are methods which correspond to messages. The BurritoRecipe class will be your inspiration; use a different example though.

CHUNK 16
TITLE Example 1
DESCRIPTION Describe a program that uses all the Java facilities that have been described in Greenberg 58--104; use no other facilities. Make it quite substantial, say around 100 lines of Java code. Present the full listing and then go through it section by section. Concentrate on the tough facilities in your description: while statements, functions, arguments in functions and brackets. Make the program visually exciting. This is one of four examples at this point in the book.

I am finding it difficult to choose prior to getting my hands on a copy of Greenbergs book and reviewing the relevant material.