Design Goals and Principles of Object-Oriented Programming

The fundamental goal of dealing with the complexity of building modern software naturally gives rise to several sub-goals. These sub-goals are directed at the production of quality software, including good implementations of data structures and algorithms. The article focuses on discussing design goals and principles of Object Oriented Programming.

OOP goals:

The three goals of Object Oriented Programming are Robustness, Adaptability, and Reusability.

1. Robustness

Every good programmer wants to produce software that is correct, which means that a program produces the right output for all the anticipated inputs in the program’s application. In addition, we want the software to be robust, that is, capable of handling unexpected inputs that are not explicitly defined for its application.

• For example, if a program is expecting a positive integer (say, representing the price of an item) and instead is given a negative integer, then the program should be able to recover gracefully from this error. A program that does not gracefully handle such unexpected errors can be embarrassing for the programmer.
• More importantly, in life-critical applications, where a software error can lead to injury or loss of life, software that is not robust is deadly. This importance was driven home in the late 1980s in accidents involving Therac-25, a radiation-therapy machine, which severely overdosed six patients between 1985 and 1987, some of whom died from complications resulting from their radiation overdoses. All six accidents were traced to software errors, with one of the most troubling being a user-interface error involving unexpected inputs (a fast-typing radiologist could backspace over a radiation dosage on the screen without the previous characters actually being detected from the input).

The goal of robustness goes beyond the need to handle unexpected inputs, however. Software should produce correct solutions, even given the well-known limitations of computers. For example, if a user wishes to store more elements in a data structure than originally expected, then the software should expand the capacity of this structure to handle more elements. This philosophy of robustness is present, for example, in the vector class in C++’s Standard Template Library, which defines in the expandable array. In addition, if an application calls for numerical computations, those numbers should be represented fully and should not overflow or under-flow Indeed, software should achieve correctness for its full range of possible inputs, including boundary cases, such as when an integer value is 0 or 1 or the maximum or minimum possible values. Robustness and correctness do not come automatically, however, they must be designed from the start.

2. Adaptability

Modern software projects, such as word processors, web browsers, and Internet Search engines, typically involve large programs that are expected to last for many years. Therefore, software needs to evolve over time in response to changing conditions in its environment.

• These changes can be expected, such as the need to adapt to an increase in CPU or network speed, or they can be unexpected, such as the need to add new functionality because of new market demands.
• Software should also be able to adapt to unexpected events that, in hindsight, really should have been expected, such as the coming of a new millennium and its effects on date calculations (the “the year 2000” problem).
• Another important goal of quality software is that it achieves adaptability (also called evolvability). Related to this concept is portability, which is the ability of software to run with minimal change on different hardware and operating system platforms. The fact that different implementations of C++ are allowed to implement some language features differently, such as the number of bits in a long integer, makes portability difficult to achieve.

3. Reusability

Going hand in hand with adaptability is the desire that software is reusable, that is, code should be usable as a component of different systems in various applications. Developing quality software can be an expensive enterprise, and its cost can be offset somewhat if the software is designed in a way that makes it easily reusable in future applications. Such reuse should be done with care, however. One of the major sources of software errors in the Therac-25 arose from the inappropriate reuse of software from the Therac-20 (which was not designed for the hardware platform used with the Theme-25). So, for software to be truly reusable, we must be clear about what it does and does not do. Given this clarity, however, software reuse can be a significant cost-saving and time-saving technique.

Following these goals will help any developer build good and efficient software and products which can help the community.