Software applications tend to be very large, expensive, and complex to create. There also tend to be changing requirements encountered during their creation (due to changes in marketplace conditions, new offerings from competitors, and additional demands from customers) and new problems that were not foreseen in the design stage. Even after software has been created, the debugging of code tends to take more time than the original coding itself, and need for revisions and improvements may also be expected. Typical software systems are so large and complex that no single individual has a holistic view that takes in every detail. To build such systems, it is essential that there be some way to break down the task into manageable parts that allow there to be a cooperative effort by a team of developers. Practices and tools that work well for a solo programmer often do not work well for large teams.
The goal of software development is to produce software that is useful, delivered in a timely fashion, reliable, maintainable, reusable, user-friendly, and efficient. The practice of software development requires two parts: the model, which is an abstraction of some problem or aspect of a part of the real world, and the algorithm, which describes a well-defined process for solving the problem that has been encapsulated in the model.
In the early days of software development, the main focus was on development of algorithms that were efficient, and the models received less attention. Early software development efforts chose to focus on computation, and were based on control flow. Later on, other efforts tried the opposite perspective, choosing to focus primarily on the data flow, while computation was relegated to a secondary place. All these efforts were handicapped by the lack of a viable model.
As developers realized that more attention needed to be given to the model, different efforts began to be made that took on a balanced perspective of the data and computation aspects, and also helped provide techniques to optimize software development. The most important achievement in this regard was the development of the object-oriented model, which consists of objects, each having data and making computations. Exceedingly large software systems which have complex interactions among their constituent parts can be described in the object-oriented model, based on the structure of the objects, classes, and the relationships between them.
Objects and classes are fundamental to object-oriented programming. Each has a representation in the model, and an interpretation in describing something in the real world. An object represents something in the real world that has a distinct nature and function. In the model, the object is entity with a unique identity, a distinct set of possible states, and well-defined behaviors. A class is a set of objects that are similar in nature; all objects belonging to a certain class are called instances of that class. In the model, a class is characteristic of the states and behaviors that all its instances share.
The state of an object is given by its fields (also called attributes), and their existing values. The behavior of an object is defined by its methods, which may read or change the state. The state and behavior of an object are together called its features.
A class serves as a template to allow creation of instances, i.e., objects (the terms "object" and "instance" are often taken to be interchangeable in this context). Instead of defining individual objects, programmers define the feature of the classes of these objects
The principle of modularity is central to object-oriented programming. Modularity is simply the style of analysis which requires that any complex system be broken down into a set of cohesive but independent modules which can each be analyzed and developed independently of the others. In order to achieve modularity, two aims are sought after: abstraction and encapsulation.
Abstraction is simply the characterization of the essential functional aspects of a module, leaving out any details that don't have to be known to users of the module. A precise description, commonly called the contractual interface for the module, has to be generated. A contractual interface is merely a means of capturing the behavior of the module while leaving its inner workings implicit and undescribed. For instance, such an interface for a telephone would simply say that if one lifts the handset of a functional phone instrument and dials a number on the keypad, a call will take place, which can be terminated by hanging up. This is the only level of detail that common phone users need to know, and inner workings of phone instruments or the phone system do not have to be part of their understanding.
Encapsulation is a closely related principle that says that the implementation of a module should be kept completely distinct from its contractual interface, and should be hidden from clients of the module. In our example, we could say that the workings of the phone should be kept separate from the instructions for using the phone. This principle is also called information hiding, and is important in helping software developers from becoming overloaded with irrelevant detail.
In object-oriented development, the practice is to split the task of building a complex software system into many modules that interact in a specific way. The design of these modules says nothing about how the modules are to be implemented, but just specifies how they are to behave. Each developer (or team of developers) works on a certain module that has to perform exactly as per the requirements specified of its contractual interface. Developers know nothing of others' modules save what is stated in their contractual interfaces; this information suffices even if they have to use other people's modules in their own work. The inner workings of each module are thus known only to the people working on that particular module. Finally, when all the modules are ready, it is possible to put them together to obtain the final system.
Other important concepts in object-oriented programming that may be mentioned include:
Inheritance--This defines a relationship among classes, so that a class may "inherit" from another class, in which case it is called a subclass and uses the implementation of its superclass.
Association--This represents general binary relationships among classes, such as relationships among classes titled "Employee" and "Pay."
Sequence Diagrams--These are used to show object interaction by showing the time order of method invocations.
Unified Modeling Language (UML)--This is a graphical notation for describing object-oriented systems, developed jointly by the "three amigos" of software engineering: Grady Booch, Ivar Jacobsen, and James Rumbaugh.
This is the complete article, containing 1,078 words
(approx. 4 pages at 300 words per page).
