Why Java is important

Main thing is it is object oriented.

What do you mean by object oriented?

In computer science, object-oriented programming, OOP for short, is a computer programming paradigm.

The idea behind object-oriented programming is that a computer program may be seen as comprising a collection of individual units, or objects, that act on each other, as opposed to a traditional view in which a program may be seen as a collection of functions, or simply as a list of instructions to the computer. Each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine or actor with a distinct role or responsibility.

Object-oriented programming is claimed to promote greater flexibility and maintainability in programming, and is widely popular in large-scale software engineering. Furthermore, proponents of OOP claim that OOP is easier to learn for those new to computer programming than previous approaches, and that the OOP approach is often simpler to develop and to maintain, lending itself to more direct analysis, coding, and understanding of complex situations and procedures than other programming methods. Critics dispute this, at least for some domains (industries).

Fundamental concepts

Object-oriented programming (OOP) emphasizes the following concepts:

• Class — the unit of definition of data and behavior (functionality) for some kind-of-thing. For example, the 'class of Dogs' might be a set which includes the various breeds of dogs. A class is the basis of modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, and the code for a class should be (relatively) self-contained and independent (as should the code for any good pre-OOP function). With such modularity, the structure of a program will correspond to the aspects of the problem that the program is intended to solve. This simplifies the mapping to and from the problem and program.

• Object — an instance of a class, an object (for example, "Lassie" the Dog) is the run-time manifestation (instantiation) of a particular exemplar of a class. (For the class of dogs which contains breed types, an acceptable exemplar would only be the subclass 'collie'; "Lassie" would then be an object in that subclass.) Each object has its own data, though the code within a class (or a subclass or an object) may be shared for economy. Thus, object-oriented languages must allow code to be reentrant.

• Encapsulation — a type of privacy applied to the data and some of the methods (that is, functions or subroutines) in a class, encapsulation ensures that an object can be changed only through established channels (namely, the class's public methods). Encapsulation means wrapping up of data and associated functions into a single unit(called class). Each object exposes an interface — those public methods, which specify how other objects may read or modify it. An interface can prevent, for example, any caller from adding a list of children to any object of the class Dog.

• Inheritance — a mechanism for creating subclasses, inheritance provides a way to define a (sub)class as a specialization or subtype or extension of a more general class (as Dog is a subclass of Canidae, and Collie is a subclass of the (sub)class Dog); a subclass acquires all the data and methods of all of its superclasses, but it can add or change data or methods as the programmer chooses. Inheritance is the "is-a" relationship: a Dog is-a Canidae. This is in contrast to composition, the "has-a" relationship, which user-defined datatypes brought to computer science: a Dog has-a mother (another Dog) and has-a father, etc.

• Abstraction — the ability of a program to ignore the details of an object's (sub)class and work at a more generic level when appropriate; For example, "Lassie" the Dog may be treated as a Dog much of the time, but when appropriate she is abstracted to the level of Canidae (superclass of Dog) or Carnivora (superclass of Canidae), and so on.

• Polymorphism — polymorphism is behavior that varies depending on the class in which the behavior is invoked, that is, two or more classes can react differently to the same message. For example, if Dog is commanded to speak this may elicit a Bark; if Pig is commanded to speak this may elicit a Grunt.

An object-based language is a language that has most of the properties of an object-oriented language, but lacks inheritance.

Matching Real World

According to some OOP proponents, translation from real-world phenomena/objects (and vice versa) is eased because of a direct mapping from the real-world to the object-oriented program (generally a many-to-one). OOP was even invented for the purpose of physical modelling in the Simula-67 programming language. However, not all proponents agree that real-world mapping is facilitated by OOP, or is even a worthy goal (Bertrand Meyer, OOSC2, pg. 230). Further, many domains, such as legal, financial, and intellectual property, have no substantial physical counterpart.

OOP as a new paradigm, point of view, and marketing term

OOP is subject to much contention as to its precise definition and its principal ideas.

In the most general terms, OOP is the practice of writing program text that is decomposed into modules that encapsulate the representation of one data type per module, instead of into collections of functions that call each other, or clauses that trigger each other. OOP concepts and practices have been brought together, with associated terminology, to create a new programming framework. Together, the ideas behind OOP are said to be so powerful that they create a paradigm shift in programming. (Other programming paradigms, such as functional and procedural programming, focus primarily on actions -- or, in logical programming, on assertions -- that trigger execution of program code.)

OOP arose independently out of research into simulation system oriented languages, with SIMULA 67, and out of research into highly secure system architectures, with capability-based OS and CPU architectures.

Some experts say that the original definition of object-orientation came from the object in grammar. The requirements for software are always subject-oriented. However, since the requirements for the subject are often complicated, subject-oriented programs end up tending to be complicated and monolithic. Therefore, as an alternative, some researchers started thinking in an object-oriented way. This represented a paradigm shift from the usual or previous subject-oriented mode of thinking.

According to object-oriented principles, the verb in a program statement is always attached to the object, and the logic associated with a requirement is likewise handled in the object. The following are some examples of the ways by which a subject-oriented requirement is translated into object-oriented thinking:

• Subject-oriented: The Sales Application saves the Transaction
• Object-oriented: The Transaction saves itself upon receiving a message from the Sales Application

• Subject-oriented: The Sales Application prints the Receipt
• Object-oriented: The Receipt prints itself upon receiving a message from the Sales Application

One distinguishing feature of OOP is the handling of subtypes of data types.

Objects' data are generally required to satisfy programmer-defined constraints (i.e., class invariants). A datatype restricted by such a constraint constitutes a subtype of the same datatype without the constraint. These constraints are then both relied upon and preserved by the actions (methods) that are defined for the data.

Data constraints may be either explicitly declared or implicitly assumed by the programmer. In either case, object-oriented languages provide mechanisms for ensuring that such assumptions or constraints remain local to one part of the program. Constraints on and assumptions about data are usually included in the documentation of object-oriented programs.

OOP itself has been used to market many products and services, and the actual definitions and benefits attributed to OOP have often been colored by commercial marketing goals. Similarly, many programming languages reflect a specific view or philosophy of OOP that is narrower and, in certain respects, less general than that embodied in the more general or standard definition.

As noted above, at the end of the previous section, widely-used terminology distinguishes object-oriented programming from object-based programming. The former is held to include inheritance (described below), while the latter does not.

The exact definitions of some of these terms show some variation, depending on point of view. In particular, languages with static typing often reflect and embody slightly different views of OO from those reflected by and embodied in languages with dynamic typing, due to a focus on the compile-time rather than the run-time properties of programs.

Note: Abstraction is important, but not unique, to OOP. Other programming paradigms employ it as well.

Reusability is the benefit most often claimed for OOP. However, that claim is unlikely to be true, as reuse of software is as old as the invention of the subroutine, reputedly prior to 1950. In fact, reuse is frequently disputed as being a primary, or even a large, benefit. The ease of translation to and from the target environment, the (improved) ability to maintain a program once written, the ability to do localized debugging, and the (improved) ability to do much larger parallel development efforts, are all cited as more significant reasons to use an OOP language.

OOP is often called a paradigm rather than a style or type of programming, to emphasize the point that OOP can change the way software is developed by actually changing the way in which programmers and software engineers think about software. And as a paradigm, OOP is about overall system design as much as it is about programming. A system is designed by defining the objects that will exist and interact within the system. Due to encapsulation, the code that actually does the work is irrelevant to an object, and to the people using the object. The challenge in OOP, therefore, is of designing a sane object system.

It should be noted that there are distinct parallels between the object-oriented paradigm and systems theory. OOP focuses on objects as units in a system, whereas systems theory focuses on the system itself. In between, one may find software design patterns or other techniques that use classes and objects as building blocks for larger components. Such components can be seen as an intermediate step from the object-oriented paradigm towards the more "real-life oriented" models of systems theory.

Actor model

OOP is a decomposition paradigm for program code, not a model for computation.

OOP is often confused with the Actor model of computation. In response to a message that it receives, an Actor can make local decisions, create more Actors, send more messages, and determine how to respond to the next message received.

Almost all OOP languages and systems, including all the major ones, such as SIMULA, Smalltalk, C++, Java, Ruby, Python, VB .NET, and C#, have message passing programming capabilities.

See Actor model implementations for a discussion on implementations of the Actor model.

In OOP the emphasis is not on how computation is organized, but on how program text is decomposed into modules, because it is this decomposition that matters as to the program text's comprehensibility and maintainability.

OOP is based on the assumption that the program text's comprehensibility and maintainability are improved by decomposing the text into modules, and that the best way to decompose it into modules is to minimize dependencies among modules and maximize the cohesion of functions inside each module, and that this is best achieved by encapsulating the representation of a data type in each module.

There are several distinct styles of object-oriented programming. The distinctions between different styles occur because different programming languages emphasize different aspects of object-oriented facilities and combine with other constructs in different ways.

OOP with procedural languages

In procedural languages, OOP often appears as a form where data types are extended to behave like a type of an object in OOP, very similar to an abstract data type with an extension such as inheritance. Each method is actually a subprogram which is syntactically bound to a class.

Static typing with the object-oriented paradigm

Many object-oriented programming languages, such as C++ and Java, have a static type systemobject-oriented design to some extent at compile-time, i.e. statically. Object-oriented facilities combine with static typing in various ways. Classes are types of objects. Many object-oriented languages provide mechanisms for statically checking the type of method parameters, types of private and public data members, types of object references and check the correctness of inheritance and subtyping relationships. Static type checking can also check API compatibility, enforce data constraints on the users of libraries created with object-oriented methods and reduce the number of type checks performed at run-time for various forms of method dispatch. that can be used to check and enforce constraints of

Some object-oriented languages, such as Eiffel, supplement the type system with assertionsinvariants of classes and the contracts of methods, though current Eiffel compilers only check these at run-time, i.e. dynamically. specifying and documenting

See Class-based OOP.

Prototype-based model

Other than using classes, prototyping is another, less popular, means of achieving object-oriented behavior sharing. After an object is defined, another similar object will be defined by referring to the original one as a template, then listing the new object's differences from the original. Perhaps the most popular prototype-based language is JavaScript, which is an implementation of ECMAScript. In prototyping systems, objects themselves are the templates, while classification systems use classes as templates for objects.

The classification approach is so predominant in OOP that many people would define objects as encapsulations that share data by classification and inheritance. However, the more generic term "behavior sharing" acknowledges alternate techniques such as prototyping.

See Prototype-based programming.

Object-based model

Object-based programming is centered around the creation of objects and their interactions, but may not have some of the key features of the class-based object-oriented paradigm such as inheritance. Such object-based systems are usually not regarded as object-oriented, because inheritance (viewing delegation as a form of inheritance) is typically identified as the core feature of OOP.