What is adventages of Object Oriented Programming?

20 years ago my saying was: "The advantage of OOP is: you can link the scrap of several programmers together and every individual piece of code is not capable to disrupt the operation of an other piece of code."

This is not completely true, but it indicates the approach:

OO is intended to isolate individual "functions" - as far as inter-function communication is not required and as far as hardware memory protection is available and configured appropriately.

Have a look at https://en.wikipedia.org/wiki/Object-oriented_programming

This should be able to give you a basic understanding of the concepts. AND it is supplying a lot of links about the different aspects of OO.

Regards

I guess you are asking for the advantage of OOP over... structured programming (with functions calling other functions with arguments in a top-down manner)?

OOP is the main programming paradigm these days in most languages. If you want to understand the design and use OO libraries correctly in your work, you have to know at least the basics of OOP.

If you program on a professional level one day, you will most surely need to do some OO programming and will need to know a lot more about OO design (i.e. design patterns, SOLID principles, etc.). In fact, it is so widely used since at least 15 years that the question is a little like asking "What is the advantage of the combustion engine over the horse?".  If you are programming now and plan to do so for a few more years, you just need to learn this!

Regards

the software engineering is better structured. Moreover, you can generalize the code much more. It is really a huge advantage compare to normal programming style.

Code Reuse and Recycling: Objects created for Object Oriented Programs can easily be reused in other programs.

Encapsulation (part 1): Once an Object is created, knowledge of its implementation is not necessary for its use. In older programs, coders needed understand the details of a piece of code before using it (in this or another program).

Encapsulation (part 2): Objects have the ability to hide certain parts of themselves from programmers. This prevents programmers from tampering with values they shouldn't. Additionally, the object controls how one interacts with it, preventing other kinds of errors. For example, a programmer (or another program) cannot set the width of a window to -400.

Design Benefits: Large programs are very difficult to write. Object Oriented Programs force designers to go through an extensive planning phase, which makes for better designs with less flaws. In addition, once a program reaches a certain size, Object Oriented Programs are actually easier to program than non-Object Oriented ones.

Software Maintenance: Programs are not disposable. Legacy code must be dealt with on a daily basis, either to be improved upon (for a new version of an exist piece of software) or made to work with newer computers and software. An Object Oriented Program is much easier to modify and maintain than a non-Object Oriented Program. So although a lot of work is spent before the program is written, less work is needed to maintain it over time.

The term was coined by Alan Kay to designate a style of programming, whereby people (and especially children) could extend the operational models of their minds into a personal computer that enhanced their ability to interact with the world around them. He envisioned a conceptual personal computer called the DynaBook which back in the mid-1970s was prescient in its vision of a modern-day iPad.

The idea was to program in objects that worked together in a network to solve some problem. Most modern programming languages do not in fact encourage object-oriented programming but more so class-oriented programming. The term "object-oriented" is casually used by contemporary programmers to describe class-oriented programming, though most of the slide from object-oriented programming to class-oriented programming has lost most properties of the original formulation and vision. (This may largely be because Smalltalk very early evolved to have classes, and because Dahl and Nygaard's evolution of Simula in Simula 67 was also class-oriented — though at least Nygaard, and probably Dahl, understood object-orientation). As a gross generalization, object-oriented programmers design using object interaction diagrams; class-oriented programmers use class diagrams and emphasize inheritance. Javascript today retains much of the spirit of object-orientation. Smith and Ungar's self language is another experiment in OO, as is Hewitt's Actor paradigm.

The claims about reuse, reduced maintenance cost, design discipline, and better structuring, are idealistic hopes that have never to my knowledge been demonstrated in any credible publication backed by a well-designed experiment. And those were not the goals: the goals were improved human interaction with the machine, and better ability for everyday people to control their computers. OO (and even class-oriented programming) tends to work well for interactive applications that are closely linked to cognitive and volitive processes in real-time. It is just one design tool and it excels where it excels and doesn't where it doesn't. You would still use procedural programming, for example, to calculate polynomial roots, or use the database paradigm to manage scaled data with transactions. Objects cater to neither of these (nor dozens of other) uses.

Trygve Reenskaug (inventor of MVC, which is the visual link from the OO computer to the human mind) and I have been working to restore Kay's vision, and its advantages, in a renewal of OO called Data-Context-Interaction. See: Coplien, James O., and Trygve Reenskaug. The DCI Paradigm: Taking Object Orientation into the Architecture World. In Babar, Brown, and Mishkin, eds., Agile Software Architecture, Morgan Kaufman: December 2013; Coplien, James O., and Trygve Mikkjel Heyerdahl Reenskaug. The data, context and interaction paradigm. In Gary T. Leavens (Ed.): Conference on Systems, Programming, and Applications: Software for Humanity, SPLASH '12, Tucson, AZ, USA, October 21-25, 2012. ACM 2012, ISBN 978-1-4503-1563-0, pp. 227 - 228; and Coplien, James O. Reflections on Reflection. In Gary T. Leavens (Ed.): Conference on Systems, Programming, and Applications: Software for Humanity, SPLASH '12, Tucson, AZ, USA, October 21-25, 2012. ACM 2012, ISBN 978-1-4503-1563-0, pp. 7 - 10.

The advantage is that the things that belong together are put together in code. C already allows to collect variables into structs. So, this is not always just restricted to object oriented languages. However, OO languages is not just combining variables into classes, but also all functions that are used to manipulate the class. These are the advantages of almost all implementations of object orientation.

Unfortunately, Wikipedia does not seem to distinguish between the concept of object orientation and its implementation. Their description is mostly based on implementation details. Nevertheless, it is also the way most people talk about OO because they are thinking in the concepts of their OO languages. The OO concept itself is quite simple:

Probably, there are more things to OO that I have forgotten to list. But, these are some of the more important rules. I'd like to comment on a few points.

Early implementations of object oriented languages took point 2. quite seriously. Sending a message to an object was literally sending a string which in most cases corresponded to a method name. This is still the case in some modern languages like Objective-C, for example. Here, objects can have a function to catch any message that cannot be forwarded to a method. This allows for some interesting responses instead of plain failure.

Not all OO languages make classes that obvious. There are languages which are prototype-base, like JavaScript, or where 'classes' is truly an abstract concept. I think the language is called BETA where you get new objects by cloning others. Directly after cloning they show the same behavior and are thus of the same class. After adding a method to only one of the objects they are not of the same class anymore (though we have subclassing now).

I think that point 4. is very crucial to the understanding of OO. Not every OO language uses inheritance for specialization (as if just showed with BETA above). You should learn to separate OO concepts from their implementation in OO languages. BTW, in popular OO languages it is possible to go against this OO concepts of specialization. If class A inherits from class B and you overwrite a method of class B in A, you can certainly change the behavior entirely. So, inheritance is not a bullet-proof way to guarantee specialization (see Liskov substitution principle).

There is one thing you should remember: Even though OO is helpful to solve many problems, it is not always the best way to solve a problem.

- OOP provides a clear modular structure for programs.

 - It is good for defining abstract data types.

- Implementation details are hidden from other modules and other modules has a clearly defined interface.

- It is easy to maintain and modify existing code as new objects can be created with small differences to existing ones.

- objects, methods, instance, message passing, inheritance are some important properties provided by these particular languages

-encapsulation, polymorphism, abstraction are also counts in these fundamentals of programming language.

- It implements real life scenario.

- In OOP, programmer not only defines data types but also deals with operations applied for data structures.

I do not agree with some of the previous answers. Some have mentioned maintainability, modularity, and reusability.

In a perfect world every programmer would write perfect code. However, it is quite hard to write truly reusable code. For this, you would need to write really generic code, thinking about anything somebody might wanna do with your class. In C++ this means to highly template your classes. This totally obfuscates the code and makes it hard to understand. Instead, the current trend is to say to only implement what you need in your class. This actually makes your code easy to read and easy to maintain. So, no point for code reuse in OO languages.

Modularity is nothing specific to OO languages. Some older languages which are not OO have modules. Modules make languages modular, not classes. You can see this with the motion to include modules into C++.

In the end it comes back to the programmer. Does the programmer write beautiful code that is easy to maintain. This is independent of the language. OO does not just make code more maintainable. I agree, however, that OO languages support to write better structured code.

I'm with Simon here. Let me add two things. The first problem is definitional: we have informally come to define "modular" to mean "encapsulated data and functions together." First, even that isn't unique to OO: plain old modules à la Modula2 do that. Second, as Simon pointed out, C does a perfectly good job of modularizing algorithms (and of modularizing related data).

The second problem, I alluded to before. Even if we could delineate properties germane to OO, the benefits are more the stuff of folklore than anything that should appear on a Research web site. Not a single poster above provided any citations for their claims — and with good reason. I am unaware of any research that substantiates broadly the claims being made.

That said, again, OO is good for what OO is good for. It is one of many paradigms. For more on this angle, see: https://3aec1b23-a-eadc3f87-s-sites.googlegroups.com/a/gertrudandcope.com/info/Publications/Mpd/Thesis.pdf .

And Simon, I appreciate you for a thoughtful answer.

Let me throw my $0.02 here - and I agree with much of what Simon and James have said.

Having taught for 12 yrs, and been in industry for over 30yrs, Object Oriented Programming has presented several interesting concepts that I have adopted, and others that seem to work in academia - but not in the "real world".  The encapsulation of the implementation (mentioned by others) is a critical feature, and as the user of an object I should not have to care *how* it is implemented.  Do I care that your stack object is a fixed array in memory or a linked list?  In a memory constrained environment, I might, but I also might not care if the implementation changed in the future - unless it had significantly bigger resource requirements.

Inheritance is also a big key of Object Oriented Programming.  Why re-invent the wheel if an existing object has a good enough implementation.  Extending the object is generally not an issue - in C++ you get to use virtual functions.  Other languages provide additional options.  Multiple inheritance, on the otherhand, is quite difficult - and there is no single definition of what happens should there be namespace collisions.

Performance is what suffers whenever you attempt to leverage virtual functions and or templates (C++).  Tradeoffs need to be made, and even some dynamic languages (Python/Perl) provide more than others.

For me the power of obect orientation is the flexibility of the datas structures and the ability to assign all things as an object. For example in the system we call world education grid wegrid.org - we vcan assign a university as an object, a nation and its universities as an object. or a problem based learning modality as an object. And therefore establish ontologies and semantic web structures o that we can conemplete a true world education grid and assign inputs as content created by others as an object that is accessible and also output and requests such that the grid can be a source of just in time training and a work or task system such that a  student can also sign up and be renumerated for tasks they perform in real time as the perform learing in real time.

Jerrold, nice answer. One minor quibble: Inheritance is a popular feature in class-oriented programming. Not only was it absent from the original Kay vision, but after enjoying some popularity in the 1980s it has fallen into disfavor. Deep inheritance hierarchies are viewed with disfavor (they make code more incomprehensible) and inheritance overall is not highly recommended.

There are some languages that properly separate subtyping and inheritance (Java does to a degree; .Net does a pretty good job, and you can simulate it in C++). Subtyping and inclusion polymorphism have their place, but only for the overriding of very simple methods. Methods that hijack the control thread (instead of just returning) also make it impossible (yes, full stop — its reducible to the halting problem) to reason about use case logic that cuts across objects. Given  that the original vision was for a network of communicating objects to cooperate on some operational model, this doesn't bode well for being able to understand hierarchies either of types or classes. Most contemporary practitioners recommend against heavy use of hierarchy.

Also, Jerrold — that performance suffers because of virtual functions is a myth. Many C++ compilers using virtual functions outperform the analogous case-based code in C on Whetstone and other benchmarks. Part of this owes to the type system and part to the inability to optimize switch statements in general — semantically, the are basically a cascaded set of nested if-then-else statements (and the base grammar reflects this).

A great advantage is the possibility you have to create your own data type (class), and operators for that data type. This permit an high level of abstraction, code reuse and modularization

Everything in programming bothers on the use of variables and functions ( or procedures) to process the various entities of an information system. In Procedural programming, the variables and functions are declared and used differently; thus, it becomes very difficult to match a given function to a particular entity. But in Object-Oriented programming, the variables and functions of various entities called objects are declared collectively with the use of classes so that a constructor can be used to create each of those objects. When this has been done, it  becomes very easy to manipulate each object with the command, object.method(). Therefore, in object-oriented programming, every created object exists in memory, and any of its methods (or actions) can easily be accesed with the command, object.method() so that we can easily tell which object performed a particular function. This functionality is not obtainable in Procedural Programming.

Object Oriented Programming easier to use than Procedure Oriented Programming,

OOP consist of Modules, i.e Textbox, command button etc as a function ( just draught & drop).

if we use POP more difficult, we must determine the position and the size of the Box. and determine the function & others

A lot of you have mentioned that the advantage of OO programming is that functions and variables are all in one place. I'd like to point out that there good reasons to move away from this. Currently, for the C++17 standard there is a discussion about 'unified call syntax'. This means that there should be no difference in meaning between x.f(y) and f(x,y). If a free-standing function cannot be found, look for a member of x. And if a member of x cannot be found, look for a free-standing function instead. As explained in this article http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394 the advantage would be that classes have only methods to directly manipulate the data. Everything else would be a free-standing function. Definitely you should write the free-standing functions right next to the class they refer to. And hopefully, we will also have modules in C++ one day to show that these belong together. According to what others mentioned as advantage of OO, writing code in this way would not be OO anymore. I do disagree on this. Currently, most OO languages force you to write functions and data in one place. It is not a characteristic at the heart of OO though. Readability always comes down to the programmer and not a specific paradigm or syntax.

BTW, who has seen classes with so many methods that they don't fit a single screen anymore? Is this an advantage?

In its simplest form, Object-Oriented Programming is a technique by which we can model the real world into a computer(like The Matrix). Normally, computer languages can only interpret primitive data types like int, float, string, boolean, double etc. Now, suppose you want to represent an entity in a real world, let us say a car, it is nearly impossible to represent it directly with primitive data attributes. But, we can create a class Car, and define its attributes in terms of primitive data types(color as int, tyre radius as a float, isSedan as a boolean etc.). Thus, an object of this class will hold the values for all its attributes specific to the object. Furthermore, by using the concepts of composition and inheritance, we can create child objects of the parent class(class BMW, class Mercedes etc.) and assign specific values to its attributes that will appropriately define the type of that car. Thus, OOP is a really powerful technique that can model expansive real world entities and data in a single, small computer. 

Jerry hit the nail on the head...what works a treat in academia with OO rarely translates to what is implemented in practice. The problem isn't with OO...in itself it's a thing of beauty... rather, it's in the lack of discipline and/or knowledge of the developer. Same/same with RDBMS architecture.  JM2c :) 

Simon does have a point, and he explained it very well. But what is the purpose of this question, one must say. The purpose is giving a vision to programmers to understand the ups and downs of different approaches to help them decide which approach suits the problem. What I don't see in answers here is that these two approaches are more orthogonal rather than being against each other. It means you can still use the concepts from functional programming in OOP and vice versa. 

For more details on what kind of nature they have, I suggest you to read these answers which had given to the same question as yours on stackoverflow

The following links should be useful.

It is a new style of programming methods where the unit is building the program and become class class, which contains data on the data and processes (functions) functions.

They have several names, including .. ::

1. object-oriented programming.

2. object-oriented programming.

* Object-oriented programming style.

Usually the programs of this method is complicated greatly as the division of the program into a set of key tasks and then divided into sub-tasks depending on the degree of complexity of the tasks on the main so the structural programming touts approach (from top to bottom) Top Down.

* Disadvantage of this method: structural programming. ::

1. difficult to separate the data on operations.

2. Re-create solutions and several re-use.

Allow me offer an example from my personal experience.

My first encounter with an object oriented programming language was in 1980 or thereabouts, for flight simulation.

Previously, I wrote flight simulation code in FORTRAN. My new task was to simulate not just a single airplane but the traffic around an airport and the resulting air pollution. (OK, my code was a lot less sophisticated than I make it sound. But this was more than 35 years ago, using a CDC 3300 mainframe and punch cards, so any program more than a few hundred lines in length was considered monstrously large.)

In FORTRAN, the code consisted of several subroutines. I don't remember its exact structure, but it was like, one subroutine calculating the lift, another calculating the drag, yet another subroutine performing an iteration step as the equations of motion were numerically integrated, yet another subroutine printing the results... the code structure bore little resemblance to the physics of the problem. Just messy numerical code.

Then I became acquainted with SIMULA/67, the language from which C++ borrowed concepts like classes and methods. Suddenly I could write a class representing the airplane, create an instance at a particular moment in simulation time, and just let it fly. The airplane class had its methods that calculated forces and iterated its equations of motion, and properties that kept track of its position and velocity. I didn't need to allocate arrays, fiddle with indices or anything like. I was not very good at this OO business yet (it wasn't even called OO back then) but I was learning fast. I ended up with a main loop that went like this:

while ExistsPlane do

  < ... print some stuff, read some parameters ... >

  activate new flight(<... some parameters ...>) at FlightTime

  if not lastitem then

  begin

    FlightTime := inint;

    hold(FlightTime - time - 1);

  end

  else

  begin

    ExistsPlane := false;

    hold(HaltTime - time + 0.5);

  end

end;

This felt unbelievably elegant. I didn't even need to know how many of my airplanes will be flying at any given time! Indeed, part of the implementation of the flight class was that it magically terminated itself and removed itself from memory when it left the volume of airspace that I was simulating. I've never seen anything even remotely like this in FORTRAN. It was pure magic, and I was in love with it.

Unfortunately, soon thereafter I was no longer using that particular mainframe, and I no longer had the means to use SIMULA/67. But maybe a decade and a half or so later, C++ arrived on my desktop, and suddenly I was rediscovering my lost love.

OO programming is a tool like many other programming concepts. Remember it's not the only tool in the box just one of the more important ones for some tasks. 

The primary advantage of OOP is the management of shared state. Sure, OOP has facilities for encapsulation, inheritance, polymorphism and modularity, which is covered well by Simon. But as Rasul expressed, what is the purpose of the question? What is the advantage of OOP? The advantage of OOP is the management of shared state. Take the Actor model as an example. Actors are most often discussed as exchanging immutable messages. This is exactly right. However, the Actor is an object. It is a powerful abstraction for managing shared state--a mailbox of messages. Managing state over time is very difficult. As a counter example, take a look at functional combinators based on the monad. Various monads are useful for managing state over time by "threading" state through functions. The problem is that monads are not intuitive. Done properly, such as the Actor model, encapsulating state is a better approach, but as others have said, it depends on the abstraction and its implementation.

In respect of what Simon mentioned before, I should add that modularity is a way of thinking and you can do it even in functional approach, however it's pretty obvious that the nature of OOP makes it easier to implement modularity

Modularity is not inherent to OOP. There is the class of prototype-based OO languages, like Self (see https://en.wikipedia.org/wiki/Self_%28programming_language%29). Only OO languages that use classes explicitly have modularity built in. Another well-known example for a prototype-based language is JavaScript. It does not have any modularity.

Most answers so far are only valid for a subclass of OO languages, namely those based on classes.

Most of the important points have been covered above, however let me put my views also. A  computer language is called OOP if it has following

(i) Encapsulation, (ii) Polymorphism and (iii) Inheritance

Because of Inheritance reusebility is a strong advantage of OOP.

Security and confidentiality may be used in OOP by hiding .

Big programs can be divided and developed independently. A programmer knows only information to be used in his program.

OOP is a bottom - up approach while modularity is top-down though in modularity also work can be divided and developed independently.

At certain extend, programming could be considered as a communication between an agent writing the code and one or more agents reading the code. They all interact on top of the purpose of the whole code repository. Note that a same person may play different roles. Conceptually, there is no difference between reading a code by a person different then the person that wrote the code (a spatial distance) and  the same person but after a certain time period (a temporal distance).

Obviously, for such a communication to make a sense and achieve understanding, there must be a clear shared conceptualization. Otherwise, misunderstandings can not be detected resulting in malfunctions within the system, often referred as hidden bugs. However, the conceptualization needs to be adopted by all participants in the communication in order to work. As a consequence, it needs a common language, formal and powerful, but simple to understand and use.

OOM/OOP is probably the most effective language for the purpose. It empowers system participants to discuss about the system and its parts in a formal and consistent way. The language constructs help us to structure the communication such that the system stays manageable during its whole lifetime.

describe the features of object-oriented programming

describe the features of object-oriented programming?

PLease help me....

 @Simon : I'm familiar with the prototype based languages. But what I don't get is why you call it non-supported modularity kinda language.

@R.C.Mittal: that is correct but the point is the encapsulation makes it easier to achieve madularity. And that is why I think Simon is wrong about prototype based languages.

You breakdown the problem by keeping modularity in mind and then you implement modules with the respect of OOP concepts.

Advantages of Object Oriented Programming are:

@Rasul: Maybe you can specify what you mean by modularity. The first thing that comes to my mind is modules which has a specific meaning in programming. Most OO programming languages do not have modules in this sense. However, I think you mean something different by modularity.

Another definition of modularity is that you have several components that can be taken apart and recombined. I still do not agree that OO design has modularity by itself. Through composition one can still achieve strong coupling between classes. Because of this you can easily loose modularity. But still, composition is an OO concept.

@George: I do not fully agree on all your points. I guess, that all this depends on the problem at hand. For most programmers your points might be valid, but for me as someone working on scientific software this is not always true.

I hope that I am not misunderstood: I am totally pro OOP. And OOP has some advantages. But, OOP is not the silver bullet and a lot of the advantages mentioned are not entirely specific to OOP. I'd like to encourage critical thinking. Finally, my preferred programming language is C++. It has OOP when I need it. But, it also supports other paradigms when these fit my problem a lot better. In scientific applications this is often the case.

Hi Henry,

OOP is probably one of the only methods of programming currently, even scripts require some form of OOP application. So, it is the only professional way to programme because other techniques such as Functional Programming are simply not applicable to programming projects of larger scale. Advantages of OOP are the flexibility you have in (with use of pointers / method overridding / instantiating et cetera)  reusing code. It is basically every where in every language.

In large projects, you simply cannot not create and work with objects. It is a norm, it is mandatory - OOP is programming these days. At the professional level, you either are an OO Programmer or you aren't a programmer - that's why you picking it up is mandatory. You want to learn programming? So you just need to know OOP.

first of all I should say Happy Norouz ( persian new year's tradition) to you all.

@Simon : Modularity means that you have the ability to decompose your application into modules which they have separated functionalities. In class-based oop, classes can do modules part. In prototype based languages such as js, you can use prototypes to do the part, all you need is a structure to gather necessary and related functions to implement the concept of a module. If I'm wrong plz tell me.

another thing that I saw in your response to George, you can implement extensibility in the way of strategy pattern in your example. By programming through behaviour you can achieve that. The open close oo-design principle specify that you should design your application in a way it can be extended and not modified, open to extension close to modification. So it's up to you to do the work. In other words you have the ability to write an extendable program using oop approach.

@Santosh: It is true that everybody should know OOP today. However, it is not true that it is the only way of doing things. I actually prefer C++ because it does not require everything to be OOP. You should only use OO design where it is useful. I would never press a numerical algorithm into an OO framework. Why should mathematical functions, such as abs(), sqrt(), etc., be inside a class? OOP is definitely not the silver bullet.

It is also totally wrong that you can only write large software in an OOP language. Have a look at Erlang on Wikipedia and see how many big companies are using it. E.g. The core on the server side for WhatsApp is written in Erlang. Most communication systems (telephone systems) used to be written in Erlang. (I don't know if this is still true today.)

Finally, OO and functional are not opposing things. Almost all OOP languages use imperative programming for the implementation of methods. Imperative programming is not restricted to procedural programming. Instead, it is orthogonal to OO programming. One opposite of imperative programming is functional programming. It is possible to use functional programming to implement the methods of classes, as it is done in Scala. If you have a closer look at Scala you will find out that it has been used at Twitter.

Today, everybody should know OOP. But, I think that everybody should also know at least procedural and functional programming as well. A good programmer should know the full palette and choose the right tool for the task at hand. Especially, good programmers should understand that OO and functional programming are orthogonal to each other.

@ Simon

Noted on the points, this is where we either complement our views  or differ.

- C Plus Plus: Even I love C++, it is simply highly organized but I think the need for specific headers to the code file is not necessary as of contemporary development outcomes, this is around, based on my opinion, to make sense of legacy code. In the era of runtime environments, I think that's an obsolete idea (functional programming), these area ideas from the BASIC days. You can easily have interface classes (in Java) or just a Object/Class compiled as Jars or DLLs in the .NET environment. Either way, I think your point on numerical functions (which are part of your included external libraries) only go on to prove my point. That even when performing simple functional programming functions for a mature language, you end up invoking and referencing existing libraries that may be written with OOP concepts in mind. These links can't be divorced.

So that's where I am at. When writing a calculation function, I would probably scale things, look at it from a bigger space and then write a firm OO program that allows me to override easily, modify my algorithms on the fly and enable reusability of code as I extend the classes used. Most design patterns keep OOP concepts in mind for software engineering. Even widely accepted patterns such as MVC retain OOP concepts. OOP is simply too mature and it is a long time before it may suffer from obsolescence. Probably as IDEs become more reliable as development tools, maybe, but not as of now.

I am all for multi-paradigm - but not at the cost of a mature development framework such as OOP. In fact, I don't think other development paradigms even come close in terms of the extent of use (development maturity is simply not present in substitutes), especially in industry.

What's the point of writing a program for a math problem when it will result in being closed (or be difficult) to scaling or minor overriding? With OO, you simply have more to gain - though it may require more lines of code to write. That's my two cent's worth - do it a little bit more because what you get in the end is a lot more. This is from a programmers' long term point of view. Of course, arguments can range from VB enthusiasts over RAD principles to GUI-intensive application developers over the impact (time/complexity/monetary) of having organized code. But I think OOP is a critical part of your code functionality over the long run. You don't invest valuable time without considering what invested time will return. Note - time = money.

I am fine with Erlang - because it is a multi-paradigm language. It is not necessarily the case that Whatsapp (an app I don't use, only being forced to use it by colleagues who simply must use it... for some reason) has elements that do not follow conventions of OOP, this is debatable. I bet, if the code is released, we can easily find OOP concepts within - but that's a hypothetical. Besides, language capability and the need for OOP concepts depend greatly on the kind of Runtime Environment you're writing your program for, but I am for managed complexity - rather than unmanaged chaos when scaling becomes an imperative.

I think there have been various development hell-based cases - where obsolete coding standards have become a lag on development projects. Not to mention, I am not a big fan (but am appreciative that I don't have to do my own garbage collection, large projects can be a train if you want clean code, OOP has made me lazy with GB) of managed code (this includes Garbage Collection) - due to the strains caused on hardware/OS resources.

What I don't get is with you being a C++ person, how would you recommend an environment that runs functional code on a managed environment? That's like recommending Visual Basic (6, maybe) over C Sharp or Java. How much control do you think you have over your software? Think about it.

Not to mention, Erlang is rather widely used in telecommunications, I hear that's due to its Sony Ericcson connection - how would it compare to fully mature RTEs like Java/.NET? How would you even work with functional code in an unmanaged environment? Won't we be looking at rewinding from C++ to C?

Major grey areas, too many loop holes in this. My view is that if it can't run on managed/unmanaged (both) environments, you're probably wasting your time learning it. But that's my own view and may be wrong.

@Santosh: I am not against OOP. In the example of the numerical algorithms it is a mixture of OO and procedural programming. I help writing a simulation software. In that background when you are, for example, solving a system of equations the algorithm for solving the equations would be a free-standing function (procedural programming). However, I would definitely use objects for matrices and vectors (OO programming). Pure OOP would tell you that for the numerical algorithm you should write a class Equation with a static method 'solve()'. I don't think this is the right way. This is why I say that you should not only learn OOP, but also the antiquated procedural programming.

The same is true for functional programming. It is not an antiquated way of thinking. In many cases, I would say, it is a superior way of thinking. Everybody should learn at least one functional programming language. You don't need to master it, but you should learn the concepts and its way of thinking. Lambda functions come from functional programming (why would you include something old school into the new C++11 standard?). And there are many elegant solutions in C++ when you use functions from the <functional> and <algorithms> headers. These help to write more concise code (directly expressing your intent), and sometimes even faster code. Everybody who learns one functional language will improve their programming skills in any other language.

And finally, I would never start a project in a functional language. I just said that it is possible to write large applications in a functional language. Concerning Erlang the major benefit is that it has very good failsafe mechanisms because it is designed to also recover from severe failure. And just because it is maybe possible to write OO code in Erlang it doesn't mean that it is an OO language. Even in C you can write OO code (see GTK+).

In general, I oppose many OO paradigms that software engineers devise. The major reason is that I am concerned with performance in my applications. This leads to avoiding dynamic dispatches. This restrictions also eliminates many patterns, e.g. the visitor pattern. Know your options. Then choose wisely.

@ Simon,

Wonder how integrated and scalable these simulation software are? Do you write external environments based on core technologies (ie DirectX/OpenGL) or do you use some 3rd party environment such as Unity or something? Latter I understand PP and FP... but former does not make sense. Basically, there is a world of difference as code tends to be managed for procedural or functional programming. How do you live without pointers and how do you achieve basic physics in a simulation without polymorphism? Just something I'm trying to understand (if you utilize the former approach).

I am more of a database person, so I think our views should have been the other way around. Concepts such as Procedural programming, while antiquated may still be relevant depending on your platform. I think VBA is a platform where PP is generally relevant for linear outcomes. But I tend to use multiple modules even in Excel and apply OOP concepts to keep things scales or reduced in scale as necessary.

But what I am saying is that OO is currently too mature. It has experienced wide application across industries and technologies, it has been scrutinized so much so that it's ended up undergoing a great deal of testing (MVC/MVVM et cetera). While every technology undergoes the bell curve to obsolescence, I doubt OO concepts have reached that end of shelf life stage. My entire point has been that it is way too critical, may just be the most important concept you can learn as a programmer currently.

Sure, for someone who wants to learn programming, FP and PP may be concepts to understand, but without OO your understanding of creating distributed and scalable systems is limited. In industry, you're not just expected to know an RTE or a specific library (as in academia), you're expected to be proficient on conceptual models of application. With OO specialization, I am at a stage where language has become irrelevant (syntax can be picked up), the primary issue lies with software architecture and if the RTE has the libraries to perform on functionalities I desire.

On patterns, wikipedia demonstrates OO concepts (and their critical elevation to the contemporary invaluable position it enjoys) - and I quote "Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved."

For something intangible such as a computer software, creating objects for an undefined subject matter is an important development. You may not even know how a GUI looks like and you could start writing code, that's a powerful concept. With PP and FP, my problem is the need for control arrays (context, if you must) - really, that's stepping into the 1970s or 80s... until better IDEs emerge, I doubt industrial application of FP and/or PP are the way to go - in fact, there is a school of thought that suggests that picking up FF or PP first tends to ruin your understanding of how to program. But then, that's just a view.

Everyone can have views, its' best to test them yourself, do take note of this Henry (if you're reading this). Up to your comfort level - but industry currently demands OOP due the popularity of RTEs like Java/.NET because now sure how you would code in Java (industrial grade systems) without OOP/Classes/Inheritance etc. Thanks.

@Santosh: You are right that most programming jobs require Java or .NET. For Java OOP is the only concept you need to know because everything has to reside in a class (okay, now you also have lambdas -> FP). This is one of the major reasons I personally dislike Java. And the jobs I like never require Java.

As I said before I am not against OOP. Especially in the area of GUI programming it is the best method around I know. But, I still think people should also learn FP and PP (only if you are programming in Java you don't need to know PP). For every language including lambdas the knowledge of a pure FP language is very helpful in finding clean solutions. It is a totally different mindset programmers should learn.

My personal experience with simulation code does not really count. It is not the way I would start writing simulation software myself. I would actually start with C++, introduce a few classes (and use libraries for matrices), and finally use some PP to steer the computation processes. However, this is my job for only three years now and the software is almost 20 years old. Back then it was written in Fortran 77 and since converted to Fortran 90. Therefore, the code heavily relies on PP and also on global variables. At least a few datatypes have been defined since then, but that is not OOP yet. It is impossible to restructure the code or even rewrite it (because of funding). Restructuring it in Fortran also does not make a lot of sense because OOP in Fortran will slow computations down significantly in numerical applications (I have seen benchmarks for that; and we are talking about a factor of about 100).

For a visualisation software I am using C++. However, speed is also of some concern here, and so I also don't use any virtual functions for the core. I even designed my classes in a way that I can directly hand them off to OpenGL buffers. No extra copying is required. And for the GUI I am using Qt. This software is almost entirely OOP. If unified call syntax is included in C++17 I might write such software entirely different in the future. Most likely that would be more PP where functions are working on objects.

About pointers in C++: What I wrote was concerning the overuse of pointers in C++. Within a function you rarely need any pointers (unless you are using them for semantic reasons). People like to use 'new' and 'delete' for every object. This introduces a lot of errors and has very low performance. My main point is that you do not need pointers in C++ where you don't need them in C. Sometimes you need them in C, then you also need them in C++. This means that performance will not suffer in C++ compared to C if pointers are used properly. The 'this' pointer in many cases does not have any performance overhead in C++, but is optimised out. I do heavily use pointers as member variables in classes where necessary. It is important to then strictly stick to RAII. Proper use of smart pointers is also very helpful. Though with smart pointers you should also consider references to smart pointers where necessary to avoid unnecessary reference counts.

Peter Newman 24 January 2005:

inheritance

operator overloading

type safety

encapsulation

polymorphism

dynamic binding

constructors/destructors

classes

instances

nodes

Abtraction

Polymorphism

Encapsulation

Inheritance

The advantage... how about getting a job for starter!

Seriously, you also need to do GOOD OOP, i.e. know and follow as much as possible the SOLID principles, know about design patterns, etc.

The sentences by Mr. Jerrold (Jerry) Heyman are very critical:

"Programming has presented several interesting concepts that I have adopted, and others that seem to work in academia - but not in the "real world".

Please tell us more.

Since I have a similar related case, I want to add the following about the the promised black-box:

"There is a clear and distinguishable variance between both theorizing that is largely based on the theoretical-academic world and the implementation that is conducted upon real-world cases"

The above sentence is from a similar discussion that I have mentioned it on page 39 (i.e. page 10) of the following paper:

Nidhal Kamel Taha El-Omari , “Sea Lion Optimization Algorithm for Solving the Maximum Flow Problem”, International Journal of Computer Science and Network Security (IJCSNS), e-ISSN: 1738-7906, DOI: 10.22937/IJCSNS.2020.20.08.5, 20(8):30-68, 2020.