M250 Unit 1 Subsection 3 - Object Technology (2)

We continue with the gentle introduction that is unit 1.

Transcript

1. M250 Unit 1 Subsection 3 Object technology
2. Because computer programmes can grow to be so large it is important that they are organised well, as users need to be able to comprehend them easily. Object-oriented programming is one approach to doing this. First we’ll look at the approach that came before this: procedural programming, which was once the main way of writing and structuring code.
3. Procedural programming In procedural programming a problem is solved in a top-down manner. That is, very procedurally. A main procedure (a) will execute which might lead to another procedure (b) running which might lead to another procedure (c). Often all of these procedures have access to the data of the program. This data can be seen as central to the procedures that operate on it. We say this data is global. As such each procedure can potentially alter the global data. The limitations of this approach is that if one procedure alters the global data, then other procedures that operate on this data might behave differently than expected. Thus there is a lot of tweaking required when writing procedurally.
4. Object-oriented programming (OOP) In OOP we simplify the complexity of an entire program by using collections of communicating objects. A software object (or just object when used in a programming context) can be described as: ‘An entity which contains both data and behaviour.’
5. A software object often models a real-life object that we can see. For example a car, a pen, a guitar. This part of the real-world that objects simulate is called the application domain. That is, we create software objects to represent an entity in the real world as part of an application domain.
6. Objects can communicate with other objects. This is done by them sending messages to each other. When an object sends a message it may also get a response back from the object it sent the message to. This response is called a message answer.
7. As said, all objects have data and behaviour. So let’s look at these.
8. Data Firstly, let’s recognise that objects have attributes. Attributes are the characteristics of an object. These attributes have attribute values. For example, let’s say we have an object modelling a door. Its attributes could be its height, width, the type of wood it’s made from, and whether it’s open or closed. The values of these attributes could be 2 metres, 0.7 metres, oak, and closed, respectively.
9. Data / State The collection of all the attribute values that an object has is known as its state. Since the state contains all the values held by the object, we can also think of the state as the data held by the object. They are one and the same. For example, the state of a dice object could simply be the value of its one attribute, ‘which side did it land on’. This value could be 1,2,3,4,5 or 6. Hence the data contained by the object, or its state, is this attribute set to whichever one of the six values it is currently set to.
10. Behaviour As mentioned, objects understand certain messages. The messages that an object understands is defined in its code. In fact, the only way to make an object do something is to send it a message. Hence the behaviour of an object is its response to receiving a message. What does it do?
11. For example, let’s say our software object models a door again. This door object could receive a message telling it to open. It might be receiving this message from a human object that wants to enter the room. So the door’s behaviour in response to this message would be to change its ‘open/closed’ attribute to ‘open’. (That is, unless the door was already open. Then the object would have nothing to change and hence would do nothing – which is still a behaviour.)
12. Behaviour / Protocol The list of messages that an object understands is called its protocol. So if we tried to send an object a message that wasn’t in its protocol, it wouldn’t know what to do because it hasn’t been defined for it. This would in fact cause the compiler to return an error message.
13. Collaboration Objects often need to collaborate to get work done, which they do by sending messages to each other. Importantly, an object doesn’t need to know how another object is coded to behave when it is sent a message. It just needs to know what this behaviour results in. E.g. The human object just needs to know that the door object will open when sent a message telling it to open. It does not need to understand the intricacies of how the hinge works, or how the handle turns.
14. The benefits of OOP Since each object contains data (in the form of attribute values) each object is responsible for maintaining its own data. This overcomes the limitation of procedural programming, where data was global.
15. Identifiers We use identifiers to name certain things in Java, attributes being one of them. So in our door example we said one attribute was the ‘type of wood it was made from’, and other was whether it was ‘open or closed’. However, in Java identifiers must all be one word. By convention they also start with a lowercase letter. Ideally they are descriptive of what they represent too. We use an identifier naming convention called camelCase, where each word after the first is capitalised (but strictly not the first). So our door object might have an attribute with the identifier typeOfWood, or materialMadeFrom. Another attribute might simply be open, which can be set to true if the door is open or false if it isn’t.