The whole basis of OOP is the object, which is a combination of data and the methods that act on the data.
Procedures in an object are referred to as methods, while data is referred to as member data.
This merger of data and methods is known as encapsulation, and provides a means of more accurately modeling real-world objects.
Benefit of Objects:
To get a better grasp of the benefit of objects, think for a moment about the common characteristics of real-world objects.
Object-Oriented Technology
Objects are key to understanding object-oriented technology. In your own life you will find many examples of real-world objects:
your stuffed panda, your desk, your television set, your jet ski. Real-world objects share two characteristics: They all have
state
and behavior.
Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Bicycles also have state (current gear, current pedal cadence, current speed) and behavior (changing gear, changing pedal cadence, applying brakes). Identifying the state and behavior for real-world objects is a great way to begin thinking in terms of object-oriented programming. Take a minute right now to observe the real-world objects that are in your immediate area. For each object that you see, ask yourself two questions:
What possible states can this object be in? and
What possible behavior can this object perform?
As you write down your observations, you will notice that real-world objects vary in complexity; your desktop lamp may have only two possible states (on and off) and two possible behaviors (turn on, turn off), but your desktop radio might have additional states (on, off, current volume, current station) and behavior (turn on, turn off, increase volume, decrease volume, seek, scan, and tune). You may also notice that some objects, in turn, will also contain other objects.
These real-world observations all translate into the world of object-oriented programming.
Key Difference between OO and Procedural Programming
In object-oriented (OO) programming, an application consists of a series of objects that request services from each other. Each object is an instance of a class that contains a blueprint description of all the object's characteristics. Contrary to procedural programming, an object bundles both its data (which determines its state) and its procedures (which determines its behavior) in a coherent way. An example of this could be a student object having data elements such as
ID,
name,
date of birth, and
email address.
and procedures such as registerForCourse, isPassed, and so on.
A key difference between OO and procedural programming is that
OO uses local data stored in objects,
whereas procedural programming uses global shared data that the procedures can access directly.
This has substantial implications from a maintenance viewpoint. Imagine that you want to change a particular data element (rename it or remove it). In a procedural programming environment, you would have to look up all procedures that make use of the data element and adapt them accordingly. For huge programs, this can be a very tedious maintenance exercise. When you are using an OO programming paradigm, you only need to change the data element in the object's definition and the other objects can keep on interacting with it like they did before, minimizing the maintenance. OO programming is the most popular programming paradigm currently in use. Some examples of object-oriented programming languages are Eiffel, Smalltalk, C++, and Java.
Classes represent Templates
A class is a template, or specification, that defines a type of object.
In programming terms, an object is a self-contained component that contains properties and methods needed to make a certain type of data useful.
The properties of an object are what it knows and its methods represent the services it can provide. In addition to providing the functionality of the application, methods ensure that an object's data is used appropriately by running checks for the specific type of data being used. They also allow for the actual implementation of tasks to be hidden and for particular operations to be standardized across different types of objects. You will learn more about these important capabilities in Object-oriented concepts: Encapsulation. Objects are the fundamental building blocks of applications from an object-oriented perspective and provide a blueprint.
Objects in Java: Let us now look deep into what are objects. If we consider the real-world we can find many objects around us, Cats, Dogs, Humans, etc. All these objects have a state and behavior. If we consider a cat, then its state is
name,
breed,
color,
and the behavior is purring, sleeping, running. If you compare the software object with a real world object, they have very similar characteristics. Software objects also have a state and behavior. A software object's state is stored in fields and behavior is shown via methods. So in software development, methods operate on the internal state of an object and the object-to-object communication is done via methods.
Classes in Java: A class is a blue print from which individual objects are created. A sample of a class is given below:
public class Cat{
String breed;
int age;
String color;
void purr(){
}
void hungry(){
}
void sleeping(){
}
}
Goals, Principles, and Patterns
As the name implies, the main "actors" in the object-oriented paradigm are called objects. Each object is an instance of a class and each class presents to the outside world a concise and consistent view of the objects that are instances of this class, without going into too much unnecessary detail or giving others access to the inner
workings of the objects. The class definition typically specifies the data fields, also known as instance variables, that an object contains, as well as the methods (operations) that an object can execute. This view of computing fulfill several goals and incorporates design principles, which we will discuss in this chapter.
Every good programmer wants to develop 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 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 (perhaps 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. More importantly, in life-critical applications, where a software error can lead to injury or loss of life, software that is not robust could be deadly.
Therac-25, Radiation-therapy machine and SW Development
This point 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 overdose. All six accidents were traced to software errors. This machine was designed from the outset to use software based safety systems rather than hardware controls. The removal of these hardware safety measures had tragic consequences, as race conditions in the codebase led to the death of three patients, and caused debilitating injuries to at least three other patients.
The manufacturer (AECL) Atomic Energy of Canada Limited became the target of several lawsuits from families of the victims, and became subject to a Class I recall from the FDA, a situation which only happens if the agency believes there is significant risk of death or serious injury through continued use of a medical device.