 |
 |
 |
 |
 |
 |
 |
|
The Decision Sciences Journal of Innovative Education
An Approach to Teaching Object-oriented Programming Concepts in Business Schools
V. Ramesh
Department of Accounting and Information Systems
Indiana University
Bloomington, IN
(812) 855-2641
Ji-Tsung Ben Wu
Fu-Jen Catholic University
Taipei, Taiwan
benwu@im.fju.edu.tw
January 29, 2003
An Approach to Teaching Object-oriented Programming Concepts in Business Schools
Java has gained immense popularity as a language for developing business applications especially for web-based applications (on the server side). Despite its popularity, however, it has still not made extensive inroads into many Information Systems and Decision Sciences curricula. One of the primary stumbling blocks in teaching Java lies in conveying the object-oriented aspects of Java to the students. In most business school curricula, students often are exposed to Java after having been taught other procedural languages such as VB or C. In addition, very often students are exposed to both Java the language and the concepts of object-orientation in the context of a single course. Thus, an instructor is faced with two challenges: a) overcoming the cognitive obstacles in moving from a procedural to object-oriented language (Manns and Nelson 1996), and b) conveying key concepts of object-orientation in a single semester. In this paper, we present an approach to teaching object-oriented concepts (using Java) that has been used successfully to overcome both of these challenges. It should be noted that while we discuss this in context of Java, the same concepts should be applicable to teaching other object-oriented languages, e.g., C# or even VB.NET. The target audience for our approach is any student who has already taken a course in programming.
Based on our experiences teaching Java to students we have identified three main hurdles that they face: a) inability to clearly distinguish between the notion of classes and objects, b) understanding and using complex objects (objects that contain one or more objects within them) , and c) grasping the concepts of inheritance and interfaces. In the sections that follow, we present a series of steps that can help students overcome these hurdles.
Provide a Gentle Introduction: A key problem in teaching Java, especially to novice programmers, lies in getting students to understand the notion of a basic Java class. We found that it is very important to not overwhelm students with multiple classes. Hence, for almost 3 weeks we focus on a single Java class view of the world, i.e., all applications use a single class. This allows us treat a Java class in a very similar fashion to a C program while at the same time focusing on the notion of using objects (see below). An example of the very first class we show students is shown below:
public class Hello
{
public Hello() {//initialize any variables here}
public void run() {
//application logic will go here
System.out.println("My First Java Program");}
public static void main(String args[]){
//change class name and constructor calls in your application
Hello myApp;
myApp = new Hello();
myApp.run();
}
}
While the example may look trivial, it embodies two key aspects (in the main() method) worth highlighting since they represent solutions to problems commonly faced in introducing Java to students. First, we present the method above as a template for all programs (at least in our course) that they are going write. Thus, when confronted with a new problem they have a relatively easy way to get started. Second, we discourage writing any other code within the method thus deferring explanations regarding static methods to a later point in the course and at the same time avoiding the potential for errors stemming from invalid references to instance variables in static methods. Many books write all their application code within the static main method. However, this practice often results in error messages that are difficult for beginning students to comprehend.
Working with Objects: After providing the basic knowledge necessary to create an “application” class, we deviate from the approach used in most books. Most books would at this point describe what a class is, i.e., that it consists of variables and methods, and present an example of a sample class, e.g., Person, Employee etc. We contend that someone with no exposure to object-oriented programming is not ready (at this point) to comprehend the complexities surrounding the creation of classes, i.e., the concepts of instance variables, constructors and methods. In particular, we believe that a key issue is that they need to be educated on the notion of what objects are and the role they play in programs before requiring them to write classes that create the objects. We believe that this detour represents a critical step in getting students to understand object-oriented programming concepts and is the key innovation that we bring to the table. We provide details of our approach below.
We begin by exposing students to objects by teaching them how to create and use objects from existing classes in the Java class library. In our instruction, we emphasize that in order to understand how to use ANY class in a Java program one only needs to understand two things: a) how to use the constructor to create object instances and b) understand what functionality can be achieved through the objects’ methods. We then show them the use of the above principles in the context of using a String class. We point them to the Javadoc for the String class and encourage them to use the constructor with the String(String) signature to create one or more String objects and use simple methods such as the length() or charAt() in a program. After this basic exposure to String objects, typical examples of applications we ask them to write (as in-class exercises) include, checking that a phone number or social security number is of the right format, checking if a string contains a substring pattern etc. It is worthwhile noting that students are only informed that the methods they need to solve these problems have already been defined in the String class. However, it is up to the students to identify the methods in the String class that can help solve the problem. Thus, the focus of these exercises is not on the programming logic. Rather, they are aimed at getting the students to understand the notion of an object (without requiring them to writing their own classes) and becoming comfortable using objects’ methods in their code.
We continue this process of “getting the mind” used to using objects by asking students to use two other classes, CardDeck and Card (Horstmann, 1998), to create several card games, i.e., Blackjack, Baccarat, Basic Poker hands etc. Another example class that we have used successfully is a Dice() class that has a single roll() method that simulates the rolling of a die. By exposing students to the use of these objects in different kinds of applications, we are able to get them to see clearly see the role of objects in object-oriented applications.
It is important to note that in all these exercises we do not provide students access to the source code in the classes. Instead, we only provide them with a description of the constructor and the methods, i.e., the Javadoc. Thus, students have to create and use objects without looking at the code. We found this to be another critical reason for our success. This strategy implicitly exposes them to the concept of encapsulation and reinforces in their mind the notion that all interaction with an object should be achieved only through its methods. In addition, while demonstrating the use of objects we emphasize the fact that the creators of the Card and CardDeck classes did not create it to meet the needs of a specific application. This begins the process of getting their mind used to the notion that objects (and hence classes) are self-contained units that need to be designed for use (potentially) in multiple applications. The ability to use the same class(es) in multiple applications also allows them to understand (at a basic level) the notion of reusability.
Introducing Complex Objects: Once students are comfortable using the above mentioned classes we introduce them to complex objects and classes that are more business oriented. Specifically, we require students to use a Bank and Customer class to create a Banking application that performs simple transactions like adding a new customer, depositing money, withdrawing money etc. A class diagram for the Banking application is shown in Fig. 1.
Figure 1 UML Diagram for Customer and Bank Example
Again, students are only provided with a description of the methods and the constructors. Students interact solely with the Bank objects in their Banking application and they are told that the details of how the Bank class uses the Customer class is not relevant to their application. This example introduces them to the notion that it is possible for an object to contain and use other objects. The Bank class also contains more methods than is needed for them to design their application, thus reinforcing the notion that a class (and hence an object) is not necessarily created with a single application in mind.
Unwrapping the covers: At this point, after almost 6 weeks, we (finally!) reveal to the students the source code for all the classes they have been using, i.e., Card, CardDeck, Dice, Bank and Customer. For the first time, they are able to see the inner workings of a class whose objects they have been using thus far. Using the source code for these classes, we introduce them to the concepts of instance variables and walk through how the methods in the classes use instance variables to keep track of state. Throughout this phase, we ask students to think back to the application they created and reflect on how they were able write the code without knowing the details of what went into the Bank class’ methods. This allows us to highlight the importance of ensuring that each class is encapsulated and also demonstrates principles of good class design. The Bank example also serves as an example of design by composition. We remind them of the fact that while the Bank class uses the Customer class extensively, their application class itself did not have to deal with the Customer class directly. We introduce this notion of composition before introducing inheritance to students because we have found that composition is easier to understand than inheritance. It also allows students to appreciate the key notion of how well designed object-oriented programs can support the concept of “division of labor” among various classes, each performing its own tasks. The code for the Bank and Customer classes as well as the solution to the Banking application described above can be found at http://www.indiana.edu/~s220/Bank/. In addition to the Banking example, we require students to design solutions to several other problems that require the use of such composition relationships.
The final exercise that brings it all together for the students requires them to write the code that goes into the classes used by an application, given only the source code for the application. The example used is an application that keeps track of student registration for various seminars. We give the students the entire source code for the application that uses two other classes, Seminar and Registration. The students are then required to determine the methods and variables needed in these classes as well as write the code for these methods. A description and solution for this exercise can be found at: http://www.indiana.edu/~s220/Assignment3/
Inheritance, Polymorphism and Interfaces: By now, week 9 or so, the students are very comfortable with the notions of objects, classes, encapsulation and design by composition. We then introduce them to concepts of inheritance, abstract classes and polymorphism using business examples. We have found that in addition to using business examples it is also very useful to use examples of existing class hierarchies in Java, e.g., Collections hierarchy, the JDBC interface, Collections Interface, and the Servlet hierarchy, to illustrate the concepts of interfaces and inheritance. This approach has the dual benefit of introducing students to the concepts of inheritance and interfaces as well as the key technologies that they will need to use in creating web applications.
We have used the approach outlined above to teach multiple sections (over a 4 year period) of a senior level undergraduate and a graduate level course in Object-Oriented Design and Programming. The philosophy behind the course has also been applied in 2 different corporate settings. Feedback in all these settings has been overwhelmingly positive. For example, the average from six semesters of student evaluations suggests that they found the class to be intellectually challenging (6.56/7.00). At the same time, they rated the course (6.41/7.00) and the instructor (6.62/7.00) very highly. In addition, the manager in charge of one of the corporate clients stated in a letter that “it was the most positive response to any type of formal training I have arranged”. Since no books in the market adequately reflect our strategy of focusing on using objects before teaching design of classes, a set of chapters based on this teaching philosophy described is used as the primary textbook and is available upon request from the first author.
References
Manns, M. L. and Nelson, H. J. (1996) "Retraining Procedure-oriented Developers: An Issue of Skill Transfer", Journal of Object-oriented Programming. 9(7) pp.6-10.
Cay Horstmann (1998), Computing Concepts w
