Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Meaning that OOP allows me to have data-trees, of arbitrary depth and breadth, with some leafs being functions (and those leafs would be called methods) ?

Because everything else that people often put near "OOP" mark, just don't seem to have anything to do with it. (Inheritance, subtype polymorphism and encapsulation seem to be orthogonal to OOP).

Am I right? Or I'm missing something ?

share|improve this question
No, it's not fair, or at least not accurate. Inheritance, polymorphism and encapsulation are three of the major points that define what constitutes OOP. You may not use or care about them, but they're clearly part of what most people understand "OOP" to mean. – Jerry Coffin May 2 '12 at 19:13
@c69: You should listen to this guy. – pillmuncher May 2 '12 at 19:13
I think any system that allowed a class/interface to inherit/implement more than one parent class/interface might immediately break your "tree" view of things. – FrustratedWithFormsDesigner May 2 '12 at 19:16
@c69: What will remain? I don't see why anything would be "gone" if "we throw the trees out". Why do you appear to assume that trees were the best structure to start with, in the first place? – FrustratedWithFormsDesigner May 2 '12 at 20:26
@c69: I would say that inheritance and subtype polymorphism are a good way to define object-orientation (ie, if you are using these in your code then you code is object-oriented, regardless of language). However, I agree with you that "encapsulation" and (plain) "polymorphism" are generic terms and can apply to other things too. – hugomg May 3 '12 at 22:08
up vote 3 down vote accepted

Is it fair to reduce OOP to mere hierarchical composition of data structures? Meaning that OOP allows me to have data-trees, of arbitrary depth and breadth, with some leafs being functions (and those leafs would be called methods) ?

I guess you can choose to look at it that way, but I don't believe it's a particularly useful way to look at it. Specifically, your use of the word "data" (even if you specifically mention functions in there) seems to reduce OOP to a way to model data (or at least, to a data-centric approach). In my opinion, this is missing the point.

OOP is a particular way to structure code; both behaviour as well as data. Its main ideas are the normalisation of behaviour (DRY principle), as opposed to, say, the normalisation of data (as in the relational DB concept), and concepts like encapsulation. At its simplest, encapsulation is achieved by providing an external interface to classes (your public stuff), and an internal implementation (private / protected stuff). This is quite different to "traditional" modular programming, since your "module" boundaries are structured completely differently - in the case of OO, each class is a mini-module.

It is also important to note that the concept of encapsulation, in the generic sense, is quite different to a specific implementation of encapsulation. OOP has a specific way that encapsulation is done, inherently (of course, I'm only referring to the core cases here, not patterns, etc). Inheritance and polymorphism are much more OOP specific ways to achieve other principles (code reuse being one of them). I'm not sure I'd lump them in the same sentence as encapsulation, they exist at a slightly different level.

OOP also tends to map quite nicely on to a problem domain, allowing you to model a problem in a way that remains understandable to semi-technical users.

What was the point of going through the above mini OOP discussion? The above is the best I can do to summarise OOP in a few sentences - it highlights the main points of OOP from the perspective of someone who has worked with the technology for a long time. I don't think reducing it to a hierarchical composition of data structures does it justice. We can also reduce it to an array of characters in text files, but it doesn't mean that it captures the essence of the paradigm.

share|improve this answer
Accepted for this short sentence: OOP is a particular way to structure code; both behaviour as well as data. Its main ideas are the normalisation of behaviour (DRY principle), as opposed to, say, the normalisation of data (as in the relational DB concept), and concepts like encapsulation. – c69 May 4 '12 at 19:33
Update: i think Will Cook gave a nice definition of OOP - – c69 Jul 17 '12 at 21:36
@c69 Yes, I think that's a pretty good definition, although if I were reading that with very little prior knowledge of OOP, I'd be lost :) – Daniel B Jul 18 '12 at 6:22

You're missing something. Probably several somethings, in fact.

Objects are a powerful means of abstraction. They don't just organize data, they organize code. You could argue that that abstraction isn't necessary, that you could produce equivalent code using purely procedural techniques, but that'd be like arguing that high level languages aren't necessary -- it's perfectly possible to write equivalent code in assembly language. Such arguments may be technically true, but they're completely false from a practical standpoint.

share|improve this answer
There is more to OOP, than just structuring ? Great - that is exactly, what i'm asking in my question. Could you please elaborate on those extra things ? – c69 May 2 '12 at 21:10
+1 for the last sentence :) . – Radu Murzea May 3 '12 at 7:02
It should be noted that there are alternative ways to organize code, namely functions (or even procedures) – Raynos May 3 '12 at 9:30
Objects are not organasing the code. Modules does. Classes just happen to be a poor man's modules substitute in the OOP languages, and therefore all the modules fame unfairly goes to the OOP. And all that OOP stuff would shy in front of any truly decent module system (e.g., as in SML). – SK-logic May 3 '12 at 9:46
@SK-logic 1) Not all OOP is class-based. 2) The question isn't "what's the best programming paradigm?" but "is OOP nothing more than composition of data structures?" – Caleb May 3 '12 at 12:20

Any formal language is reducible to graphs, but the fact that a language is a graph or tree is insufficient to define what sort of language you have.

If you are trying to establish that a language as OO, then yes, it is a graph (possibly a tree if there is truly no multiple inheritance) where some nodes are functions, some are data types, etc., but the tree will also adhere to certain rules, such as encapsulated state, polymorphism, and inheritance. If it does not, it's not OOP.

share|improve this answer
State can be encapsulated with closure (or you can make public fields), polymorphism is often nothing more than lexical agreement, and "prefer composition over inheritance" kinda limits the scope of applicability for inheritance abusing patterns, once you leave prison of Java. – c69 May 2 '12 at 21:41
I'm not arguing that any of those items aren't available in other ways. I'm saying that they are what make an OO language OO. Without all three, it is not an OO language. And this has nothing to do with Java--the same was true in Smalltalk, and it is a big part of what differentiates C++ from C. – Matthew Flynn May 2 '12 at 21:57

I'd say that you are missing that OOP is tighly linked to OOA/D which is about modelling the problem domain in a meaningfull and sustainable way. This leads to considerations of coupling, cohesion, responsibilities, separation of concerns, and in turn considerations of encapsulation, composition, inheritance etc.

share|improve this answer
Separation of Concerns is in no way unique to OOA/D/P. Coupling and cohesion should be considered in any other paradigm as well. "Responsibilities" is not even a programming concept in strict sense.. So that leaves only modeling as potential object-oriented feature. – c69 May 2 '12 at 19:18
I agree these things are not unique to OO. The unique part is exactly the modeling approach. But IMO that modeling approach trickles down through the rest, leading to those things being realized differently with OO than with other paradigms. Btw. I'm not saying OO is necessarily better than other paradigms, just that they differ because of modeling approaches. – Christian Horsdal May 2 '12 at 19:23
It's quite common to do OOP without OOA/D. OOA seems to be losing popularity to BDD and TDD. – kevin cline May 2 '12 at 20:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.