1. Principles of Programming

2. Achieving an Object-Oriented Design  Abstraction and Information Hiding  Object-Oriented Design  Functional Decomposition  Using UML to Model Designs  Advantages of an Object-Oriented Approach

3. Abstraction and Information Hiding  Procedural Abstraction  Data Abstraction  Information Hiding

4. Procedural Abstraction  Separates the purpose of a method from its implementation.  Specifies what a method assumes and what it does, but not how it does it.  You can change how a method works without having to change the methods that use it.  Allows you to use code written by others without having to study the code.

5. Data Abstraction  A collection of data and a set of operations on the data (abstract data type).  You can use the operations, if you know their specifications, without knowing how they are implemented or how the data is stored.

6. Information Hiding  The hiding of implementation details, especially relating to how data is stored, from external access.  As a user of a module, you do not need to worry about the details of implementation, and as an implementer of a module, you do not need to worry about its uses.

7. Object-Oriented Design  Classes, Objects, and Instances  Encapsulation  Inheritance  Polymorphism

8. Objects, Classes, and Instances  The objects in a problem environment are the things that get used, created, and/or manipulated.  A class is a template for a collection of objects that are similar or of the same type.  An instance is a specific member of a class.

9. Encapsulation  It is the combining of data and operations on that data.  It is a mechanism that helps with information hiding because it hides the inner details of the implementation from external modules.

10. Inheritance  The properties of a class can be inherited from another class.  This allows you to reuse classes defined earlier for different purposes with appropriate modification.  In the new class some of the methods can be modified and new ones can be added.

11. Polymorphism  This is a mechanism that enables determination to be made at execution time as to which method is the right one to use based on the type of objects operated on.  For example, the + operator between two numbers means addition, but between two strings it means concatenation.

12. Functional Decomposition  The successive refinement of function into more specific functional elements.  It is the breaking down of a complex task into more manageable single-purpose tasks and subtasks.  This is also referred to as top down design.

13. Using UML to Model Designs Class Diagram Example: Clock -hour: integer = 12 -minute: integer = 0 -second: integer = 0 +setTime(in hr: integer, in min: integer, in sec: integer) -advanceTime() +displayTime() {query}

14. Advantages of an Object- Oriented Approach  Although extra time and effort is required when using object-oriented programming (OOP), it is usually worth it.  After you identify the classes needed for your problem and how they interact with each other, you can focus on one class at a time which simplifies implementation.  Once you have implemented a class, it is much easier to implement similar classes since you can inherit properties. (reuse)  You can make a change to an ancestor class and affect all descendant classes.

15. Key Issues in Programming  Modularity  Modifiability  Ease of Use  Fail-safe Programming  Style  Debugging

16. Modularity  Modularity has a favorable impact on: Constructing the program Debugging the program Reading the program Modifying the program Eliminating redundant code

17. Constructing the Program  Because the modules are independent writing one large modular program is not much different from writing many small, independent programs.  Modularity permits team programming where several programmers work independently on their own modules before combining them into one program.

18. Debugging the Program  The task of debugging a large program is reduced to the task of debugging many small programs.  If you thoroughly test modules as you go along, you can be almost sure that newly found bugs are in the newest module introduced.  Modular programs are more amenable to formal methods of verification.

19. Reading the Program  Just as modularity helps the programmer to deal with the complexity of the problem, it also helps the reader to do the same.  A modular program is easy to follow because the reader can get a good idea of what is going on without reading any code.  A well-written can be understood fairly well just from its name.

20. Modifying the Program  A small change in requirements will likely require modification of only one or a small number of modules.  With modularity you can reduce a large modification into a set of small and relatively simple modifications.

21. Eliminating Redundant Code  You can identify a computation that occurs in many places in your program and implement it as a method.  This improves both readability and modiyfiability.

22. Modifyiability  The use of methods, e.g., creating a sort method rather than embedding the code in the main body of the program, makes a program easier to modify.  Using named constants, e.g., for the number of students in the class, can make a program that processes information about members of the class easier to modify if that number changes.

23. Ease of Use  In an interactive environment, the program should always prompt the user for input in a manner that makes it clear what is expected.  A program should always echo its input.  The output should be well labeled and easy to read.

24. Fail-Safe Programming  A fail-safe program is one that will perform reasonably well no matter how anyone uses it.  You need to try to anticipate how people might misuse the program and guard against these abuses.  There are two main types of errors to guard against: Errors in input data Errors in logic

25. Style  Five issues of style 1. Extensive use of methods 2. Use of private data fields 3. Error handling 4. Readability 5. Documentation

26. Extensive Use of Methods  If a set of statements performs an identifiable, recurring task, it should be a method.  The use of methods is cost effective even if it adversely affects performance because of the human effort saved.

27. Use of Private Data Fields  You should hide the exact representation of data fields of an object by making them private.  This supports the principle of information hiding.  Use accessor and mutator methods to access and change the data values of an object.

28. Error Handling  In most cases a method should return a value or throw and exception instead of displaying an error message when a problem is encountered.

29. Readability  For a program to be easy to follow, it should have: A good structure and design A good choice of identifiers Good indentation and use of white space Good documentation

30. Identifier Conventions User-defined identifiers are both upper- and lowercase letters as follows: Class names are nouns, with each word in the identifier capitalized. Method names are verbs, with the first letter lowercase and subsequent internal words capitalized. Variable names begin with a lowercase letter and subsequent internal words capitalized. Named constants are entirely uppercase and underscores are used to separate words.

31. Indentation Style  Use blank lines to offset each method.  Indent individual blocks of code visibly and offset them with blank lines.  Indentation should be consistent.  Try to avoid rightward drift.

32. Indentation Style  With regard to braces ({, }) there are two acceptable styles. 1. Put the opening brace at the end of the line that begins the compound statement and the closing brace should be on a line by itself, lined up with the with the beginning of the line that begins the compound statement. 2. Put the opening brace on a line by itself immediately following and lined up with the beginning of the line that begins the compound statement. The closing brace is as above.  Braces should be used around all statements, even single statements, when they are part of a control structure.

33. Documentation  A program should be well documented (commented) so that others can read, use, and modify it easily.  You should comment your code as you go along, not just as a last step.  You may be the one who benefits most from your own documentation.

34. Essential Features of Program Documentation 1. An initial comment for the program that includes: a. Author and date b. Description of the program’s input and output c. Description of how to use the program d. Assumptions such as the type of data expected e. Statement of purpose f. Statement of exceptions, that is, what could go wrong g. Brief description of the major classes

35. Essential Features of Program Documentation (Cont’d) 2. Initial comments in each class that state its purpose and describe the data contained in the class (constants and variables). 3. Initial comments in each method that state its purpose, preconditions, postconditions, and methods called. 4. Comments in the body of each method to explain important features or subtle logic.

36. Debugging  Programs that are modular, clear and well documented are generally easier to debug.  Fail-safe techniques are also a great aid to debugging.  Use System.out.println statements as necessary.

37. Debugging (Cont’d)  Debugging methods: You should examine the values of a method’s arguments at its beginning and end.  Debugging loops: You should examine the values of key variables at the beginnings and ends of loops,  Debugging if statements: Just before the if statement you should examine the values of the variables within its expression.  Remember to either comment out or remove debugging code inserted.