3. OBJECT ORIENTED PROGRAMMING

This chapter under major construction.

Object oriented programming (OOP).

Since its discovery in the 1960s, the principles of OOP have influenced the discipline of programming. OOP is a paradigm that breaks a complex system into a bunch of interacting parts or objects. The basic thesis is to model real-world or abstract entities (e.g., televisions, bouncing balls, complex numbers) in software. An object stores some data (its state), provides methods to access and manipulate that data (its behavior), and represents an individual unit (its identity). For example, the state of a television set might be characterized by whether it is on or off, what channel it is tuned to, and the current volume. We can communicate with the television and change its behavior (e.g., change the channel) through the remote control. We can identify a television by its serial number.

An "object-oriented program consists of a group of cooperating objects, exchanging messages, for the purpose of achieving a common objective." Four of the most important principles of OOP are: data abstraction, modular programming, encapsulation, and inheritance. Here is an OOP FAQ.

OOP is an approach to programming that involves modeling...

Data abstraction is the principle of organizing data to permit efficient access and update in a given application context. For each abstraction that we want to implement, we must choose an appropriate data structure to efficiently support the desired operations. In scientific and engineering applications we encounter complex numbers, strings, polynomials, and matrices.
Modular programming is the act of building programs by writing lots of simple, re-usable data types, and combining them to build more complex data types. Complex matrices, rational polynomials, matrices where each entry is a ratio of two complex polynomials. We solve a problem by decomposing it into sub-problems; we build a system by composing our building blocks. Modular programs are easier to update and maintain since small changes are localized to a small number of modules. This simplifies testing, facilitates debugging, and improves reliability. It also makes code more readable to other programmers.
Encapsulation means that we should organize programs as collections of abstract data types. Each ADT hides its internal representation to de-couple the implementation from the specification and client. This enables us to use a (universal) remote control with different types of televisions.
Inheritance is a mechanism to create an ADT by specifying only its difference from a related ADT. This enables us to build programs incrementally and avoid duplicate code. This is especially useful when dealing with Java's built-in libraries for which you do not have the source code and cannot modify. It is also an excellent way to organize libraries for use by others.

Engineering.

Engineering involves the design, implementiation, and analysis of a useful solution to a practial problem. The design is limited by resoruce constraints including time, money, usability, flexibility for future modification, maintainability, safety, aesthetics, marketing, and ethics. The analysis models how well the design will perform and whether it will be the project constraints. Prototyping, testing, simulation are all components of a proper analysis. Designing quality software is similar in many ways to designing bridges. "A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible." -- Freeman Dyson. When programming, use the priniciple of least surprise.

Software engineering.

Programming is a form of engineering: apply computer science to the benefit of humankind. Unlike other forms of engineering (which have been around for hundreds of years), software engineering is very young (~30 years) and no widespread consensus on best practice and engineering standards. Nevertheless, some key ideas have emerged (modular programming, data abstration, encapsulation). OOP is one of the main tools for building complex programs. We will also consider other software engineering aspects that complement OOP including specification, design, coding, and testing. a computer program to solve a problem. Testing, unit tests (testing smallest compilable element in isolation), integration tests (testing several interacting modules), functional tests tests, regression testing... Test characteristics: functional (does it do what it should do, and not do what it should not), performance, usability, security, etc.) Test detail: unit test (one xxx), integration (several interacting modules), system (the whole thing). Test access: black box (treat module as a black box), white box (use internal structure to determine test cases). Each test should return true or false. Specification is often the biggest source of errors. Compile-time, run-time, and logic errors. Compiler error messages can be cryptic, but usually can be resolved after a few minutes. On the other hand logic errors are the bane of programming. Can take hours to days to discover the error, even if it was just a simple typo. We should be thankful of all the errors that the compiler discovers, and it is a blessing to use a language and compiler that facilitate discovering errors at compile time.

In practice, companies hire employees to solely perform testing. Ratio of testers to programmers can range from 10:1 to 1:10.

Fred Brooks hypothesises that the number of lines of code a programmer writes per day is about the same, regardless of which language they use (Java, C, machine language). One of main goals of using a higher level programming language (e.g., Java) and OOP is so that we can write 10 lines of Java code that replaces 1,000 lines of machine language code. Another goal is to write programs that are easier to debug than machine language programs. OOP helps address both goals.

Software life-cycle. Analysis and specification, design, construction, testing, operation, maintenance. Waterfall model: do all of the tasks in sequence, reaching decisive milestones along the way. (Inflexible, especially if design is wrong.) Prototype model: build quick prototype, evaluate, and redesign if needed. (harder to manage and throw away previous designs)

Testing. Design good test cases (especially at boundaries), test coverage (use computer to generate test inputs), unit tests, regression testing. Program should always either complete successfully or output a useful error message. Bugs in computer-aided design (CAD) program nuclear reactor control system, guided missile, spacecraft environmental control can be disastorous. Validation = checking that the software does what the customer specified (producing the right product). Verification = checking that the software has been written according to design spec (producing the product right).

Often, it's convenient to write the tests before the code. If you can't write the tests, you might need to change the inerface or specs. If you still can't, you need to spend more time thinking before you begin to write code.

Design. In many ways, designing good programs is more challenging that writing the code itself. Keep interfaces narrow.

Bugs. CMU study of 30,000 programs: 5-6 defects per 1,000 lines of code in production software. New programs: 100 defects per 1,000 lines of code. $60 million bug (misused break statement in C program) in ATT long distance system - 114 switching nodes crashed on January 15, 1990 collection of software bugs.

IN the 2000 presidential election, Al Gore received negative 16,022 votes on an electronic voting machine in Volusia County, Florida.