|
Java Tutorial |
ObjectOrientationThese pages make up the course notes for my Java programming course (run at Dallam, Milnthorpe, Cumbria). Hopefully they also make a useful self-learning tutorial. We have talked about Classes and Objects and in ClassesInDetail we looked at some standard classes available to us. However, before we get too much further we need to consider some more features of classes. In the 1990s Object Oriented programming became increasingly common as an approach to programming and Java is an Object Oriented programming language. Object Orientation represents a significant change of mind-set over earlier programming techniques. Up to now we have considered programs as lists of instructions for the computer to follow, in the same way that we may follow a recipe. Object Oriented programming encourages us to think about the Classes of Objects that make up the system. So instead of thinking about making a cup of coffee in terms of the ingredients and how we measure and mix them, we should be thinking about the objects involved in the process. I think there are three distinct classes of "object" involved in making coffee, there are vessels (the cup, the coffee jar, the kettle and may be the sugar bowl), measures (the teaspoon) and the sink (where we get water, wash-up and dispose of dregs). At first sight it may seem a bit odd to group cups, coffee jars and kettles as "vessels", but by doing this we may be able to apply some of the features of a vessel to all these things (such as empty, full, etc.) without duplicating the code. Also our simple recipe (put coffee in cup, add water, etc.) has no regard for where the coffee comes from, what if the coffee jar is empty, etc. The object oriented approach already has us thinking about these real world problems. At this point you may be thinking that Object Orientation is some overly abstract way of thinking about programming and that it may not be worth bothing with. However when we come to developing User Interfaces with Swing you will need to have some understanding of it. One of the drivers for the growth of object oriented programming was the increasingly common use of Graphical User Interfaces (i.e. Windows and mice rather than just a screen and the keyboard). Graphical User Interfaces allow users to do things in any order that seems natural to them, rather than in an order set by the computer programmer. In our coffee example I may want to add the milk before the hot water, but someone else may add the hot water before the milk. Inheritance We mentioned above that Cups, CoffeeJars and Kettles may all be thought of as types of vessels. The jargon for this is inheritance - Cups, CoffeeJars and Kettles inherit some features of a parent Vessel. We may be at risk of stretching the coffee recipe example too far, so let's consider telephones. There are a wide range of telephones: corded, cordless, mobile, etc. But they all share some features - such as a number, the ability to dial, the concept of on-hook or off-hook (engaged). So we could create a Telephone class that implements this functionality, and then specific types of phone would only need to implement the features specific to them (e.g. a mobile phone has a network provider, can send and receive SMS/text messages). here's what the Phone class might look like
public class Phone {
private String myNumber;
public String getMyNumber () {
//return the number of this phone
return myNumber;
}
public void setRemoteNumber(String numberToDial){
//set the number to dial
}
public void connect() {
//dial the number
}
public boolean isOffHook() {
//is the phone off the hook
}
}
here's what the MobilePhone class might look like
public class MobilePhone extends Phone {
public String getTextMessage () {
//read an SMS message
}
public void sendTextMessage(String text){
//send an SMS message
}
}
Notice that the MobilePhone class extends the Phone class. In this way we can use the public and protected methods of the Phone class from the MobilePhone class Polymorphism and Interfaces Polymorphism essentially means that one thing can also be seen as another. For example, my mobile phone can also act as a calculator. So sometimes it is a phone and other times it is a calculator. If we want to represent these things as a program, we need some way of saying that this MobilePhone can also be a Calculator. In Java we do this by implementing an Interface. An interface defines what methods a class must have to be a certain type of thing. For example my mobile phone must have Add, Subtract, Divide and Multiply methods to be a Calculator. Without these it is not a calculator. The interface itself does not actually implement any functionality it just specifies what is required by classes which implement that interface. Method Overloading Sometimes we may want to treat a variety of things in a similar way, even though they are different. Consider a zoo keeper; one of the zoo keeper's jobs is to feed animals. I want to just be able to tell the zookeeper to feed the lion or the penguin, and leave it up to the zoo keeper to decide what food to give. Object Orientation in Java allows us to have many methods of the same name as long as they take different arguments:
public class ZooKeeper {
public void feed ( Lion lion ) {
//feed it meat
}
public void feed ( Penguin penguin ) {
//feed it fish
}
public void feed ( Python python ) {
//feed it rodents
}
}
Now we can ask our zooKeeper object to feed a variety of animals without worrying about what the animals are. So if we had a list of animals of different types, we can just call zooKeeper.feed(animal). We do not have to find out what type of animal it is and then instruct the Encapsualtion Encapsulation is a term used in object oriented programming which basically means keeping related functionality in one class. The Notice that the Phone class had a method getMyNumber(). We could have made the class variable myNumber public and then anyone could access it rather than having the getMyNumber() method. However, suppose we wanted to change the way the phone number was stored internally - for example we might decide to split it into an area code and a local number - good encapulation ensures that we don't break any code which uses myNumber i.e. our getMyNumber() method could be changed as shown below without haviong to change any other code outside of the Phone class;
private String myLocalNumber;
private String myAreaCode;
public String getMyNumber () {
//return the number of this phone
return myAreaCode + " " + myLocalNumber;
}
This work is Copyright Chris Hunter 2007, you may use it for non-commercial purposes |
