10. Objects – Part I

Howdy! Good to see you again. It’s time to delve a little deeper into the wonderful world of programming. So far, we’ve been studying the basics of procedural programming; programs that take the form of a set of structured functions, that call and are called by each other. Although still used, procedural programming has been largely superceded in recent decades, by Object-Oriented Programming.

Seeing The World As It Is

When we write a program, we create an intangible product; a set of instructions using a programming language, that results in a computer automatically manipulating data. When coding an app, the programmer’s approach mirrors that of the real world. For example, when coding a car racing video game, the programmer actually has to build cars using code.

In order to better represent real world physical elements within programs, the object-oriented programming paradigm emerged in the early 60s (no – that’s not a typo!). These real world elements, and new abstract elements such as a user login form, are known as objects.

It’s worth noting that not all programming languages support object-oriented programming. Common object-oriented languages include Java, Ruby, C++, Python, C#, Objective-C (which literally means object-oriented C) and Swift.

The Class – Mother Of Objects

Let’s take a closer look at our car racing game. In real life, an engineer tasked with designing a new car, will first create a blueprint; exact specifications that he will hand over to the people who will actually build the car.

In programming, a blueprint is called a class. Each time you see the word class, you can think of it as a blueprint or specifications. The concrete stuff that gets built by following the blueprint (in our case, a car) is called an object.

The engineer’s blueprint will contain all the properties of the car, such as the precise size of its wheels, the number of doors etc. Also included, will be a list of actions that the car can take. For example, “pressing button B123 will open the windows”, “turning the ignition key will start the car” and so on.

In object-oriented programming, a property is called …wait for it… a property! An action is called a method. Together, properties and methods are known as the class members.

Make One, Make Many

The car manufacturer, once in possession of the blueprint, can produce as many cars as it wants, based on that blueprint. Some properties such as the color of the car may change but every car that rolls off the production line will share the same origin: the blueprint.

In programming, we work the same way. Once we’ve created a class to represent the blueprint of an object – let’s say a monster in your awesome new game – you can create as many monsters as you want from that class. You can alter their properties (such as height, size of their teeth etc) when you build each monster.

With a class, you can create as many objects as you need and you can change their properties at will.

Object-oriented programming enforces the concept of reusability when writing programs.

There’s one key concept to emphasize here; a class is not an object. The blueprint of a car is not a car. You cannot drive a blueprint! You first need to build a car from the blueprint.

Your Own Data Types

Remember the basic data types such as integers and strings? Well, when we design a class intended to serve as the creator of an object, we are actually creating a new custom data type. We are instructing the computer that we won’t work only with its predefined data types, and that we now need Mr Computer to also manipulate our new customised data types!

To put this another way, the computer will not only know what an integer or a boolean is, it will also know what a car is. Pretty cool, huh?

Interconnecting Objects

The true power of objects is that they can interact with each other. An object can be comprised of several other objects. Back to our car; the vehicle itself is made of various components such as its motor, wheels, and doors. These components had to be designed before being built. That means there’s also a blueprint for each part. Typically, the blueprint for the entire car would reference another, more detailed blueprint for the motor.

The same is true for classes. A class used to describe a monster in a video game can reference other classes such as one for the monster’s weapon. Should you want to change the weapon from a sword to an axe, you would simply replace the class referencing the sword weapon to one referencing the axe weapon.

Another way objects can interact with each other is by passing messages from one to another. When your phone rings in your pocket, it is the GSM chip object that passes the message receiving a call to the ringer object. You use objects interaction daily: the tube of toothpaste object interacts with the toothbrush object. The coffee machine object fills your cup object.

Objects interact with each other in both the physical and in the software worlds. In the software world, since objects are intangible pieces of code, it is sometimes hard for the beginner to recognise and identify them as objects.

Setting Properties

In the car manufacturing process, when does the car receive its color? During the building process. Its the same for objects. A monster object will receive properties such as its size and color at the time it is being built. You can opt for default values to be set when an object is created from a class but you can also override these default values, in much the same way as you might choose the power steering option when building a car.

What Makes Objects Do Stuff?

Remember that a class has two kinds of members; properties and methods. We looked at properties above. Now lets take a look at methods, which are just as vital!

Take a cat, for example. It has properties such as a weight, a color, a gender and so on. It also has things it can do such as jump, walk, run, eat and sleep (the last two being very important in a cat’s life!). Jump, Walk, Run, Eat and Sleep are the cat’s methods. Do they look strangely like functions to you? Well, thats exactly what they are!

Functions implemented in a class, and that act on the objects created from that class, are called methods.

Object-Oriented Analysis

Let’s take a look at what object-oriented analysis is. As you’ve probably figured out, before you start programming your brilliant app, you need to do some analysis. This is where you will identify what classes your program will require. There’s a fantastic language to help you analyze and design your apps; English! Let’s say you want to make a game (we are going to build an actual working version of this game in a future lesson, not in pseudocode but with a real language. Exciting, right? We know!). The first step is to briefly describe how the game will work. It might look something like this:

The player enters his name. The player then chooses between a bow or a rifle. The bow is less powerful than the rifle but is more accurate. The rifle causes greater damage but is not as accurate as the bow. During a game round, the player shoots first followed by the monster taking its shot(s). Each successful hit reduces the player’s or the monster’s life points. The game ends when either the player or the monster has zero life points left.

Given a brief concept such as this, the first thing we’ll need to do is to rearrange the English into objects with their associated methods (what these objects can do) and their properties (what these objects are like). Let’s make a list of possible objects in this example:

  • Player
  • Bow
  • Rifle
  • Round
  • Monster
  • Game

These are all good candidates for objects as in our game description, each of these nouns have a description and can do something. If we want them to be objects at some point, we need to create a blueprint for each of them. Did we just say blueprint? We meant class, of course! Let’s start by figuring out what these objects would be like by listing some possible properties:

  • Player
    • Name
    • Life points
    • Weapon
  • Bow
    • Accuracy
    • Strength (the damage it can inflict)
  • Rifle
    • Accuracy
    • Strength
  • Round
    • Round number
  • Monster
    • Name
    • Species
    • Weapon
    • Life points
  • Game
    • Title
    • High scores

This is our initial list of properties for our blueprint. Some may get removed in the future and others may be added as we refine the design of our game.

Now, let’s look at the methods we would implement in our classes to define what these objects can do:

  • Player
    • Properties:
      • Name
      • Life points
      • Weapon
    • Methods:
      • Equip a weapon
      • Shoot
      • Die
  • Bow
    • Properties:
      • Accuracy
      • Strength (the damage it can inflict)
    • Methods:
      • Fire
  • Rifle
    • Properties:
      • Accuracy
      • Strength
    • Methods:
      • Fire
  • Round
    • Properties:
      • Round number
    • Methods:
      • Start
      • End
  • Monster
    • Properties:
      • Name
      • Species
      • Weapon
      • Life points
    • Methods:
      • Shoot
      • Die
  • Game
    • Properties:
      • Title
      • High scores
    • Methods:
      • Start a round
      • Create a player
      • Display high scores
      • End

And just like that, we have classes containing properties and methods. They may not be perfect but they are a starting point for our game. Exciting! In general, we suggest that you don’t over-analyze at this stage. That’s what consultants, who are paid by the hour, do, and there’s a special place in hell for them! Our aim is to build our software! A rough analysis on a sheet of paper is a great foundation that will be refined as we do the actual coding.

A Note On Design And Analysis

Code design is not an exact science. There are no absolute “right” or “wrong” ways to code, however some approaches and designs are better than others. Imagine asking two experienced graphic designers to each draw a tree. The resulting designs will be totally different, even though they will both have drawn trees in the past. Each designer views the world through their own unique lens and reproduce it accordingly. Coders are similar. Each programmer will represent their world as they see it. This is the creative art of programming!

Throughout this course, we will offer hints, tips and pointers to help you to become better at designing object-oriented software but we won’t be able to turn you into a master of software design. Only experience and practice will get you to that point.

Summary

Wow – that was quite a bit to take in! In this lesson, you learned that object-oriented programming is a way of writing software that mirrors the physical world. Real world elements are modelized as objects in a program. To interact with an object in a program, you must first create it based on a blueprint known as a class. A class is a custom data type that you create. Objects can do things and we represent doing things with functions we implement in the class. These are called methods. Objects have properties which are also defined in their associated class. Methods and properties form the class members. Objects can interact with each other just like in the physical world. Object-oriented analysis is the step you take before starting to write code in order to define the classes you are going to use in your program.

From this point forward, we will only use object-oriented programming as it is the most common form of writing well designed, maintainable, enhanceable and reusable software. So, if something is not clear in the theory of this lesson, don’t dismiss it. Make sure to ask your questions in the comments section below: object-orientation is central to your programming journey. Bon Voyage!

Important Words

  • Object-oriented programming
  • Object-oriented analysis
  • Class
  • Object
  • Property
  • Method
  • Class member
  • Custom data type
  • Objects interactions
Exercise

Experienced programmers see the real world in much the same way as Neo in the Matrix. Ok, not quite, but close! We need to train ourselves to see our surroundings in terms of objects possessing descriptive features and capabilities. Try to define how these objects interact with each other. As you start seeing them, imagine what their blueprints would look like. Take a few objects you like and try to describe them in terms of a class to your fellow coders in the Forums. You can even take somebody else’s class and create one that would be an element of theirs, or one that would interact with it.

Share to friends