8.1 Object Orientation
8.1 Object Orientation In the bad old days, when programmers such as myself wore our flow charting templates with pride , software was pretty much written according to a process flow. The flow of control began at the first line of code and continued to the last line, with a few loops , if statements, and subroutines in between. Most of the time, we were left on our own to develop an entire application from scratch, continually reinventing the wheel by rewriting the same set of functions. In addition, some parts of this code were better written than others. It was common to have a newly written function corrupt a file or reduce system performance. To improve both productivity of the staff and the integrity of the system, managers began to develop libraries of functions within an application to support the various resources. When a program accessed a file, for example, it would do so through the common library functions. Some might consider this approach the predecessor to object-oriented software development. In a sense, these libraries objectified system resources. The application began to see the resource as an entity and surrounded it with a set of functions. One could argue that object-oriented programming began almost 400 years ago. John Locke, an English philosopher born in 1632, developed a new way of looking at the universe. He believed that everything in the human mind was an idea . When he used the term idea, he was referring not only to thoughts, but to everything in our heads. This included sensory input, pain, and emotions. Everything. Everything we know, think, perceive, or feel is an idea. Consequently, we do not have a direct connection to the universe; we can only work with the ideas in our own heads. This book is a simple example. You know that you have this book in front of you because you are receiving sensory input. You see it because it reflects light and your eyes perceive that light. The perception of this light is an idea. If you are holding the book, you feel its weight and the texture of the cover. Both the weight and the feel of the book are sensory input, ideas. The book itself, however, is more than an image, weight, or texture. The book is beyond the things that we perceive. It is beyond our ideas. Philosophers describe this as the difference between immediate and mediate . There are things as we experience them, the immediate, and then there are things as they are unto themselves , the mediate. If you were to meet me, you would probably experience me as a brutally handsome, highly intelligent fellow with a rapier sense of wit and keen insights. Nevertheless, is that who I truly am? These are only your perceptions of me. Every human being is much more than who he or she appears to others to be. There is an entire internal aspect to every person. We may perceive a person as angry and hostile . We don't necessarily see or understand the internal forces that drive those actions, which are an outward manifestation of the internal feelings. Figure 8.1 demonstrates the difference between the mediate and the immediate. The immediate can be broken down into two categories: attributes and behaviors. Attributes are the characteristics of the object. A person's attributes are his or her height, weight, eye color, and hair color . Behaviors are actions. A person may run, walk, laugh , or cry. These are all things that we can observe. While an emotion, a mediate, may manifest itself in the immediate, it is still mediate. A person may feel sad, and cry. The behavior is crying, which is immediate. The emotion, sadness, remains mediate. Figure 8.1. The immediate and the mediate. We can only perceive what we can perceive. This means that our understanding of anything in the world around us is limited to our perceptions. Objects become abstractions of their actual existence. That is, we focus our attention only on the relevant aspects of an object, ignoring those aspects that do not relate to the current interactions. We ignore the unperceived and focus only on the perceived attributes of an object that relate specifically to us. We may abstract an individual based on the way he or she interacts with us. We may label this abstraction as a nice guy or a good sport because those terms are indicative of their behavior. We infer the mediate from the immediate. Internally, the reason a person is a good sport may be that he or she lacks the courage to express the hostility he or she may feel at losing. Since we have no perception of the fear or the suppressed hostility , the inference or conclusion we draw about the internal may be quite incorrect. The mediate may be something altogether different. In a sense, this is how the object-oriented world experiences its environment. In the bad old days of programming, every interaction between the external world and the program was separate and independent. There were no structures within the language that abstracted the entities. Object-oriented programming changed this view. We see this in Figure 8.2. Programs now work with objects that are abstractions of things within the environment. The immediate characteristics of the object, both attributes and behaviors, are public . They are seen from outside the object. The mediate behaviors and attributes of the object are private, accessible only to the functions that are internal to the object. Figure 8.2. Object structure. A relational database demonstrates the difference between public and private. Public behaviors of the database can include open, close, read, and write. The database also has attributes that reflect the state of the database, such as opened or closed. When our application wishes to establish a connection to the database, it can invoke the database open behavior. The application can then retrieve data by invoking the read behavior. These are actions carried out by the object. Objects also have attributes. These may include the state of the database or an output queue. For example, our application may check the state of the database to determine if it is open. The state is an attribute of the database. The database object also has attributes and behaviors that are private to the database itself. Programs outside of the database cannot see them. For example, the database may have an archive log for database recovery. Without going into the details of an archive log, functions within the database write and read from this log, but it is not accessible to the program invoking the database object. We may also have attributes that are exclusively internal to the database, such as block size. While functions within the database may need to know the block size , applications accessing the database need not. We now move from Locke to Hume. Hume discussed causality , how one state causes or brings about another. Hume noted how we draw conclusions about cause and effect based on our observations. For example, let us assume that a child, for the first two years of his life, experiences only spherical objects that are rubber ballsballs of all sorts of shapes , sizes, and textures. Then one day his uncle comes to visit and gives him a ceramic ball, perhaps it is a globe. The child immediately takes it and slams it to the ground. Of course, not having experienced a sphere other than those made of rubber, the child had no idea that it would shatter. He naturally assumed that the ceramic ball would behave as all other spherical objects in his life behaved. He thought it would bounce. This brings us to the another aspect of object-oriented programming: classification. What the child did was something we all do. He extended his past experience and projected it onto the new object. In real life each time we encounter an object, we don't treat it as if it is the first time we encountered such an object. When we get in a car, we know from our experience with other cars how the steering wheel, brakes, and transmission work. There is no need to retrain ourselves with the new car. We do the same with object-oriented programming. We take the objects that are similar and create a class. The class describes the attributes and behaviors common to the objects in that class. The child created in his mind a class of objects called balls to which he ascribed certain attributes. First, all balls had a spherical shape. Second, they had a range of textures and colors. Certainly, the attributes of the globe fit these criteria. Balls also have certain behaviors. Balls, as well as globes, roll. Balls bounce. The child quickly learned that ceramic spheres do not share the bouncing behavior with balls. In object-oriented programming, the objects within a class have similar attributes and behaviors. In our example, we can have the class balls and another class globes. We might even have a class called fruit. In each class, we specify the attributes and behaviors that are common to the objects within that class. When describing a balls class, we would give it the attribute spherical and the behavior bounce. For the globes, we would assign the attribute spherical and the behavior shatter. This would work well in some situations, but we can do better. Rather than create a single class for each type of object, we create a hierarchy of classes. We present such a hierarchy of classes in Figure 8.3. Spheres, the topmost node in the hierarchy, is a superclass . The classes beneath the sphere are its descendents. The superclass contains behaviors and attributes common to the descendents. The descendents inherit these from the superclass. The balls, fruit, and globes classes are also superclasses. They contain the behaviors and attributes that are specific to them and their descendents. A ball may have the behavior bounce, while the fruit may have the behaviors ripen and taste. We push the behaviors and attributes down a level because they are not common to all spheres. A ball may have the behavior bounce, but ripen is meaningless to it. Figure 8.3. Class structures. We know that not all balls bounce the same. While a golf, tennis, and baseball all may bounce, they do so in very different ways. The different ways in which a subclass carries out a behavior is a method. If we bounce a tennis ball, the characteristics of how that ball bounces is its method. The way in which a baseball bounces is very different. Rather than discussing balls and spheres, think for a moment how we might apply this to an application. We might have an application that writes to several output devices. In some cases, the device is a printer, while in others it is a terminal. The way we write to each will differ ; these differences are the different methods . The behavior is the same, writing to an output device. We should make an important distinction between a class and an object. A class describes a type of object, not an actual instance of an object. When we define a balls class, we do not have an instance of a ball. This is actually something quite common to most programming languages. Data types such as integers, floating-point numbers , and characters do not actually create an instance of a variable. They are just types, not the actual variables that hold values. When we write our program, we need to create a variable that is an actual instance, a data type. Similarly, when we create an object class, we are only establishing the class type, not an instance. A class with actual instances is a concrete class. A class in which there are no instances is an abstract class. In our example, we may specify that a sphere must be one of the three subclasses. A ball, however, can be a general, nondescript ball. In this case, the spheres class is an abstract class. There are no actual sphere instances. The balls class and all its subclasses do have instances, which makes the balls class a concrete class. In creating these class structures, we are able to manipulate groups of objects at one time. This is inherent to an object-oriented programming environment. The remainder of this chapter discusses Java. As we explore both the Java language and its environment, we shall see how we can use this object orientation to develop IEBI applications.  |
| | |
Team-Fly  |
| Top |
EAN: 2147483647
Pages: 113