Chapter1 - Introduction to Object-Oriented Programming and Software Development
•Télécharger en tant que PPT, PDF•
2 j'aime•5,042 vues
Introduction to Object-Oriented Programming and Software Development
![Objectives ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Chapter1 - Introduction to Object-Oriented Programming and Software Development
Similaire à Chapter1 - Introduction to Object-Oriented Programming and Software Development (20)
Plus de Eduardo Bergavera
Dernier
Dernier (20)
Chapter1 - Introduction to Object-Oriented Programming and Software Development
- 1. Chapter 1 Introduction to Object-Oriented Programming and Software Development
- 5. Graphical Representation of an Object <Object Name> We use a rectangle to represent an object and place the underlined name of the object inside the rectangle. Example: SV198 This is an object named SV198.
- 6. An Object with the Class Name <Object Name> : <Class Name> This notation indicates the class which the object is an instance. This tells an object SV198 is an instance of the BankAccount class. Example: SV198 : BankAccount
- 8. Sending a Message deposit 250.00 Message deposit with the argument 250.00 is sent to a BankAccount object SV198. SV198 : BankAccount
- 9. Sending a Message and Getting an Answer current balance getCurrentBalance() Ask for the current balance of this particular account. SV198 : BankAccount The current balance of SV198 is returned.
- 10. Calling a Class Method maximum speed MobileRobot getMaximumSpeed() Ask for the maximum possible speed for all MobileRobot objects is returned.
- 12. Sample Instance Data Value All three BankAccount objects possess the same instance data value current balance . The actual dollar amounts are, of course, different. SV098 : BankAccount SV211 : BankAccount SV129 : BankAccount current balance current balance current balance 908.55 1304.98 354.00
- 13. Sample Class Data Value SV098 : BankAccount SV211 : BankAccount SV129 : BankAccount current balance current balance current balance 908.55 1304.98 354.00 BankAccount minimum balance 100.00 There is one copy of minimum balance for the whole class and shared by all instances . This line is an instance-of relationship.
- 14. Object Icon with Class Data Value When the class icon is not shown, we include the class data value in the object icon itself. SV129 : BankAccount current balance 908.55 minimum balance 100.00
Notes de l'éditeur
- Upon completing this lesson and studying the corresponding sections from Chapter 1 of the textbook, you will have a basic understanding of classes, objects, methods, and data values. You should also be able to draw correct icons for classes and objects.
- The two most important concepts in object-oriented programming are the class and the object. In the broadest term, an object is a thing, both tangible and intangible, which we can imagine. A program written in object-oriented style will consist of interacting objects. For a program to maintain bank accounts for a bank, for example, we may have many Account, Customer, Transaction, and ATM objects. An object is comprised of data and operations that manipulate these data.
- This is how we represent a class. The name of a class appears inside the rectangle. The example shows two classes: Account and Motorcycle.
- This is how we represent an object. The name of an object also appears inside the rectangle, but unlike the class name, an object name is underlined. This example shows an object whose name is SV198. Notice that just by looking at this icon, we cannot tell what type of an object it is? Is it a Motorcycle? Or is an Account? We will use another notation, shown in the next slide, when we wish to identify the class it belongs to.
- To indicate the class of an object, we suffix the object name with a colon and the class name. The example shows an object SV198 is a BankAccount object.
- An object is not a passive container of information. Rather, it is an active entity capable of carrying out tasks. Tasks such as deducting a withdrawal amount from an account, computing the shortest route from your dorm to a classroom, and so forth. To command an object (or a class) to do something, we send a message to it. Not all objects (and classes) can respond to any messages sent them. They must be programmed to recognize messages. In other words, we define methods. Once a method is defined, then we can send a matching message. For example, we define a method, say, move to a MobileRobot object. Once this method is programmed correctly, then we can send a message to a MobileRobot object to move.
- Here’s an example of sending a message. This slide shows a sending of the message deposit to SV198. The BankAccount class must include a method named deposit. Otherwise, there will be an error because SV198 won’t be able to recognize the message. The name of the message we send to an object or a class must be the same as the method’s name. Because they are the same, the phrase “calling an object’s method” is synonymous to “sending a message to an object.”
- The deposit method in the previous slide is an action-only method. An object takes some action when called, but returns no answer back to the caller. The getCurrentBalance method in this slide is a value-returning method. When called, an object will return a value.
- Here’s an example of calling a class method. It is not as common as the instance methods, but it can be handy in certain situations. The maximum speed of all MobileRobot objects is the same. Since the result is the same for all instances, we define getMaximumSpeed as a class method. General Idea: You define an instance method for a task that relates uniquely to individual instances (like getCurrentSpeed, which is different for individual mobile robots) and a class method for a task that relates to all instances of the class collectively.
- Every object from the same class will have the same set of data values. The values themselves for individual objects would be different, of course. We assume here that the minimum balance is the same for all accounts. If this is the case, then the single value for minimum balance is shared by all Account objects. So we need to keep one value of the minimum balance that will be shared by all Account objects.
- Here we see that all instances of the BankAccount class has a data value named current balance. Although only one instance data value is shown here, it does not mean these objects contain only one data value. Most likely the real BankAccount objects would include about a dozen or so instance data values. We only show a single instance data value here so the diagram would not become cluttered.
- Here we see that a single class data value named minimum balance is shared by all instances. The dotted lines show the three objects are instance of the BankAccount class. To see the significance of a class data value, consider the situation where the minimum balance is represented as an instance data value. Because there’s only one value for the minimum balance, defining it as an instance data value would result in maintaining three copies of the same value, one copy per object. This is a waste of memory space. Not only that, more critically, keeping duplicates in memory will complicate the processing. When we have to change the value for the minimum balance, for example, we have to locate all copies and update them. Imagine updating the duplicates copies of 1000 BankAccount objects. This is a very time consuming and error-prone activity, which can be avoided easily by representing the information as a class data value.
- When we do not include the class icon in a diagram, we can use this notation. Whether the data value name is underlined or not indicates the information is a class or an instance data value.
- When a construction firm builds a house, it will follow a strict construction sequence that is based on sound engineering principles. Although software is not a physical object, it is just as complex as a building. And we also need to follow a strict software construction sequence if we expect to build an error-free software. We need a software construction sequence that is based on sound software engineering principles.
- In the analysis phase, we perform a feasibility study. We analyze the problem and determine whether a solution is possible. If a solution is possible, the result of this phase is a requirements specification which describes the features of a program. In the design phase, we turn a requirements specification into a detailed design of the program. For an object-oriented design, the output from this phase will be a set of classes/objects that fulfill the requirements. In the coding phase, we implement the design into an actual program, in our case, a Java program. In the testing phase, we run the program using different sets of data to verify that the program runs according to the specification. Two types of testing are possible for object-oriented programs: unit testing and integration testing. With unit testing, we test classes individually. With integration testing, we test that the classes work together correctly. Activity to eliminate programming error is called debugging. An error could be a result of faulty implementation or design. When there's an error, we need to backtrack to earlier phases to eliminate the error. Finally, after the testing is successfully concluded, we enter the operation phase in which the program will be put into actual use. The most important and time-consuming activity during the operation phase is software maintenance.