I am very new to programming and a bit confused from reading\hearing different conventions from different sources:

Does Object-oriented programming have 4 or 5 concepts?

As a newcomer, I understand these are the 5 concepts:

  • Abstraction
  • Inheritance
  • Encapsulation
  • Polymorphism
  • Modularity

So how come I don't find a more "strict" definition and there seem to be several arrangements of these concepts out there?

  • 7
    Maybe because that's not like mathematics (some concepts in CS are, but I think OOP doesn't belong in this category), so there are no strict definitions to begin with. So for example how important is 'modularity'? Is it really so special to OOP that we have to mention it or would it be just something that happens by itself if we apply the other four correctly? Some lists add 'hierarchy', but is this really something extra or just follows from inheritance and polymorphism? – thorsten müller Mar 10 '16 at 10:05
  • 6
    Word of advise: As a very new programmer you shouldn't get so hung up on understanding terminology and theory. Collect some hands-on programming experience first, and it will get much more obvious what these people are talking about. – Philipp Mar 10 '16 at 10:27
  • 9
    Another thing is that OOP is changing over time. A lot of focus in the early C++ days (I know OOP goes further back than that) was on Inheritance and Polymorphism. Todays focus is far more on Abstraction and Encapsulation. – Bent Mar 10 '16 at 10:29
  • 3
    Some interesting discussion about the lack of precision in the definition of OO can be found here: c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs – MichelHenrich Mar 10 '16 at 14:26
  • 3
    Possible duplicate of Formal definition for term "pure OO language"? – user40980 Mar 10 '16 at 20:19

The reason you find different explanations of what object-oriented programming means is because there is no single person or organization with the authority to formulate a strict universally-applicable definition.

Object-oriented programming is not an ISO standard or a scientific law. It is a philosophy. And as with all philosophies, there are all kinds of different interpretations and no interpretation is universally applicable. When you read a text which tells you what concepts you should follow when designing a software architecture, you should see this as a guideline based on the opinions the author formed during their professional experience, and not as an universal truth.


Does Object-oriented programming has 5 or 4 components?

As others have mentioned, "OO" doesn't really have any components, because it's a way of thinking about modelling solutions to problems and not a toolkit nor a set of clearly defined processes.

As a newcomer, I understand these are the 5 components:

Abstraction, Inheritance, Encapsulation, Polymorphism and Modularity?

Inheritance and Polymorphism are programming language features. It's good that you understand these, but remember they are tools (which means, that as with any other tools, they should only be used for solving specific problems, and not treated as a goal or something to strive towards). You can (and often should) write "OO" code without using either of them. Some of the best "OO" code I've ever seen makes very little use of inheritance or polymorphism.

Abstraction, Encapsulation and Modularity are less to do with code and more about the way you look at a problem, the way you try to understand that problem, and the way you design and structure your solution in code.

Also, those design ideas are not exclusive to "OO". Chances are that you probably understand them now at a basic level, which could include being able to explain a textbook-perfect definition, and apply them to somewhat nontrivial problems; although a deeper test of understanding is being given a very large complex problem, and how much complexity you can handle.

Another test of understanding is the approach you use to break down a problem; and newcomers to "OO", who are often taught about OO in terms of data modelling (because that's how most people used to understand it back in the 1990s), and often end up focused on the wrong aspects of a problem - i.e. they focus too much on data, and they don't focus enough on behaviour.

For example, classic examples often refer to entities such as Dog, Cat, Elephant, Seagull, Shark, etc. Newcomers to "OO" often look at such examples and immediately think "Oh, I need a base entity called Animal", and they may even end up with other intermediate entities such as Mammal and Amphibian in a neat inheritance heirarchy, with different attributes in each one.

While that way of thinking demonstrates a very basic understanding of several OO concepts, an experienced OO programmer would never approach it like that nor jump to that conclusion (And would actually complain that they don't have enough information), because that approach demonstrates Entity modelling rather than OO modelling, and because the contrived example says nothing about the behaviour of those animals (And many people would argue these days that the essence of OO is all in the behaviour and functionality).

The path to learning about "OO" traditionally involves spending time building the wrong abstractions when you either know nothing (or too little) about the behaviour of the problem you are modelling, or when you make the mistake of focusing your attention on entities rather than functionality, although part of that is because so many books, courses and online tutorials written over the years have been (mis) guiding learners down that path for a long time (The tide is changing though).

Overall, a lot of your understanding will come down to experience. Those concepts you've learned so far are a good start, there are more concepts you'll need to learn along the way (for example, "SOLID" and "DRY" principles), and you will need to spend a long time putting theory into practise with real highly-complex problems before all of it is likely to "click" into place.

  • 2
    A shark and a frog both swim, but one is a fish, the other is an amphibian. I think that example describes your point well. – RubberDuck Mar 10 '16 at 23:24

The term "Object-Orientation" was coined by Dr. Alan Kay, so he is the authoritative source on what it means, and he defines it thus:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

Let's break that down:

  • messaging ("virtual method dispatch", if you are not familiar with Smalltalk)
  • state-process should be
    • locally retained
    • protected
    • hidden
  • extreme late-binding of all things

Implementation-wise, messaging is a late-bound procedure call, and if procedure calls are late-bound, then you cannot know at design time what you are going to call, so you cannot make any assumptions about the concrete representation of state. So, really it is about messaging, late-binding is an implementation of messaging and encapsulation is a consequence of it.

He later on clarified that "The big idea is 'messaging'", and regrets having called it "object-oriented" instead of "message-oriented", because the term "object-oriented" puts the focus on the unimportant thing (objects) and distracts from what is really important (messaging):

Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.

The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas.

(Of course, today, most people don't even focus on objects but on classes, which is even more wrong.)

Messaging is fundamental to OO, both as metaphor and as a mechanism.

If you send someone a message, you don't know what they do with it. The only thing you can observe, is their response. You don't know whether they processed the message themselves (i.e. if the object has a method), if they forwarded the message to someone else (delegation / proxying), if they even understood it. That's what encapsulation is all about, that's what OO is all about. You cannot even distinguish a proxy from the real thing, as long as it responds how you expect it to.

A more "modern" term for "messaging" is "dynamic method dispatch" or "virtual method call", but that loses the metaphor and focuses on the mechanism.

So, there are two ways to look at Alan Kay's definition: if you look at it standing on its own, you might observe that messaging is basically a late-bound procedure call and late-binding implies encapsulation, so we can conclude that #1 and #2 are actually redundant, and OO is all about late-binding.

However, he later clarified that the important thing is messaging, and so we can look at it from a different angle: messaging is late-bound. Now, if messaging were the only thing possible, then #3 would trivially be true: if there is only one thing, and that thing is late-bound, then all things are late-bound. And once again, encapsulation follows from messaging.

Similar points are also made in On Understanding Data Abstraction, Revisited by William R. Cook and also his Proposal for Simplified, Modern Definitions of "Object" and "Object Oriented".

Dynamic dispatch of operations is the essential characteristic of objects. It means that the operation to be invoked is a dynamic property of the object itself. Operations cannot be identified statically, and there is no way in general to exactly what operation will executed in response to a given request, except by running it. This is exactly the same as with first-class functions, which are always dynamically dispatched.

In Smalltalk-72, there weren't even any objects! There were only message streams that got parsed, rewritten and rerouted. First came methods (standard ways to parse and reroute the message streams), later came objects (groupings of methods that share some private state). Inheritance came much later, and classes were only introduced as a way to support inheritance. Had Kay's research group already known about prototypes, they probably would have never introduced classes in the first place.

Benjamin Pierce in Types and Programming Languages argues that the defining feature of Object-Orientation is Open Recursion.

So: according to Alan Kay, OO is all about messaging. According to William Cook, OO is all about dynamic method dispatch (which is really the same thing). According to Benjamin Pierce, OO is all about Open Recursion, which basically means that self-references are dynamically resolved (or at least that's a way to think about), or, in other words, messaging.

As you can see, the person who coined the term "OO" has a rather metaphysical view on objects, Cook has a rather pragmatic view, and Pierce a very rigorous mathematical view. But the important thing is: the philosopher, the pragmatist and the theoretician all agree! Messaging is the one pillar of OO. Period.

Note that there is no mention of inheritance here! Inheritance is not essential for OO. In general, most OO languages have some way of implementation re-use but that doesn't necessarily have to be inheritance. It could also be some form of delegation, for example. In fact, The Treaty of Orlando discusses delegation as an alternative to inheritance and how different forms of delegation and inheritance lead to different design points within the design space of object-oiented languages. (Note that actually even in languages that support inheritance, like Java, people are actually taught to avoid it, again indicating that it is not necessary for OO.)

  • 1
    @DavidArno Your comment is not constructive at all. Alan Kay himself claims he coined the term "object" for this concept (though, I suppose, not the concept itself). If you are going to contradict a well-known authority on the subject, at least write a more constructive comment. – Andres F. Mar 10 '16 at 14:15
  • 1
    @DavidArno Also, is the downvote yours? So someone took the time to write a comprehensive list of different views, from well-known experts, on what OOP means, and you downvoted it because you disagree with a single sentence? Oookay. – Andres F. Mar 10 '16 at 14:18
  • 2
    @AndresF. This answer can be summed up as "there are two schools of though, Alan Kay's, and everyone else's. Because the former coined the term he's automatically right and everyone who disagrees with him is wrong". It's an appeal to authority fallacy answer. Thus the downvote. – David Arno Mar 10 '16 at 14:26
  • 2
    Actually, this answer can be summed up as "there are three schools of thought, coming from three completely different angles and nobody disagrees with anyone, in fact, they are all in agreement." The linguistic prescriptivist would say, Alan Kay invented the term, he gets to say what it means, and he says it means messaging. The linguistic descriptivist would say, no, Alan Kay doesn't get to say anything, we have to look at how the term is actually used, and that's what Cook did: he studied what languages that are commonly described as OO (Java, C++, C#, etc.) have in common, and he found – Jörg W Mittag Mar 10 '16 at 14:40
  • 3
    one thing: messaging.He studied what languages commonly described as not OO are lacking that languages commonly described as OO have, and he found one thing: messaging. The ivory tower theorist takes the λ-calculus and looks at what the smallest set of features is that one would have to add to get something that is commonly described as OO, and he arrives at open recursion, which is basically the building block for messaging. – Jörg W Mittag Mar 10 '16 at 14:42

As @Philipp states, the root of the problem is that there is no official definition of what makes a programming language object-oriented. Indeed, this is probably a good thing. There are a lot of ways to support OO programming, each with their own advantages and disadvantages. Discussion about which languages are more "pure OO" don't really achieve a lot.

However, looking at the 5 attributes you listed, to my mind Modularity is definitely the odd one out. Modularity is really an attribute of a program not a programming language. At the linguistic level, the attribute is "support for modularization", and that typically takes the form of a "modules" pr "packages" mechanism.

But my real objection to Modularity is that it is not key to OO programming or OO programming languages, to the extent that the archetypal programming language Smalltalk-80 did not support modules at all. And when you think about it, linguistic support for modules in many widely used OOPLs is "weak".

Modules are designed to support "programming in the large" ... where your code-base gets too large for a single person to fully understand. And you don't need modules in a programming language to modularize your code.

I'm nor getting into the debate about the other 4 attribute, and whether (for example) what models of "inheritance" are pure OO. Also, while Alan Kay is credited with having invented OO programming, that does not necessarily mean that his definitions of OO / and OOPL have primacy. Clearly, this is not the case. He is an authoritative source, but there are other sources who give other definitions for OO & OOPLs that (in practice) carry greater weight.

  • 2
    +1 Modularity is in fact widely accepted as a desirable attribute of most software systems, regardless of the programming language and paradigm used. Many languages which are not OO have support for modularization. – Andres F. Mar 10 '16 at 14:10
  • +1 @AndresF. comment. Indeed, "structured programming" and "step-wise refinement" (a technique for thinking code structure) comes out of the crucible of "increasing complexity resulting in even worse software". Had it preceded COBOL that language would not have such a negative reputation IMHO. And I view OO pragmatically as simply higher-order structure. And I mean that w/out underlying structure OO is no better than the worst COBOL. – radarbob Mar 11 '16 at 5:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy