1. BlueJ bank example with subclasses of BankAccount 2. Transparency of UML diagram for BankAccount class hierarchy

Transcription

1 CS112 Lecture: Fundamental Concepts of Object-Oriented Software Development Last revised 1/13/04 Objectives: 1. To review/introduce key concepts of object-orientation: object, class, data members (class and instance), message, method (class and instance), polymorphism, and inheritance). 2. To introduce the use of object diagrams. 3. To introduce the software lifecycle. Materials: 1. BlueJ bank example with subclasses of BankAccount 2. Transparency of UML diagram for BankAccount class hierarchy I. Introduction A. We said at the outset that this course is not just about computer programming, but about a particular kind of computer programming: objectoriented programming. The purpose of today s class is to review some key concepts we have already been introduced to, and to introduce some new concepts and some key terms that we will be using throughout the semester. B. It is important to recognize that one of the key challenges we face in computer science is complexity. In fact, some writers define computer science as the science of managing complexity. Why? 1. In the fifty plus years since computers were first developed, computer technology has developed systems of dramatically increased speed and capacity. This, in turn, has led to the use of computer systems to solve ever more complex problems. Today it is possible to type just a few keystrokes and search databases literally around the world in a matter of a few seconds - a process that ultimately entails the collaboration of thousands of interconnected systems. 2. Unfortunately, as computer systems become more complex, they also become more difficult to understand and maintain. Large computer systems have passed the point where any one human being can possibly have a complete understanding of how a complete system works. As a result, large software systems are typically built and maintained by teams of scores, hundreds, or even thousands of individuals. C. To manage complexity, computer science makes use of three key concepts: modularity, abstraction, and interfaces. 1

2 1. By modularity, we mean breaking a large system up into smaller pieces - each of which may, in turn, be broken into smaller pieces, each of which may, in turn, be broken into smaller pieces... - until the individual pieces become small enough to be understood and managed by an individual or a small team of individuals. 2. By abstraction, we mean that each module in the system treats other modules it must interact with as black boxes that can be understand in terms of a small set of well-defined behaviors, but whose inner workings are irrelevant to the module that uses them. 3. The set of behaviors other modules can count on a module to exhibit is called its interface. We have it as a goal that two components that have the same interface should be interchangeable with one another, leading to notions like plug and play. Example: A familiar electrical plug is a good example of abstraction, modularity and a well-designed interface in a different realm. a) When you plug an appliance into a wall outlet, you depend on the outlet to exhibit a certain behavior (providing 115 V 60 Hz AC current), without needing to know how that current is actually generated or distributed. It may be produced by a nuclear or hydroelectric plant, or it may be produced by burning coal, oil, or natural gas. b) The appliance functions as a module that can be plugged into any standard wall outlet, and the outlet functions as a module that supplies power to any standard appliance. The appliance can be a radio, a computer, an electric shaver, a light, or whatever. c) The standard behavior of a wall outlet - including its electrical characteristics and the precise physical size and shape of the prongs - constitutes its interface. Any appliance with a plug that conform to this interface can be used with any socket that conforms to this interface. D. Over the years, computer scientists have developed a number of different approaches to achieve modularity and abstraction. Of these, the newest (and probably the most powerful) is object-orientation, or OO for short. Though OO dates back to 1967, it began to become prominent in the software world in the 1990 s, and is likely to dominate software development for many years to come. 2

3 II. Key OO Concepts Before pursuing a detailed discussion of a particular OO programming language (Java), we need to be clear in our minds about some of the fundamental concepts of OO. As you read the book for today, what concepts seemed to be crucial? - Develop list on board A. As we have already seen, the key concept in OO is the notion of an object. We have already worked with examples of objects - e.g. the various robots in the Karel J. Robot simulation. 1. Recall that an object has three essential properties. State Behavior Identity 2. At the start of the course, we developed an example of bank accounts. Today s chapter in the book developed a similar example. Certainly, an important object in the world of bank accounts is a BankAccount object. a) A bank account has a state consisting of attributes like: (1) Account number (2) Owner (3) Current balance etc. b) It has behaviors like: (1) Deposit money (2) Withdraw money (3) Calculate interest etc. c) Of course, each account would have its own identity. 3. Actually, in OO systems, objects are of three general types. (This is not meant as a rigid classification, but as a helpful way of looking at the big picture). 3

4 a) A boundary object is used to manage interaction between the program and the outside world (human user or another system). Example: What kind(s) of objects fulfilled this function in the Karel programs we were working with? (1) The window representing the robot s world that we saw on the screen was a boundary object. (2) The window containing the speed and resume/stop controls was actually a window object containing two other objects: a button object and a slider object. All were boundary objects. (3) A GUI application will always have at least one boundary object - the top-level window (frame) in which the application is displayed. (It is possible to write non-gui applications in Java, too, though we seldom will.) b) An entity object is used to represent a thing in (concrete or abstract) in the domain of the program, with methods providing operations on it. Example: What kind(s) of objects fulfilled this function in the Karel programs we were working with? (1) The object(s) representing the robot(s) (2) The objects representing the world. (We didn t work with these directly; however, the call to World.readWorld() resulted in creating the objects needed to represent a specific scenario. c) A control object is used to manage the flow of computation, using the other objects. Example: What kind(s) of objects fulfilled this function in the Karel programs we were working with? (1) The robot programs we wrote were part of a control object. 4

5 They were part of the class that contained the main method. The main method created an instance of the control object, and arranged for its run() method to be called to manage the computation. (2) In this case, it would have also been possible to have the robot object(s) do double duty (as both entity and control objects) by having our subclass of Robot include an appropriate method that could have been started from main(). (In this case, no object of the class containing main would ever have been created.) (3) It is at this point that many OO programs fudge a bit in not actually creating separate control objects - more on this later. B. A second key notion in OO is the notion of a class. Again, we have already been introduced to this concept. A class serves as a template for constructing objects. For example, in the bank account example, we would have a class BankAccount which serves as a template for creating bank account objects. 1. One difficult concept for beginners in OO is understanding the difference between a class and an object. a) Basically, when writing OO programs, we define classes. Then, when the program is running, it creates objects that belong to those classes, using new... b) Any given class is defined exactly once. But there may be many objects belonging to the class. Example: We might define a class called BankAccount, and create many instances of this class, each of which corresponds to an individual account. c) One reason for the confusion is that it is sometimes the case that we have what is called a singleton class - a class for which it only makes sense to have one object that belongs to it. Also, sometimes we may have classes which are not singletons in principle, but behave like singeletons in practice. Example: Monotheism - the belief that there is only one God - amounts to saying (if I can say this reverently) that the class God is a singleton. 5

6 Example: at any one time, there is only one person who belongs to the class PresidentOfTheUnitedStates - though over the course of the years there have, in fact, been 43 instances of this class. (In fact, any time it makes sense to use the phrase the..., there is probably such a class lurking in the background.) Examples from the robot world? The World is a singleton. It makes no sense to have more than one world object at a time. The various kinds of robots we create often behave like singletons. There is no reason - in principle - why we can t have, say, two maze escaper robots - it just happens, in many cases (like the examples we did last class), that we only create one. (And we modified the class definition to change the way the maze escaper robot behaved.) 2. To further contribute to this confusion, it is common to find that, in the case of singleton objects, we may not actually create a separate object - we may use the class as if it were an object. This is the case, for example, with the World class in the robot programs - we treat the World class as if it were an object. 3. Nonetheless, it is important to have clearly in mind that there are some fundamental differences between objects and classes. a) When we create programs, we define classes; when we run programs, we create objects. b) A class is As part of the process of defining a class, we must specify what attributes are recorded for objects of the class. A class is said to encapsulate its attributes. 4. We call these attributes data members. Example: Open up BankExample in BlueJ Look at code for class BankAccount - note how data members accountnumber, owner, and currentbalance are declared. 5. Actually, data members are of two general kinds: 6

7 a) An instance member is associated with each instance of the class, and may have a different value for each member. Example: Each bank account object will have its own value of current balance. b) A class member is associated with the class as a whole, rather than with any particular instance. Example: In today s example, we have a SavingsAccount class that pays interest periodically (while a CheckingAccount does not). We will need to record the interest rate somehow. We will likely associate this with the class as a whole, rather than with each individual account, since all accounts of the same type have the same interest rate - we don t have a different rate for each individual account. Associating such a data member with the class rather than with individual instances saves storage (one copy, rather than many), makes changing the value easier (change it just once, rather than once for each instance), and prevents inconsistencies that would arise if some copies were changed but others were not. Show declaration for interestrate in class SavingsAccount. In Java, a class member is preceded by the word static. (This specific word is actually a historical artifact from C/C++. If we were inventing a language from scratch, we might use a clearer word!) 6. Note that we didn t have any visible data members in our robot objects - though there must have been data members to keep track of things like the robot s position, orientation, and the number of beepers in its beeper bag - we just didn t have to deal with them directly. C. Objects interact by means of messages. 1. In our robot examples, the messages robots could respond to were operations like turnleft(), move(), etc. 2. In the bank account example, the act of a withdrawing money from a bank account at an ATM might be modeled by having the ATM object send a withdraw message (with a numeric argument representing the amount) to the appropriate bank account object. The account object is responsible for subtracting the amount to be withdrawn from its current balance. 7

8 D. In order to be able to respond to a message, the class involved must have as part of its definition a method for responding to that message. Example: if BankAccount objects are to be able to respond to a withdraw message, then the BankAccount class must define a withdraw(amount) method for carrying out this operation. (Note that the method name is always the same as the message name, and is followed by a parenthesized list of arguments - possibly empty.) Show code for withdraw() method in class BankAccount - note how a test is first done to ensure that there is a sufficient balance. 1. An important property of OO systems is that it is often the case that different classes of objects can respond to the same message - but in distinctive ways. This concept has a fancy name. polymorphism Example: We have already suggested that, instead of having just one kind of bank account class, we might have several - e.g. a CheckingAccount class and a SavingsAccount class. Both might be able to respond to a creditinterest message - with the checking account doing nothing and the savings account increasing the current balance by interest computed by multiplying the current balance by an interest rate. (For simplicity, we ignore the possibility of interest-bearing checking accounts, which might constitute yet another class.) This could be handled by defining a creditinterest() method in each class. a) The CheckingAccount creditinterest() method would do nothing. b) The SavingsAccount creditinterest() method would perform an actual computation. SHOW code for this method in each class 2. Actually methods are of two general types: instance methods and class methods. a) An instance method is used for an operation that performed by an individual object that is an instance of the class. Example: The withdraw(amount) and creditinterest() methods we have 8

9 been discussing are of this sort, since they deal with the individual balance of a specific account, and must therefore be sent to a specific instance of the class BankAccount. b) A class method is used for an operation that operates on the class as a whole. Example: A method to modify the interest rate for savings accounts (which, you recall, is a class data member) SHOW code for this in class SavingsAccount - note the word static again. E. In our discussion of different kinds of bank accounts, we have used at the final concept we want to review today: inheritance. 1. We have already made use of inheritance in our robot examples. 2. Note how BlueJ shows the inheritance relationship among the various classes of BankAccount. Note: a) The class BankAccount is an abstract class representing the common properties shared by all bank accounts. b) The CheckingAccount class is both a subclass of BankAccount and a superclass for OverdraftProtectedCheckingAccount. c) Each of the subclasses inherits attributes (accountnumber, owner, currentbalance etc) from the superclass, but may also have attributes of its own (e.g. an OverdraftProtectedCheckingAccount may have an attribute recording the total amount of money that is currently on loan from the bank.) Example: Create an object of class OverdraftProtectedCheckingAccount. Use inspector to show how it has inherited attributes common to all accounts plus an amount on loan attribute. d) The way that inheritance plays out can be depicted by a more complete diagram than the one that BlueJ shows. TRANSPARENCY 9

10 Bank Account accountnumber currentbalance owner deposit(amount) withdraw(amount) creditinterest() reportbalance() getaccountnumber() CheckingAccount SavingsAccount creditinterest() creditinterest() OverdraftProtected CheckingAccount amountonloan withdraw(amount) repayloan(amount) Each of the subclasses may inherit methods from its superclass, may override those methods by responding to the same message in a different way, and may have methods of its own. (E.g. the OverdraftProtectedCheckingAccount may well inherit the deposit(amount) method from BankAccount by way of CheckingAccount, but may override the withdraw(amount) method to provide overdraft protection instead of just failing, and may have a repayloan(amount) method that is invoked when the customer repays money borrowed to cover an overdraft - something that other kinds of bank accounts don t need or have. 10

11 Show in code for class OverdraftProtectedCheckingAccount- note that there is no deposit method at all, since it is inherited, while the other two are present - one because its an override, one because it is unique to this subclass. III. The Software Life-Cycle A. One last concept that we need to discuss in this discussion of What is OO? is the fact that OO programming - indeed any kind of programming - is much more than just writing code in some programming language. For those of you who have never programmed before, this is probably not much of a problem at this point, but for those of you who have done some programming, it is possible that you may have learned some bad habits that must be unlearned. (And those of you that haven t programmed before don t want to learn these bad habits!) B. The goal of programming is to produce correct, reliable, and maintainable software that meets the user s needs. Producing this kind of software requires us to follow an engineering process with several phases: 1. The Analysis Phase - determining exactly what is needed. 2. The Design Phase - determining how it will be built. 3. The Implementation (Coding) Phase - actually building it. 4. The Quality Assurance Phase - ensuring that the software we have built really does what it is supposed to do, correctly and reliably - and fixing the errors if it doesn t.. (Sometimes this is called the testing phase or the verification and validation phase. 5. The Deployment/Maintenance Phase - in which the software is used to accomplish its original purpose, and modified as necessary to keep abreast of changing requirements. C. A very serious problem in the software industry arises when the early phases (analysis and design) are given short shrift, and programmers leap right into coding. This inevitably results in software that is incorrect, unreliable, and difficult to maintain. D. Did you notice something? We have just completed an entire lecture on programming. How much actual program code did we talk about? Programming is much more than coding! 11