I encourage you to search in the web, there are tons of information about this topic, as it is one of the most used programming paradigms since many years.
Object oriented programming is more natural. It is near to real world due to implementation using class and object. Entities are implemented using objects and characterized using classes. Important features are: Abstraction, Encapsulation, Inheritance, Polymorphism, Data hiding
Object oriented programming is especially valuable if it is combined with object oriuented design, which implies that users are invited to think in objects
If you define "characteristic features" as features only found in OOP, then I'd say that inheritance is the characteristic feature of OOP. Abstraction, Encapsulation and Polymorphism can be easily achieved in other non-OOP languages.
It is possible to write programs, with an Object Oriented language, that are not Object Oriented because they do not use Abstraction, Encapsulation, Inheritance and Polymorphism. So this four features are needed for a program to be considered Object Oriented. Consider for example a Java program with classes that have public attributes and only static methods, not using object instance. Even if inheritance is used it is difficult to say that such a program is object oriented.
For being considered object Oriented a system have to use entities identified as objects, abstracted from the problem domain and encapsulated in classes. Introducing Inheritance, as appropriated (i.e. where a is-a relationship is present), or composition and leveraging on Polymorphism, increase the quality of the implemented solution.
Moreover, in my opinion, there are also other features to be considered. Dynamic binding, or late binding, is also a required feature of the supporting language that influences the object orientation of a program, enabling the application of Liskov Principle. Interaction between object instances, with message exchange, is also a feature needed. Finally object instantiation, identity, state and destruction have to be present.
Concluding, I believe that Object Oriented Programming is a methodology for implementing systems that is based on abstraction of entities (objects), which data and behaviour are encapsulated in classes, that can be extended (their base behaviour can be modified, Inheritance) and with particular behaviour that are decided at run-time through a late binding of the correct code (Polymorphism). This entities (objects) have to interact one with the other, through message exchange (methods invocation) and have an identity, a state and a lifetime.
Encapsulation – Encapsulation is capturing data and keeping it safely and securely from outside interfaces.
Inheritance- This is the process by which a class can be derived from a base class with all features of the base class and some of its own. This increases code reusability.
Polymorphism- This is the ability to exist in various forms. For example an operator can be overloaded so as to add two integer numbers and two floats.
Abstraction- The ability to represent data at a very conceptual level without any details.
Some other Characteristic of OOP
Some key features of the Object Oriented programming are:
- Emphasis on data rather than procedure
- Programs are divided into entities known as objects
- Data Structures are designed such that they characterize objects
- Functions that operate on data of an object are tied together in data structures
- Data is hidden and cannot be accessed by external functions
- Objects communicate with each other through functions
- New data and functions can be easily added whenever necessary
The crucial difference with the traditional programming method is, that your code is much better manageable and re-usable. If you write a piece of code the old-school (procedural) way, and you want to re-use your code, then you can put that code in a subroutine or function. That's basically it.
Object Oriented Programming allows you to put the code into a "class" -- the basic building block and blueprint of an object. Very much like the blueprint of a house, or the genetic code of an organism.
Once you need the object again, you instantiate it: you create an instance of it. Like creating an instance of a class "dogs", named "Fluffy". The instance is called an object, because it has it's own properties and methods. These are defined by its class, the blueprint. Properties are things that objects have, methods are things objects can do.
Objects also have their own "state", the condition their properties and methods are in. An object is completely self-contained and needs nothing else. Sure, classes can be dependent on other classes, and usually are. But the objects are autonomous abstractions.
And here is where the fun begins: if you need a dog with two tails, you simply extend the class "dogs" with a new property "2nd tail". Next, you instantiate the extended class into an object, and ba-da-boom , you have a dog with two tails. Your dog with two tails inherits all the properties and methods of a normal dog. The only thing you did, is to define the characteristics of its second tail. Now is that magic, or what?
The real strength of Object Oriented Programming is, that you can very easily re-use code to build new code. And the good thing is, that you do not need to know much about a class' inner workings. That is all hidden from the outside world. You only need to know a class' name, its methods and its properties, and away you go.
Personally, I regard Object Oriented Programming as one of the most important inventions of our modern time. It makes very complex software manageble, extendible, and maintainable. And thereby, possible.
But hey, don't take my word for it, check it out yourself.
Object oriented programming is license for complexity and a closed coding system that require tons of documentation. While there is a place for it, my experiences tend to find processing slow and not really so re-useable. When I speak with other professional in our field, I find the same comments from them.
I once employed a programmers who took object oriented programming too seriously. The app he wrote classed an object which classed another couple objects which each classed tons of other objects. Four years later when he went back to it, he could not figure it out.
While that is an exception. I personally have acquired professionally developed objects for my projects and spent days just trying to figure out the order I had to load properties and execute methods before I would get a reliable outcome. Then if you have the source and someone else improves it, look out. Things stop working as planned. Sometimes good subroutines and functions are faster and easier to maintain.
The inheritance of implementation is only one characteristic feature of OOP. All other features like encapsulation, abstraction, polymorphism etc are taken from other paradigms, mostly from the structural and modular programming.
The main concept of OOP is "Everything is the object. The objects interact with each other by sending messages".
Look at Simula-67 language that implemented all main OOP features in 1967. Smalltalk is other good example.
Object-oriented programming (the term was coined by Alan Kay) is a programming approach whereby one creates a network of cooperating "operational models", called objects, that work together as extension of the end users' mental facilities. The idea is an outgrowth of the child development psychology ideas of Piaget. The first implementation shortly predated Kay's naming of the concept and was done by Dahl and Nygaard in an iteration of their Simula language, called Simula 67.
It has not fundamentally about classes, reuse, or productivity, and those (such as many of the posters above) who approach it wrongly from those perspectives are of course bound to be disappointed.
Object-oriented programming (OOP) is a programming language model arranged in a systematic way “well-organized” around objects rather than 'actions' and 'data' rather than 'logic'. However, it takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. So in terms of the concept of the Objects, there are four major principle “characteristic” of OOP as follows:
1- Inheritance: this is the process by which a class is derived from a base class with all features of the base class and some of its own. “It will Increase the code reusability”.
2- Encapsulation: it is for capturing data and keeping it safely and securely from outside interfaces.
3- Polymorphism: it means one name, many forms, which is the ability to exist in various forms. For example, an operator can be overloaded so as to add two integer numbers and two floats.
4- Abstraction: it is used to manage complexity. Software developers use abstraction to decompose complex systems into smaller components, however, it has the ability to represent data at a very conceptual level without any details.
Other characteristics of OOP are:
1- Class definition: Basic building blocks OOP and a single entity which has data and operations on data together
2- Objects: The instances of a class which is used in real functionality, its variables and operations
3- Generic classes: Class definitions for unspecified data which is known as container classes. They are flexible and reusable.
4- Class libraries: Built-in language specific classes
5- Message passing: Objects communicates through invoking methods and sending data to them. This feature of sending and receiving information among objects through function parameters is known as Message Passing.
6- Method: Also it is known as a message in OOP, which is a procedure associated with an object class. An object is made up of behavior and data. Data is represented as properties of the object and behavior as methods.
Based on all these characteristic, the key features are listed as follows:
1- It emphasis on data rather than procedure
2- The new data and functions can be easily added whenever necessary
3- Programs are divided into entities known as objects
4- Data Structures are designed such that they characterize objects
5- Data is hidden and cannot be accessed by external functions
6- Functions that operate on data of an object are tied together in data structures
7- Objects communicate with each other through functions
The characteristics of programming objects directly affect the data and its handling process through encapsulation, reusability, subclasses, methods, polimosfirmos, abstraccion among others. This makes this type of programming is manipulable objects in your source code for handling methodologies agile software development
An important feature of oop is the shift from focusing on the design of functional decompotion to focusing on class structure design for domain decomposition. Thus, functional decomposition is done according to the class structure following EXPERT pattern. You do not get reusability by default but you design reusability. Obviously, oop is not good for programming all kinds of applications.
@article{DBLP:journals/fac/ZhaoLLQ09,
author = {Liang Zhao and
Xiaojian Liu and
Zhiming Liu and
Zongyan Qiu},
title = {Graph transformations for object-oriented refinement},
@Loay Aladib: The class concept is defined in only class based OOP languages. An other OOP language set is prototype based OOP languages such as java script.
Zhiming Liu — what you describe is "class-oriented programming," which is a weak evolution from object-oriented programming and, while somewhat related and often confused with OO, it is not the same.
Experts in reusability (such as Will Tracz) note that reuse is not a design desideratum but can be a consequence of good design. The most reused artefacts to this day are probably still the primitives in the C library. Many OO artefacts designed to be reused are in fact rarely used, and to be reused, they must first be used. (My corporate reuse repository contained code that didn't even compile, but the people who put it there were rewarded for contributing reusable code.)
There is a lot of formal definition in the answers: encapsulation, inheritance, polymorphism, abstraction, interfaces, delegation.. etc. This is all good and in fact a feature set of any language that 'is' OO. OO languages, in general, contain all the tools to implement the 'one definition rule', i.e., you write it once and re-use it. OO design is something of an art; it's deconstruction of a problem into natural globs of functionality or responsibility, which are 'objects'. Each if these objects can be thought of as it's own little computer (encapsulation), which ideally knows nothing of the outside world ( is de-coupled ), but changes it's internal state when some input causes it to do so, and on changing state informs anybody whose interested. These interactions are ideally done over 'interfaces', ie, a set of methods. As the problem becomes better understood, or changes, or it's apparent some objects share functionality, they can be brought into a hierarchy, where the parent implements the common stuff, the child objects do unique things. In such a relationship every child object 'is-a' parent. Other situations are not naturally inheritance based, but can be expressed by one object aggregating other objects in a 'has-a' relationship.
Interfaces are very powerful in that two objects can interact over this 'interface' and have absolutely no knowledge of each other, and therefor can be interchangeable with other objects that share the interface. So if objects 'A' and 'B' talk to each other over interface 'I', and object 'C' also understands interface 'I', then 'A' and 'C' can automatically talk to each other.
Does this sort of solution automatically just fall out of the problems? No, and in my experience it's a focusing effort ..is iterative. Honestly the understanding can be fuzzy at first, but the OO effort begins to crystalize over time.
The question was: what are the characteristic features of object oriented programming (OOP)?
So what characterizes OOP in regard to procedural programming?
Besides the technical aspects pointed out by my fellow posters, OOP provides a clear distinction between architects and users of objects.
Architects provide classes that once instantiated into objects, implement solutions to solve problems for users.
Users of objects do not have to know anything about the inner workings of objects, known as "state". That is provided by encapsulation. Encapsulation warrants users for the details of how objects maintain their inner state.
To consume a specific function, all an user has to know is the name of the class, required parameters (if any and whether overloading is implemented), the names of required properties to supply or to retrieve, and the names of methods to invoke. This emphasizes the necessity and importance of program documentation; as without, OOP fails.
This clear distinction between architects and users of objects has generated an immense boost to the software development industry, to the growth of the Open Source community, and the widespread availability of highly complex software products.
In my opinion, the significance of OOP cannot be overstated as well as Bjarne Stroustrup's contribution with C++.