Principles of Programming

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:

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 • Extensive use of methods • Use of private data fields • Error handling • Readability • 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. • 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. • 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 • An initial comment for the program that includes: • Author and date • Description of the program’s input and output • Description of how to use the program • Assumptions such as the type of data expected • Statement of purpose • Statement of exceptions, that is, what could go wrong • Brief description of the major classes

35. Essential Features of Program Documentation (Cont’d) • Initial comments in each class that state its purpose and describe the data contained in the class (constants and variables). • Initial comments in each method that state its purpose, preconditions, postconditions, and methods called. • 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.