Some Background on Object Oriented Programming
| Introduction.
Since Java is considered to be an object oriented
programming language it is important that I spend some time
trying to acquaint you with some of the basic concepts associated with OOP.
But, instead of taking a high intellectual road I want to try and acquaint
you with why object oriented programming has become so prevalent and why
businesses actually make use of it. One difficult question for me to answer is, "How can I get people that are almost totally unfamiliar with programming and particularly with objects to develop a better understanding of what objects are?" The OOP acronym is more than a bit representative of the slippery slopes a professor treads when trying to answer this question. Considering that everyone in the class has almost surely interacted with the Microsoft Office suite of products I will use this experience as the point of departure on our quest to understand Object Oriented Programming even if this seems sacrilegious in a Java course. Imagine yourself as a programmer working for Microsoft on enhancing and developing the Office Suite. You have a project manager that is concerned with many things, but four things in particular
Trying to answer these four questions is something that has made OOP very important in the software development world of today. For example, there are many common features in the Office Suite, such as an overall look and feel, overall organization, menus, toolbars, windows, printer interfaces, file open dialogue windows and on and on. It would make sense to try and get small teams to each focus their attention on particular aspects of the overall suite development and then tie these developments together to create the greater products. Let's say for example that your team is given the responsibility of creating the dialogue windows that are used for the opening and saving files throughout the Office suite. Putting one team on this has the advantage that they will be able to focus their efforts. It also has the likely impact of unifying these interfaces throughout the suite, thereby increasing user comfort as they work with different products in the suite. Let's take a look at the Save As dialogue boxes for three of the products in Microsoft Office 98. I want to express some views using a more primitive version of Office. Then I want to take this even further by showing how these Save As dialogs have changed in Windows XP. |
Save As Dialogue in Microsoft Word
Save As Dialogue in Microsoft Excel
Save As Dialogue in Microsoft PowerPoint
|
Hopefully just by displaying these I have made some of the points I want
to make. Can you imagine the added hassles of
using a suite of products if such basic interfaces weren't unified? Though this is somewhat imprecise, Microsoft has had your team develop classes that contain all of the information, functions, properties and other objects necessary to implement these dialogue windows. So these dialog windows are examples or instantiations of the Save As object from the Save As class. Every time someone opens a Save As dialog they are calling a constructor to instantiate an object of this particular type. In order to build this object you included other objects that allow a user to select the disk/directory/folder, select the files, select the file name and select the file extension. You have also included command button objects that allow users to do things such as move up one directory in the directory tree, go to your favorites, create a new folder, actuate the save or cancel the Save As. Each of these embedded objects may have been created in an earlier version of the Office Suite and you can sort of plug them in with or without enhancements. Eventually, once all of the necessary objects have been developed they can be assembled into a finished software program. It is much easier to modify or maintain object based software development for many reasons, some of which are well beyond this very superficial and introductory discussion. The software associated with each object is usually very self-contained or encapsulated in a class or class hierarchy. Thus it is much easier to focus on the relevant issues. A programmer needs only to follow a few conventions to make sure their changes and programs don't interfere with the ability of the object to be assembled with other objects. Now you should look at the Save As dialog in Word for Office XP. |
| Ultimately, you should notice how similar this is to
earlier versions in Office 98. This is likely to be even more true
for versions of Office between 98 and XP. Thus, code reusability is one of the key issues impacting the desire to develop useful classes and objects. One only needs to inherit from previous classes and extend previously existing capabilities. It used to be that when computers were had much less memory for RAM and hard drives and their processing speeds were much slower, taking approaches such as OOP were considered to be poor programming practices. But as memory and speed have become more and more available even with GUI interfaces developers have been able to make use of OOP. Another Example. You may not be able to remember all the frenzy associated with computing when switching over to the new millennium. No one really knew everything that could or might go wrong with programs that had not been developed with use during this transition in mind. Endless and expensive hours were spent going over all kinds of systems trying to find date and time references in programs. If OOP had been prevalent it is much more likely that developers would have been able to focus on just a few classes/objects associated with date and time processing in programs and made adjustments to these if necessary. Class Hierarchies. While this is a concept that is really quite sophisticated and hard to get a handle on, I will try to initiate your development with some discussion and examples. Think of a situation where you want to develop a program that gets inputs from a user and draws a geometric shape. There are all kinds of shapes to be considered, but even with the following list you can start to imagine the complexity of implementing such capabilities.
Most of these are flat sided or have straight lines as boundaries. Maybe you should write some code that can be made use of in all these instances to draw these sides. Then you won't need to rewrite this code for each type of flat sided figure you want to draw. This line drawing capacity is likely to be developed higher up in the hierarchy so that it can be accessed in more specialized implementations. You may want the user to have the capacity to just draw ovals and allow them to draw circles by using the oval drawing capabilities with the alt key pressed. The same could be done for squares in relation to rectangles. This might result in some sort of hierarchy in the classes. You might also want the user to be able to fill each of these shapes with a color. This is very likely to result in the developers developing this capability further up the hierarchy so that every class underneath can inherit these abilities and prevent code rewrites. For another example think of something like a space invaders game that has little objects that appear on the screen that must be destroyed. Maybe each of these types of objects inherits from a class further up the hierarchy that allows things to be specified such as
Thus, much of the functional parts of the code can be developed in somewhat more abstract frameworks and specified later. This assists debugging, reducing code duplication and a lot of other things. We will barely get into developing our own class hierarchies in this course. But I want to point them out as we go through the semester to help you get acquainted with hierarchies that others have considered useful. OOP and Java. Since this is a course in Java I want to get to these issues. We will discuss several of Java's pre-built classes and hierarchies for quite some time before you start developing your own. Java programs require a sort of overall inclusive class with the same name as the file in order to run. There really is no escaping classes and objects in Java, though I have heard some self proclaimed experts state otherwise. But, I have yet to see how they do this. I will make certain that we make use of a variety of pre-built classes, objects, methods and properties as we work through out this course. |