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

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
• 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 programs 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
(Contd)

• 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 (Contd)

• Debugging methods
• You should examine the values of a methods
  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.