Chapter 6 Object Concepts Prepared by: M206 Team - Kuwait Branch

Team Work - Kuwait Branch Objectives Familiarizing with terms that mostly used in OOP such as objects, classes, messages, attributes, …etc. Introducing some of the OOP principles such as polymorphism and inheritance. Team Work - Kuwait Branch

Philosophy and advantages of the OOP approach Design based on real-world models, not ‘ones and zeroes’. Objects are easy to communicate about to end-users. OOP increases developer productivity Component based architecture is reusable, compatible, extensible, maintainable, and understandable. Leads to quick development and easier testing. Team Work - Kuwait Branch

Team Work - Kuwait Branch Objects An Object is a computer representation of some real-world thing (i.e. person, place) or event. Real-world objects share two characteristics, they all have state and behavior. State  stores data. Behavior  operations/manipulations of the state data, or in general it is an object’s response when it receive a message. For example, bicycles have: State such as: current gear, two wheels, number of gears, ..etc. Behavior such as: braking, accelerating, slowing down, changing gears, ..etc. Team Work - Kuwait Branch

Team Work - Kuwait Branch Objects When an object is mapped into software representation, it has too both state and behavior. A software object maintains its state in one or more attributes. A software object implements its behavior with methods (messages can understand). Team Work - Kuwait Branch

Team Work - Kuwait Branch Messages A single object alone is generally not very useful. Instead, an object usually appears as a component of a larger program or application that contains many other objects. Software objects interact and communicate with each other by sending messages to each other. When object A wants object B to perform one of B's methods, object A sends a message to object B. Sometimes, the receiving object needs more information so that it knows exactly what to do, this information is passed along with the message as arguments (parameters). Team Work - Kuwait Branch

Team Work - Kuwait Branch Messages Example: This figure shows the three components that comprise a message: The receiver object to which the message is addressed (YourBicycle). The name of the method to perform (changeGears). Any parameters needed by the method (lowerGear). These three components are enough information for the receiving object to perform the desired method. No other information or context is required. Team Work - Kuwait Branch

Team Work - Kuwait Branch Attributes and state An attribute is a piece of information or property (data) needed by the object to define its state and hence to provide its behaviors. The information that an object holds (by its attributes) at any time describe its state. For example, a frog object may have been given the attributes colour and position; its state is described by the values of these attributes, perhaps Green and 3. Team Work - Kuwait Branch

Team Work - Kuwait Branch Attributes and state Here you have to go and work with LB-06. You can explore the object concepts that being discussed. The objects are considered to belong to an Amphibian world of frogs, toads, and hoverFrogs. Team Work - Kuwait Branch

Sending messages In order to make an object do something, we need to send a message to it, and hence an object needs a name to refer it by. And in this case we call it the receiver. In the M206 LearningWork Smalltalk Environment we have two way to send messages to objects: Either through a graphical interface Or through a text-based interface 1.By selecting the object (the receiver) from the objects item-list. 2.Then choose which message you want to send to it by clicking on the button specified for this message. By typing the required message in the text pane. Team Work - Kuwait Branch

Team Work - Kuwait Branch Sending messages Team Work - Kuwait Branch

Grouping objects into classes In the real world, you often have many objects of the same kind. For example, your bicycle is just one of many bicycles in the world. Using object-oriented terminology, we say that your bicycle object is an instance of the class of objects known as Bicycles. Bicycles have some attributes (current gear, current cadence, two wheels) and behavior (change gears, brake) in common. However, each bicycle's state is independent of and can be different from that of other bicycles. When building bicycles, manufacturers take advantage of the fact that bicycles share characteristics, building many bicycles from the same prototype (blueprint). It would be very inefficient to produce a new prototype for every individual bicycle manufactured. Don’t reinvent the wheel. Team Work - Kuwait Branch

Grouping objects into classes Objects belonging to the same class are called instances of the class. They have the same attributes. They respond to the same set of messages. They respond in the same way to each message. For example: frog1 and frog2 are both instances of class Frog. They have the same attributes (colour and position). They respond to the same set of messages (left, right, green, brown, and home). They have same graphical representation as they respond to each message in the same way. Team Work - Kuwait Branch

Grouping messages into a protocol Objects can only respond to the limited set of messages they have been set up to understand. The list of messages to which any instance of the class can respond is called the protocol for the objects. In our example: the protocol for a Frog object is left, right, home, brown, green and jump. Team Work - Kuwait Branch

Changing the state of the object The only way that the state of the Frog object can be changed is by sending it a message. The value of the attribute colour can be set to Green or Brown. The value of the attribute position can only be an integer number (from 1 to 11). Not all messages to objects change the state of an object. Some messages request an object to carry out an action without altering its state. Example: frog1 jump Frog objects only have the attributes colour and position. There is no attribute such as height. So the values of position and colour remain unchanged after a Frog object has responded to the message jump. Hence its state will not change. Also messages that query an object’s state (i.e. request the value of a particular attribute to be made known), such messages do not change the state of the receiver. Team Work - Kuwait Branch

Inspecting state using an inspector Inspector is a tool in the LearningWorks Environment, used to ascertain the attributes an object has been given and also to find out the value of each attribute. Example: inspecting frog1 displays a text description of frog1 such as ‘An instance of class Frog (position 1, colour Green)’. Team Work - Kuwait Branch

Initial state of an object All instances of a particular class are initialized identically. So identical initial states is an additional property of objects that belong to the same class. See the example (2 frogs and a toad). The Toad object icon has a different colour and in a different position from the Frog object icons. The Toad and Frog objects are initialized differently, that is, their states are different when they are newly created, simply because they belong to two different classes. Team Work - Kuwait Branch

Objects of different classes Instances of the same class are created from the same template. They are initialized identically. They have the same attributes and protocol. They exhibit identical behavior in response to the same message. This isn’t applied for objects of different classes. Frog and Toad objects belong to different classes. Each sort of object has a different initialization. Responds differently to some messages (home, left and right). Team Work - Kuwait Branch

Classes and writing software Class advantages Enables the program to be written in a concise way. All the class’s objects have the same set of attributes and protocol, and respond to their protocol in the same way. Saves effort If any part of the protocol needs to be changed, the change made only once- to the class itself. Team Work - Kuwait Branch

Team Work - Kuwait Branch Polymorphism One of the main and most useful features in OOP, the word means ‘many shapes’. Polymorphism allows us to write a generic method that correctly processes lots of different types of classes (all within a class hierarchy), so that: Different objects interpret and hence respond to the same message in a different way. Any message to which objects of more than one class can respond is said to be polymorphic. For example: In a word processor, It might be helpful if the user could double the size of items such as characters, words, pictures and paragraphs by using one such key. All these objects understand the message doubleSize, but apply it differently! Team Work - Kuwait Branch

Team Work - Kuwait Branch Polymorphism Examples reflecting its advantages: The Frog and Toad example: They are objects of different type of classes (both in the same class hierarchy). They share the same buttons, but have different response. Such messages (left, right, and home) are said to be polymorphic. Team Work - Kuwait Branch

State-dependent behavior The way that an object responds to a message depend on two things: Mainly, it depends on the object class. Also, it may depend on the object state. In such a case we call it a state-dependent behavior. Example: The case of the HoverFrog object, It’s height attribute can go between 0-6. So any up or down message to a HoverFrog object that attempted to set the value of height beyond these limits left the value unchanged. Team Work - Kuwait Branch

Team Work - Kuwait Branch Inheritance Just as inheritance in real life is ‘what you get from your parents’. In OOP, inheritance is ‘what you get from your parent class’, including the attributes and the messages of the class that is inherited from, and hence becomes a subclass of it. Team Work - Kuwait Branch

Team Work - Kuwait Branch Subclasses The terms superclass and subclass are used extensively within OOP. Superclass: Is a parent or a base class. Superclass wrongly suggests that the parent class has more functionality than the subclass. Generally a subclass is a more specialized form of the superclass. Subclass: Is a child class that inherits from, or extends, a superclass. Example: HoverFrog class is a subclass of the Frog class, and the Frog class is the superclass of the HoverFrog. Team Work - Kuwait Branch

Team Work - Kuwait Branch Subclasses The relationship between the Frog (super) and HoverFrog (sub) classes is summarized as follow: The protocol of HoverFrog objects includes that of Frog objects. HoverFrog and Frog objects respond in the same way to the same messages. (But it is possible that they don’t.) Instances of the HoverFrog class have the attributes of instances of the Frog class. HoverFrog objects have an additional attribute (height) There are messages in the protocol of HoverFrog objects that are not in the protocol of Frog objects (up, down, hover: by:). In both classes, the common attributes of the instances are initialized in an identical manner. But still the subclass may have different initialization than the superclass, because it may have extra attributes. Team Work - Kuwait Branch

The importance of inheritance and class/subclass relationship in OOP No need start from scratch! If your new class has common attributes and behaviors with an already existing one, it should inherit it and add its extra features. Saving time and effort. Reducing errors and ensuring a good quality. Team Work - Kuwait Branch

Keyword messages and arguments Keywords messages are messages that need arguments in order to include information. A keyword message contains one or more keywords and a single argument is associated with each keyword. In the graphical interface representation of the Amphibian world in the LearningWork, some buttons have labels containing …. Theses buttons indicate that some information is required from the user. Often a menu will be presented when any of them is selected. And an item must be chosen from the menu before the message triggered by the button can be sent. This item (value) is called the message argument. The textual representation of such menu button is as follow: The button ‘label’, followed by a colon (:), followed by any of the items ‘value’ listed in the menu. The colon acts as a textual prompt for the argument. Team Work - Kuwait Branch

Keyword messages and arguments Example: Frog and HoverFrog example. Look at the colour… menu button: This button corresponds to a keyword message colour: that requires an argument. The argument will be assigned from the different colour values (Blue, Brown, Green, Purple, Red, and Yellow) listed in the menu associated with the button. The textual representation of such a button could be one of the following: colour: Red colour: Green colour: Purple … Team Work - Kuwait Branch

Keyword messages and arguments Team Work - Kuwait Branch

Team Work - Kuwait Branch Message selectors colour: isn’t a message until an argument is provided. Selector is the word given to the name of a message. Hence, messages consist of a message selector, and zero or more arguments. The message selector for the message left is just left. The message selector for the message colour: Purple is colour: The protocol of a certain class is given in terms of the message selectors. For example, the protocol of HoverFrog is left, right, home, green, brown, jump, colour:, and hover:by: Team Work - Kuwait Branch

More than one argument messages An example of a message with two arguments is the hover message used in the HoverFrog class to make a HoverFrog object hover. To represent in textual form a message asking hoverFrog1 to move up two ‘steps’, you need to type the following line. In this example: The message itself is hover: Up by: 2 And the message selector is hover:by: Team Work - Kuwait Branch

More than one argument messages Team Work - Kuwait Branch

More than one argument messages The message argument always refers to an object. For example: In the message colour: Red, the argument Red refers to an object (belonging to the class ColorValue). In the message sameColourAs: frog1, the argument is the object frog1 that is an instance of the Frog class. Team Work - Kuwait Branch

Enquiry messages and message answers When a message is sent to a receiving object, an answer is always returned. A message answer is sometimes called a message reply. Message answer is an object. Example: Refer to the two message selectors colour: and colour and evaluate each of them. Team Work - Kuwait Branch

Enquiry messages and message answers The message selector colour: changes the state of the receiver object. In sending the message colour: Red to a Frog object, you request the receiver to set its attribute colour to Red. Although you are not requesting an answer, the message answer object is the Frog object itself in the state after responding to the message. However The message selector colour obtains information about its state. In sending this message, you ask the Frog object for the value of its colour attribute. The value of an attribute is a reference to an object. So the message answer is an object; in this case a reference to a colour object such as Red. Team Work - Kuwait Branch

Enquiry messages and message answers The pervious example shows that: The message answer from the message selector colour is useful and used in further processing. While the message answer from the message selector colour: is just ignored (it is the object frog after changing its colour). So why it is a must for every message to have a message answer although a message answer may or may not be used? Simply, to make the system uniform, consistent, and easy to use. Team Work - Kuwait Branch

Enquiry messages and message answers It is usual for a message and an attribute to have the same name. In the Frog class there is the message colour and the attribute colour; also the message position and the attribute position. Also it is usual that for each class to have both getter and setter messages. Getter message: a message that returns the value of an attribute  its answer is required and used for processing. E.g. frog1 colour, would answer with the value of the attribute colour (Green, Brown,..). Setter message: a message that is used to set the value of an attribute  its answer is ignored (usually displayed, but not used for processing). E.g. frog1 colour: Red, would cause the setting of the attribute colour of frog1 to be changed to Red. Team Work - Kuwait Branch

Collaborating objects Objects send messages to each others to get some required information. Suitable message answer object may be used subsequently as the receiver or argument of another message. Check the following message: frog6 sameColourAs: frog8 The two Frog objects will collaborate to get the answer of this message. Team Work - Kuwait Branch

Collaborating objects Check the following sequence (object-interaction) diagram. Team Work - Kuwait Branch

Collaborating objects Evaluating the previous message follows the following sequences: The user sends the message sameColourAs: frog8 to frog6. frog6 sends the message colour to frog8. frog8 returns as message answer the value of its attribute colour (the object Purple) to frog6. Finally, frog6 sends itself the message colour: Purple, where the argument Purble is the message answer object from the previous message. Team Work - Kuwait Branch

Team Work - Kuwait Branch Messages overview Messages may do any of the following: Team Work - Kuwait Branch

Domain models and user interfaces In any piece of software constructed using objects, the software can be divided into: The user interface (you have used two sorts of user interface in the LearningBook, a graphical interface and a text interface.). And ‘everything else’ which is referred to as the domain model (the underlying software objects, including its messages, protocols, states, …etc.). Separable user interfaces principle: User interfaces are separated from the domain model (the actual working part of the application) and it is independent of it. Advantages: Changing the interface will not affect the underlying domain model (the objects and the protocols). Team Work - Kuwait Branch

Things You Should Do Yourselves Read chapter 6 from the first block. Read the Glossary of the chapter, it summarizes the most important terms and techniques included in the written materials. Read the review of the chapter on page 24, it is very useful. Solve the exercises and review questions all along your way. Work on LB-06. Team Work - Kuwait Branch