1 / 58

Object Oriented Programming

Object Oriented Programming. Or: We Finally Start Talking Openly About That Thing Mr. Ahronheim Keeps Talking About. AP Computer Science 9/12/11. What is a Black Box?. A Black Box is: Why is a car’s onboard computer never serviced?. More On Black Boxes.

dinesh
Télécharger la présentation

Object Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Object Oriented Programming Or: We Finally Start Talking Openly About That Thing Mr. Ahronheim Keeps Talking About AP Computer Science 9/12/11

  2. What is a Black Box? • A Black Box is: • Why is a car’s onboard computer never serviced?

  3. More On Black Boxes • Why doesn’t the average driver try to fix their car engines when it breaks? • What are some reasons that this is a good idea?

  4. If It’s All Hidden How do We Use it? • What is the interface that the average driver uses to run their car? • How is this different from the interface that a mechanic uses?

  5. Talking Technically • A black box provides encapsulation. • Like any other capsule. • In medicine, why are capsules used?

  6. It’s All About Perspective • Different people use different levels of abstraction to manipulate objects. • Abstraction is all about how far back you need to step back to see the picture you’re supposed to see.

  7. So Why do we Go Through the Trouble? • In simpler times, our programs were simple. • A program then:

  8. A Program with OOP:

  9. The Evolution of Object-Oriented Programming • Advantages of OOP:

  10. The Magic of Abstraction Driver Car Automotive Engineer Car Computer Component Designer Capacitors and Transistors Chemists/Physicists

  11. How Have you Interacted With Objects so Far?

  12. Public Interface • We create objects with constructors. • We use them with methods like accessors and mutators. • Do you really care how each of them works?

  13. A Public Interface • What about those “methods” a driver does? • Those actions and methods define the public interface of a car as viewed by the driver. • Now let’s take a quick look at the example used in the book.

  14. Banking Software • In the book, the author wants to run the following code: • harrysChecking.deposit(2000); • harrysChecking.withdraw(500); • System.out.println(harrysChecking .getBalance()); • From this, we can imply some of the interface of this program.

  15. Defining Methods • A method definition has several pieces: • publicintmyMethod(char myLetter) • Theaccess specifier • Thereturn type • Themethod name • A list of any Parameters, enclosed in parentheses. • This is followed by the actual code of the method -- the method body.

  16. Bank Software Methods • Signature for the deposit method: • Signature for the withdraw method: • Signature for the getBalance method:

  17. Constructors • We’ve called constructors, now it’s time to build one. • How are constructors different from normal methods? • How are constructors similar?

  18. Defining a Constructor • Here is a constructor for the BankAccount class: • publicBankAccount(double Balance); • Theaccess specifier • Themethod name • A list of any Parameters, enclosed in parentheses. • Which normal part of a method signature is missing here?

  19. Another Constructor • publicBankAccount(); • How is this different from the last Constructor? • Could we use both in the same Object?

  20. Summing Up: Constructors • All MUST have the same name, and that name MUST be the same as the class it’s constructing. • Have NO return type (not even void). • Are used to give a newly created object its initial values. • Can have multiple (overloaded) constructors per object.

  21. What Is That “public” Bit? • The access specifieris what lets us specify who can get in to our black box and how. • public means that anyone can see that method or constructor. • Together all these pieces marked public make up the public interface. • When someone wants to use our Object, these are the handles they have available to manipulate it.

  22. A Note on Public Interfaces • Do users of your Object need to know the details of how your object works? • Does that mean that they don’t need to know anything beyond the method name, parameters and return type?

  23. COMMENTING!! • Commenting the public interface is really important. Why? • ALL methods should start with something like the following: /** A one sentence description of your method. @param and @return */

  24. A Helpful Suggestion • Which should come first, the comment or the method? • Why?

  25. How Often Should You Comment? • What is the purpose behind commenting? • What technique best supports that purpose?

  26. This Often. • Every class • Every method • Every parameter • Every return • This isn’t Mr. Ahronheim being picky. That’s standard JavaDoc Guidelines.

  27. Your Choice, But… • Remember: • Does it hurt to have a few too many comments in a simple method? • What about not enough comments in a tricky one?

  28. Instance Fields • Sometimes, our object needs to store information for use by several methods. • What happens if we declare the variables in a method?

  29. Remember Scope! • To make sure that these instance fields (a specific kind of variable) don’t die before we’re done with them, we have to declare them in the code block we want them to survive in.

  30. Instance Fields • An Example: public class BankAccount { privatedoublebalance; … } • Why didn’t I give the field an initial value?

  31. Difference Between a Field and a Normal Variable? • Fields: • Normal Variables:

  32. Looking at the Example: • From before: privatedoublebalance; • Access specifier, usually private. • Variable type (not a return type). • Field name, just like a method name. • Why should the access specifier almost always be private?

  33. Give Whoever Said “Encapsulation” a Prize! • That’s right! Encapsulation! • What is the job of the instance fields? • Should that be part of the public interface? • Does the user of an object have any business tinkering with instance fields directly?

  34. Private Means Private! • Using non-private instance fields is a violation of Object Oriented Programming. • What are some reasons why it’s not a good idea to allow direct access to your instance fields?

  35. More Encapsulation • Not only do private instance fields prevent access by other methods, they also mean that each object has it’s own copy of each field. • What does that mean when one instance is modified?

  36. A Guideline • Always make instance fields private. • If you make your fields public:

  37. Baby’s First Constructor • After the fields are declared, it’s time to make at least one constructor. Start with the declaration and move forward. //Constructor with no parameters publicBankAccount(); { //What goes here? }

  38. Baby’s Second Constructor • What if we want to include a starting balance in our constructor? publicBankAccount(double initialBalance); { //What goes here? }

  39. What Have We Got So Far? • We now have two constructors. One takes a double as a parameter, one takes no parameters at all. • What are some potential calls that will use these constructors?

  40. Baby’s On a Roll. How ‘Bout a Method? • Let’s talk about what happens when someone wants to deposit some hard earned $$ into our little “bank”. • Let’s write a signature for the deposit method:

  41. Now Let’s Write the Method! /** Deposits money into our Account. */ publicvoiddeposit(double depAmount) { }

  42. Let’s Do Withdraw Now /** Withdraws an amount from the account.*/ publicvoidwithdraw(double withAmount) { }

  43. And an Accessor for Good Measure /** Checks the account balance */ publicdouble checkBal() { }

  44. The Return Statement • When the program hits a return it will immediately deliver the returned item as the result of the method (even if the thing returned is void). • While void methods MAY include return statements, every other method MUST ensure that it is IMPOSSIBLE to hit the end of the method without hitting a return statement that returns the correct type.

  45. Where to Begin • Step 1: • What is the object supposed to do? • What methods do we need to provide? • Step 2: • What is the public interface going to look like? • Match names and parameter types to those required (if applicable).

  46. Then… • Step 3: • Write the method signatures for the required methods and constructors. • Comment, comment, comment. Before you write even one more line of code, comment each method. • Step 4: • Figure out which instance fields you need. • Comment each one to keep track of each field’s purpose.

  47. Finally: • Step 5: • Actually write code. • Fill in the constructors and methods so that they accomplish the tasks laid out in your comments. ( You did put that in your comments, right?) • Step 6: • Test your class. • Write a short test class with a main() method that creates an object of your class and ensures that each method performs correctly.

  48. Something To Notice • Up until step 6, there was no mention of our good friend: • public static void main(String[] args) • Each program needs only one main method. • Most object will not be a whole program by themselves, so they don’t need to be independent.

  49. Creating a Test Class • If we make an object without a main() method, we still need to test the object. • Let’s look at an example!

  50. Testing Objects • Remember to test each method and check the output each time to make sure that nothing unexpected is happening. • Don’t be nice to your object! Throw it curveballs and see how it handles them (if it’s supposed to be an int, try negative numbers, floats, chars, and even nothing at all). • The tougher you test your own objects, the less likely it is that some annoying user will be able to break it.

More Related