Showing posts with label object. Show all posts
Showing posts with label object. Show all posts

Sunday, January 8, 2012

Advantages of Using Objects

As I said at the outset, object-oriented programs are written using objects that are specific to the problem being solved. Your pinball machine simulator may well define and use objects of type Table, Ball, Flipper, and Bumper. This has tremendous advantages, not only in terms of easing the development process and making the program code easier to understand, but also in any future expansion of such a program. Java provides a whole range of standard classes to help you in the development of your program, and you can develop your own generic classes to provide a basis for developing programs that are of particular interest to you.

Because an object includes the methods that can operate on it as well as the data that defines it, programming using objects is much less prone to error. Your object-oriented Java programs should be more robust than the equivalent in a procedural programming language. Object-oriented programs take a little longer to design than programs that do not use objects since you must take care in the design of the classes that you will need, but the time required to write and test the code is sometimes substantially less than that for procedural programs. Object-oriented programs are also much easier to maintain and extend.

Operating on Objects

A class object is not just a collection of various items of data. In addition to the parameters that characterize an object, a class specifies what you can do with an object of the class - that is, it defines the operations that are possible on objects of the class. Clearly, for objects to be of any use in a program, you need to decide what you can do with them. The operations that you specify for objects of a given type will depend on what sort of objects you are talking about, the attributes they contain, and how you intend to use them.

For the CowboyHat class, you may want to have operations that you could refer to as putHatOn and takeHatOff, which would have meanings that are fairly obvious from their names, and do make sense for CowboyHat objects. These operations on a particular CowboyHat object would set the value of hatOn for the object. To determine whether your CowboyHat was on or off, you would just need to look at this value. Conceivably, you might also have an operation changeOwner by which you could set the instance variable recording the current owner’s name to a new value.

Of course, for each type of object you can have any operation that makes sense for you. If you want to have a shootHoleIn operation for Hat objects, that’s no problem. You just have to define what that operation does to an object. You are probably wondering at this point how an operation for a class is defined. As you’ll see in detail a bit later, it boils down to a self-contained block of program code called a method that is identified by the name you give to it. You can pass data items - which can be integers, floating-point numbers, character strings, or class objects - to a method, and these will be processed by the code in the method.

A method may also return a data item as a result. Performing an operation on an object amounts to executing the method that defines that operation for the object. Just so you’ll recognize one when you see it, let’s take a look at an example of a complete class definition. The code for the class CowboyHat we have been talking. This code would be saved in a file with the name CowboyHat.java. The name of a file that contains the definition of a class is always the same as the class name, and the extension will be .java to identify that the file contains Java source code. The code for the class definition appears between the braces that follow the identification for the class.

The code for each of the methods in the class also appears between braces. The class has three instance variables, owner, size, and hatOn, and this last variable is always initialized as false. Each object that is created according to this class specification will have its own independent copy of each of these variables in Java program, so each object will have its own unique values for the owner, the hat size, and whether the hat is on or off. I omitted the type parameter in this version of the class to make the code a little bit shorter. The keyword private, which has been applied to each instance variable, ensures that only code within the methods of the class can access or change the values of these directly.

Methods of a class can also be specified as private. Being able to prevent access to some members of a class from outside is an important facility. It protects the internals of the class from being changed or used incorrectly. Someone using your class in another program can get access only to the bits to which you want them to have access. This means that you can change how the class works internally without affecting other programs that may use it. You can change any of the things inside the class that you have designated as private, and you can even change the code inside any of the public methods, as long as the method name and the number and types of values passed to it or returned from it remain the same.

Our CowboyHat class also has five methods, so you can do five different things with a CowboyHat object. One of these is a special method called a constructor, which creates a CowboyHat object - this is the method with the name, CowboyHat, that is the same as the class name. The items between the parentheses that follow the name of the constructor specify data that is to be passed to the method when it is executed - that is, when a CowboyHat object is created.

What Are Objects?

Anything can be thought of as an object. Objects are all around you. You can consider Tree to be a particular class of objects: trees in general. The notion of a Tree in general is a rather abstract concept - although any tree fits the description, it is more useful to think of more specific types of tree. Hence, the Oak tree in my yard which I call myOak, the Ash tree in your yard which you call thatDarnedTree, and a generalSherman, the well-known redwood, are actual instances of specific types of tree, subclasses of Tree that in this case happen to be Oak, Ash, and Redwood. Note how we drop into the jargon here - class is a term that describes a specification for a collection of objects with common properties.

A class is a specification, or blueprint - expressed as a piece of program code - that defines what goes to make up a particular sort of object. A subclass is a class that inherits all the properties of the parent class, but that also includes extra specialization. Particular classes of Tree, such as Oak or Ash, have all the characteristics of the most general type, Tree; otherwise, they could not be considered to be such. However, each subclass of Tree, such as Oak, has its own characteristics that differentiate Oak objects from other types of Tree.

Of course, you define a class specification to fit what you want to do in your application context. There are no absolutes here. For my trivial problem, the specification of a Tree class might just consist of its species name and its height. If you are an arboriculturalist, then your problem with trees may require a much more complex class, or more likely a set of classes, that involves a mass of arboreal characteristics.

Every object that your program will use will have a corresponding class definition somewhere for objects of that type. This is true in Java as well as in other object-oriented languages. The basic idea of a class in programming parallels that of classifying things in the real world. It is a convenient and welldefined way to group things together.

An instance of a class is a technical term for an existing object of that class. Ash is a specification for a type of object, and yourAsh is an object constructed to that specification. So, yourAsh would be an instance of the class Ash. Once you have a class defined, then you can come up with objects, or instances, of that class. This raises the question of what differentiates an object of a given class from an object of another class, an Ash class object, say, from a Redwood object.