Explain Object-Oriented Programming Like I'm 5

I'm an experienced C programmer, but I don't know that much about C++ and I'd like to know why it's better, worse, or just as good.

I'm probably just ignorant, but to me, I don't see that many benefits with classes other than for organization purposes. I know they can keep variables and functions (or "methods") private, but why would you need private variables and functions? If those variables and functions aren't to be called or accessed, then don't call or access them.

I can see why they would be useful if you're writing a library and there's certain functions you don't want your users to mess with, but why would you use them in your own programs? Aren't structures just as good for organizing your data? You can make copies of them with typedef.

I'm probably being really stupid, because like I said I don't know that much about OOP, these observations are just from what I know of it.

In terms of performance, C++ done right should be just as fast as C. That aside, I'm starting to learn it myself because it offers some of the things that have been spoiling me in Python but with the speed of one of the fastest compiled languages. For example:

Code:

---

#include <iostream>
#include <unordered_map>
#include <string>

int main(void)
{
    std::unordered_map<std::string, int> adictionary;
    adictionary["some key"] = 3;
    adictionary["another key"] = 6;
    std::cout << adictionary["some key"];
    return 0;
}

---

I'm not really interested in the nitty gritty of the language and its myriad of complicated features, I'm more interested in its large standard library as recently upgraded by C++11. The standard library includes all kinds of data structures out of the box which makes it ideal IMO.

Even in your own code it is easy to do things you shouldn't. Programmers make mistakes that, in hindsight, are often unnecessary mistakes. You may write the documentation incorrectly. You may forget about some special but important case that should be avoided. Even in your own code.

In fact, often especially in your own code. You are more likely to be over-confident that code you wrote works correctly, and that you understand it.

Access control (private, public, etc) is about allowing you to control what code is allowed to do a change, and what is not.

Quote:

---

Originally Posted by Babkockdood

I'm an experienced C programmer, but I don't know that much about C++ and I'd like to know why it's better, worse, or just as good.

---

C++ and OOP in general are the fine art of taking a device that needs finely grained step by step instructions and getting it to act like it works on blobs of data as unified objects. Underneath even the most wildly abstracted OOP code, you are still going to find ASM like procedures running the show.

Laughably this is touted as an attempt to make programming more "human"... I don't know a single person, programmer or otherwise, who thinks like a C++ data object... I do however know several people who think just like old style BASIC programming, complete with GOTO 10!

The only way I can get my head around it is by imagining classes, interfaces and objects to be little machines where pulling one lever does one thing, another lever does something different...

Quote:

---

Originally Posted by Babkockdood

I can see why they would be useful if you're writing a library and there's certain functions you don't want your users to mess with, but why would you use them in your own programs?

---

I take it that you recognise that the notion of implementation details being private in some way to the implementation maintainer is useful - this would be the notion of encapsulation. Another thing that you may recognise is that it may be useful to refer to an interface consisting of a set of functions that operate on some kind of data structure as a single entity - this would be the notion of an object or a class.

Quote:

---

Originally Posted by Babkockdood

I don't see that many benefits with classes other than for organization purposes. (...) Aren't structures just as good for organizing your data?

---

If we just compare C++ concrete classes/structs with C structs, then yeah: the main difference would be member functions and access control. Member functions can be considered syntactic sugar since objects of a C struct type can also be seen as an object in an OO sense; a function that operates on the C struct and which forms the core interface provided by the library author can be seen as a member. An access control mechanism as a language feature is nice but unnecessary as convention can also work to achieve encapsulation... or we could use the opaque pointer idiom if necessary.

I think that it is more interesting to consider the use of inheritance and polymorphism thereof in C++. Start by reading about the Open-Closed Principle and the Liskov Substitution Principle.

Quote:

---

Originally Posted by Babkockdood

I'm an experienced C programmer, but I don't know that much about C++ and I'd like to know why it's better, worse, or just as good.

---

One way in which it's better: the convenience of the STL containers.
One way in which it's worse: it is a resource pig compared to C, at least if you make much use of, eg, the STL. The significance of this depends on the nature of the task, I guess.

I find a lot of the syntax awkward, but I'm now learning Java -- also a strongly typed OO language w/ generics -- and it seem to have some of the same complications.

Quote:

---

I'm probably just ignorant, but to me, I don't see that many benefits with classes other than for organization purposes.

---

I think that is true, but it is also true of functions, and has almost as significant ramifications. The difference between "procedural" and "object oriented" is slightly ambiguous in reality; if you think of it on a micro level, class methods are procedural code. If you think of it more meaningfully, on a macro level (the way everything as a whole is organized), you may easily find that they way you already write code could be described as "object oriented"; it is intuitive and logical anyway. I'd actually say most of the C projects I've ever looked at are essentially object oriented in at least a protozoic way, very often explicitly. Certainly, it is easy to think of them that way. OO makes natural, modular sense.

So the formal OO system in C++ provides some additional "power features", such as tidy inheritance, that are pretty useful for organizational purposes, and as such, can save you a significant amount of work (just like functions) and help "de-complexify" to a large extent. I find there is a sort of "complexity barrier" with coding; OOP simplifies IMO, making it easier to keep that barrier at a distance.

Quote:

---

I know they can keep variables and functions (or "methods") private, but why would you need private variables and functions? If those variables and functions aren't to be called or accessed, then don't call or access them.

---

That's how I feel too, but then, I've never (yet) done significant work as part of a large team. In which case I might be very grateful to be able to disarm my co-workers in this way.

Quote:

---

Aren't structures just as good for organizing your data? You can make copies of them with typedef.

---

Yeah, that's the kind of "primitive" or casual OOP I was talking about. C++ classes evolved from C structs.

Quote:

---

I'm probably being really stupid, because like I said I don't know that much about OOP, these observations are just from what I know of it.

---

There is more OO code and less OO code. I think you start out writing more procedurally, making use of classes where you see it as obvious and convenient. Gradually, as the potential relationships between classes unfold, you start to see more and more stuff in that light. Again, exactly like functions. In general, the more you can break a task down into functions, the better. I suppose there could be such a thing as code which is too object oriented, just as there can be code which is broken down too much into functions, but I would place that bar very low, like near the level of obviously joking around. Some people are unintentionally silly, of course, but I like to think I'm not one of them. ;)

In short, I'd say that object oriented programming is not contra procedural programming at all. It just adds a sort of meta perspective to it, opening up and structuring different possibilities.

Quote:

---

Originally Posted by CommonTater

C++ and OOP in general are the fine art of taking a device that needs finely grained step by step instructions and getting it to act like it works on blobs of data as unified objects.

Laughably this is touted as an attempt to make programming more "human"... I don't know a single person, programmer or otherwise, who thinks like a C++ data object...

---

This is a very perverse, polemical mis-interpretation, unfortunately. Like I said, it is a mistake to understand OOP as something that is alien to or incompatible with "procedural" thinking.

If you are trying to discredit something, a straw dog is useful. But if you are actually trying to understand it, don't chase the straw dog. It's not what you are looking for.

Quote:

---

Originally Posted by CommonTater

The only way I can get my head around it is by imagining classes, interfaces and objects to be little machines where pulling one lever does one thing, another lever does something different...

---

A little better, if only because it is so general. :P

Quote:

---

Originally Posted by CommonTater

The only way I can get my head around it is by imagining classes, interfaces and objects to be little machines where pulling one lever does one thing, another lever does something different...

---

That's not so bad. If you imagine classes as a blueprint for the little machine, describing all the levers, and then objects are the little machines, that's about right. Classes aren't objects in the same way that struct declarations aren't variables. I didn't have the convenience of such nice imagery to learn from, mainly in classes and books, we just dived right in and learned all the OOP terms and learned how to write classes by actually writing code.

You're very self deprecating when it comes to this stuff CommonTater, but you "get it" better than you think.

Learning some more C++ today...I think I may have to off myself for the spoils provided by std::string alone...

(as in, I'm retarded for not having learned C++ sooner)

Quote:

---

Originally Posted by Epy

(as in, I'm retarded for not having learned C++ sooner)

---

Nah, your real mistake was going with the trendier python instead of the more expressive perl.

Thanks for all the explanations. I'm starting to understand it better.

Quote:

---

Originally Posted by MK27

Nah, your real mistake was going with the trendier python instead of the more expressive perl.

---

Perl's syntax just makes me puke blood...and I only use Python at work to make quick and dirty reports really, I prefer C or Fortran otherwise.

Quote:

---

Originally Posted by Epy

Perl's syntax just makes me puke blood...

---

That's what it's for. You need to get that crap out of your system and purlify. Embrace concise dynamic beauty kind of thing. Eventually it feels good ;$

Quote:

---

Originally Posted by MK27

That's what it's for. You need to get that crap out of your system and purlify. Embrace concise dynamic beauty kind of thing. Eventually it feels good ;$

---

I don't particularly like Perl's syntax, either. I learned Python because it's syntax _is_ nice. I am aware of Perl being more "hardcore" than Python, however, if I ever wanted a more "expressive" industrial scripting language, I would learn Ruby.

Funny thing is, I would probably have already learned Perl anyway if not for it's use of sigils.
Sigilia are evil. :(

I must only be scratching the surface of programming, because I would say that Python is about as expressive as it gets. Between that and the huge standard library, I don't really see the need to learn Perl or Ruby, since I already know Python...

Quote:

---

Originally Posted by Epy

I don't really see the need to learn Perl or Ruby, since I already know Python...

---

Yeah, that's about it. I don't think there's a point in knowing more than one language from that category (general purpose, dynamic typing, GC, OO) unless you are required to. As to which one is "the best", I guess it depends on the criteria. They all have an immense range of modules. I learned some ruby for a rails project, I would not bother beyond that because I like perl more. Likewise, I learned a smidgen of python to script-fu gimp. I've had to work in php before. Perl's less stodgy than all of them IMO. Because of the evil sigils. :devil:

Quote:

---

Because of the evil sigils.

---

A wizard is only as good as the quality of his spells.

Quote:

---

I'm probably just ignorant, but to me, I don't see that many benefits with classes other than for organization purposes.

---

Someone who is only using conditions and jumps (i.e. ifs and gotos) could say the same about structures and functions in C :)

Yes, it's always about organization and making it easier for the programmer. C++ is worth it even if you only use std::string. Using std::string excessively would probably remove half of the bugs ever written.

Again, I'm smacking myself for not learning C++ sooner just for std::string alone. basically has all the spoils Python provides you with (I'm guessing Python actually took these from C++), but many many times faster as a compiled language.

Quote:

---

Originally Posted by Epy

basically has all the spoils Python provides you with

---

Eh, C++ is much closer to C than to Python.

std::string is convenient, and I do extensively use STD containers when writing C++. But again, dynamic strings can very easily be made in pure C, containing pretty much all the same functionality.

Quote:

---

Originally Posted by Epy

Again, I'm smacking myself for not learning C++ sooner just for std::string alone. basically has all the spoils Python provides you with (I'm guessing Python actually took these from C++), but many many times faster as a compiled language.

---

That's not really the case, or no one would bother using anything but C++. I kind of agree with Yarin -- I find working in C++ more like working in C than perl.

Dynamic typing and garbage collection are a huge deal. If I had to be concerned with type conversion and safety for the tish I do in perl, it would take me 5x as long and cause 10x the headaches. It makes a lot of data structures much much simpler. Eg this:

Code:

---

    std::unordered_map<std::string, int> adictionary;

---

From your first post only superficially looks like a python dictionary. It's way more limited -- the keys have to be strings and the values have to be ints. They can't be, eg, more dynamic dictionaries in a tree. And look at the freaking syntax -- it's almost painful. In perl:

Code:

---

my %dictionary;

---

The keys of which are stings which can type convert to numbers, and the values of which can be anything -- arrays of objects, code refs, more tree, etc. Now start to consider the code involved with putting something into a std::map. Then getting stuff out -- iterators are another very tedious, awkward C++ mechanism that has to do with strong typing.

GC is a little less significant IMO, but still saves a lot of hassles, esp. around closures and such.

I think if you take a reasonably complex, well written python program and re-write it in C++, you're going to end up with at least 3-5 times more code.

Quote:

---

Originally Posted by MK27

It makes a lot of data structures much much simpler. (...) It's way more limited -- the keys have to be strings and the values have to be ints. And look at the freaking syntax -- it's almost painful.

---

Pros and cons: if the intention is to map strings to ints, then the C++ code snippet has an advantage over the Perl code snippet as it communicates, and to some extent enforces, that intention, at the cost of verbosity. What is more painful is the verbosity of re-stating the type when initialising a variable with an object of a known type, since the gain in clarifying intention is small, but the new use of auto alleviates this.

Quote:

---

Originally Posted by MK27

Now start to consider the code involved with putting something into a std::map.

---

Depending on the use case, this could actually be very little code ;)

Quote:

---

Originally Posted by MK27

Then getting stuff out -- iterators are another very tedious, awkward C++ mechanism that has to do with strong typing.

---

I note that iterators are not a C++-specific mechanism. I think most of what made C++ iterators in the pattern of the C++ standard library "tedious, awkward" was the lack of a range based for loop, but that has now been fixed. Interestingly, the range based for loop mechanism effectively uses a form of duck typing...

Quote:

---

Originally Posted by laserlight

Pros and cons: if the intention is to map strings to ints, then the C++ code snippet has an advantage over the Perl code snippet as it communicates, and to some extent enforces, that intention, at the cost of verbosity.

---

Well, there are obviously very different intentions behind C++ and dynamically typed languages. In perl, "type safety" is essentially non-existent; if you wanted to implement it, it would be painful and long-winded ;)

I don't think the verbosity of C++ is by accident or mistake -- I think it's intentional and for a purpose -- just personally, I don't consider the purpose worthwhile, because the amount of trouble strong typing saves me is nothing compared to the amount of time it costs me.

However, I don't know if it is feasible to have a 100% compiled, dynamically typed language, I suspect not without disguising something like a runtime interpreter into a core library. So it goes with the territory, I guess.

Presuming that purely compiled languages really are stuck with certain constraints, it would seem that the main purpose of the verbosity is really to deal with those constraints. I don't think you can completely justify the syntax on the basis of it being "more communicative", altho that may be, as you say, a beneficial side effect. How beneficial seems pretty subjective tho.

Quote:

---

I note that iterators are not a C++-specific mechanism. I think most of what made C++ iterators in the pattern of the C++ standard library "tedious, awkward" was the lack of a range based for loop, but that has now been fixed.

---

Thanks for the tip. Better late than never.

I wasn't trying to slam C++ excessively, BTW. Just pointing out to Epy that it is not the final solution or anything, and does not at all have "all the spoils Python provides you". Conversely, perl or python do not provide all the spoils of C++. Considering the difference between languages may be at least as important to understanding them as considering their similarities.

Quote:

---

Originally Posted by MK27

the amount of trouble strong typing saves me is nothing compared to the amount of time it costs me.

---

how does it cost you any time? any time spent dealing with type safety should more than pay off in time saved debugging and maintaining your code.

Quote:

---

Originally Posted by Elkvis

how does it cost you any time? any time spent dealing with type safety should more than pay off in time saved debugging and maintaining your code.

---

For starters, because you can assemble complex data structures on the fly that would require writing a class in C++. The rough equivalent of std::map in a dynamically typed language does not have any limitation on its values, just as arrays do not have limitations on their elements. They can be heterogenous, like members of a class, including more heterogeneous arrays and maps, and also code references, like class methods. Also, they can be reassigned some other type. All the dynamically typed languages I know of have some means of easily determining the type of a reference if needed. All that can save oodles and oodles of code if used proficiently. Dynamic typing is the major reason people will observe, "you could re-write that in language X and reduce the codebase by 70-80%".

However, I'm pretty sure that handling dynamic typing is also the major runtime expense that makes interpreted languages slower than purely compiled ones. Like I said earlier, I think true, purely compiled languages require strong static typing for technical reasons. After all, perl, python, et. al. could be "purely compiled" if you built a complex runtime machine into every executable, or pieces of such into libraries they link against. But nobody does this because (presumably) it makes more sense to just have a generic interpreter. I'm sure this has to do with the fact that dynamic typing involves complex runtime handling, whereas it with static typing it is dead simple (and therefore, higher performance).

So the concept of "type safety" evolved to embrace a necessity. I don't know if anyone claims it is purely about good programming practices, I think such a claim would be specious. Which is also why I think it can be silly when taken to extremes. The types are not there to make your code more communicative or comprehensible. They are there for the compiler.

Quote:

---

Originally Posted by MK27

After all, perl, python, et. al. could be "purely compiled" if you built a complex runtime machine into every executable, or pieces of such into libraries they link against. But nobody does this because (presumably) it makes more sense to just have a generic interpreter.

---

That's actually only mostly true ;)

Quote:

---

Originally Posted by MK27

I'm sure this has to do with the fact that dynamic typing involves complex runtime handling, whereas it with static typing it is dead simple (and therefore, higher performance).

---

However, dynamic types can in many cases be converted to static types during the compile process, through hint optimization, for example. Though I can't think of any real life examples of this off the top of my head...

Quote:

---

Originally Posted by MK27

The types are not there to make your code more communicative or comprehensible. They are there for the compiler.

---

That is the other extreme, which is also "specious" and "silly" ;)

Quote:

---

Originally Posted by Yarin

That's actually only mostly true ;)

---

I'm sure there's a way to do that for a lot of languages (it can't be impossible, just more or less awkward); someone mentioned hiphop for php here a few weeks ago.

Beyond allowing you to deploy a static exe without worrying about interpreter installations, I'm not sure if I see a point tho. I guess it could improve performance for non-persistent applications that are run to perform a one off task and exit.

Quote:

---

Originally Posted by laserlight

That is the other extreme, which is also "specious" and "silly" ;)

---

I'll agree that type safety is important because of the necessity for strong typing in compiled languages. But sans such necessity, I'd consider someone who wanted strong typing purely to facilitate type safety a little loony. ;) Perhaps: data type obsessive compulsive disorder.

OOP at the core, is this idea: all actions a program makes, are performed by objects, which are self-contained entities that hold data, and the procedures which operate on that data. This is not a programming technique but a way of organizing your thought processes. C++ just makes it natural to express these sorts of thoughts.

Some people include inheritance, protected scope, dynamic dispatch and some other things under the OOP umbrella. Most OOP languages provide these features, but a language which doesn't can still be OOP.

Virtual functions, operator overloading, inheritance, exceptions, private/public all just add flavor to the C++ language. Its OOP-ness comes from the class concept.

I would say that inheritance and virtual functions should be considered core concepts of OOP. without them, it's impossible to have is-a relationships, which are impossible to escape in real life, and really helpful in programming.

Quote:

---

Originally Posted by Elkvis

I would say that inheritance and virtual functions should be considered core concepts of OOP.

---

Yeah, though I think "polymorphism" would be a more general term than "virtual functions".

Quote:

---

Originally Posted by brewbuck

Some people include inheritance, protected scope, dynamic dispatch and some other things under the OOP umbrella. Most OOP languages provide these features, but a language which doesn't can still be OOP.

---

I would not included "protected scope", but some kind of inheritance and polymorphism (hence dynamic dispatch) is essential to OOP, in my opinion, since they form a cornerstone for OO design. Of course, a language that does not natively support them can still be used for OOP, but that's another matter.

Quote:

---

Originally Posted by laserlight

I would not included "protected scope", but some kind of inheritance and polymorphism (hence dynamic dispatch) is essential to OOP, in my opinion, since they form a cornerstone for OO design.

---

Aren't those ultimately syntactic sugar for composting (sp?) ...i.e..putting objects of the 'base' (or pointers to them) inside the 'derived' ?
...Some sort of dynamic behavior could easily be attained by maintaining enums or objects (..tables) about the state and nature of a particular object .

Quote:

---

Originally Posted by manasij7479

Aren't those ultimately syntactic sugar for composting (sp?) ...i.e..putting objects of the 'base' (or pointers to them) inside the 'derived

---

I am talking concepts, so there's no syntactic sugar. What's a pointer? ;)

Also, what exactly do you mean by "composting"? It sounds like composition, but that's a different concept from inheritance and polymorphism.

Quote:

---

Originally Posted by manasij7479

Aren't those ultimately syntactic sugar for composting (sp?) ...i.e..putting objects of the 'base' (or pointers to them) inside the 'derived' ?
...Some sort of dynamic behavior could easily be attained by maintaining enums or objects (..tables) about the state and nature of a particular object .

---

Under the hood, there is no difference between composing two classes and having one class inherit from the other. To wit:

Code:

---

struct Base
{
    int a;
};

struct Derived
{
    Base base;
    int b;
};

---

The Derived struct is composing two things: a Base and an integer. But imagine that there is some syntactic sugar present, which allows us to avoid needing to put ".base." when we want to reference a member of Base. Suddenly you have inheritance. It's actually no different from composition, but the sugar gives us the feeling that Derived is actually just a specialized form of Base.

Once again, OOP is primarily in your head.

Quote:

---

Originally Posted by manasij7479

Aren't those ultimately syntactic sugar for composting (sp?)

---

"Composting" is almost a good term for this, lol.

I think "inheritance" is actually a narrow, boxy term. Eg, mix-ins, which are part of some OO languages, are normally considered an "inheritance" related technique, but the term itself ("mix-in") seems broader to me than inheritance, and kind of indicates what inheritance is primarily about (code re-use/sharing), and that code sharing does not need to depend on a hierarchy (which the inheritance "box" implies). Thinking outside the box, inheritance is more a form of mix-in than a mix-in is a form of inheritance ;) And as brewbuck points out, it's all based on a simple and obvious premise that does not require any formalization in syntax at all.

Put another way: inheritance is not a pre-requisite for OOP, it is an inevitable consequence of it. It would be impossible to do OOP in a way that did not permit inheritance or code sharing in some form, so it is as redundant to say, "Inheritance is fundamental to true object oriented programming" as it is to say, "Wetness is fundamental to water". It implies there are forms of OO without a form of inheritance or sharing, which is does not make logical sense if we deconstruct the concept of inheritance slightly. The form of sharing may not be the same as it is in C++, is all.

Quote:

---

Originally Posted by MK27

Thinking outside the box, inheritance is more a form of mix-in than a mix-in is a form of inheritance

---

No, because you are only thinking of inheritance of implementation when there can be inheritance of interface without inheritance of implementation. Consider a language with duck typing and classes but no native support for class-based inheritance: one can describe an interface via documentation that is then implemented by different classes. The subclasses inherit from this superclass which only exists in the documentation, and the polymorphic behaviour is facilitated by duck typing.

Quote:

---

Originally Posted by MK27

It would be impossible to do OOP in a way that did not permit inheritance or code sharing in some form, so it is as redundant to say, "Inheritance is fundamental to true object oriented programming" as it is to say, "Wetness is fundamental to water".

---

I think that's the whole idea behind talking about "core concepts" of a programming paradigm: how do you identify something in a program as being "object oriented"? "Wetness" is one aspect that we can use to identify water as "liquid water"; "inheritance" is one aspect that can we use to identify that something in a program is "object oriented".

Quote:

---

Originally Posted by laserlight

No, because you are only thinking of inheritance of implementation when there can be inheritance of interface without inheritance of implementation.

---

I think you could meaningfully discuss things in terms of a implementation "mix-in". Eg, two classes that both perform an alphabetical sort, but for whatever reason do not actually share any code, might be considered to have mixed in an interface.

That's a very broad brush, but that was my point -- terms like inheritance should not be construed so narrowly as to become circular. The question "What is inheritance for?" is more important than "How does inheritance work?" or even "What can I do with inheritance?".

Quote:

---

"Wetness" is one aspect that we can use to identify water as "liquid water"; "inheritance" is one aspect that can we use to identify that something in a program is "object oriented".

---

If the answer to the question, "What is inheritance for?" is "To implement object inheritance" (this is the circularity), then I don't think it is can be used to identify OOP -- but it might be used to identify a style of OOP. If the answer is, "To facilitate code sharing", then it could, but it sort of redundant, like I said, because any language that could, even primitively, permit something like OOP, would also permit code sharing between classes via global functions, pointers, whatever.

But it makes sense to define inheritance more strictly -- such that it refers to a specific system of code sharing involving base and derived classes -- just I don't quite see how that could be called essential to OOP. So inheritance is either a sort of red herring in the definition, misses the forest for the trees, etc, or you could just regard it as what I meant by "wetness" -- the possibility for classes to share code -- which makes it sort of redundant. Yes, water is wet. Yes, classes encapsulate code (and code can be used in multiple contexts if written properly).

So I guess I mean it's better to think of inheritance as an OO methodology, but not prerequisite to it...which is why most people, when they first write classes and such, probably do not make use of inheritance until later, and why you could have an OO program that does not contain any inheritance structures.

Quote:

---

Originally Posted by MK27

If the answer is, "To facilitate code sharing", then it could, but it sort of redundant, like I said, because any language that could, even primitively, permit something like OOP, would also permit code sharing between classes via global functions, pointers, whatever.

---

Sure, but does the "code sharing" constitute inheritance? I do not see a redundancy here.

Quote:

---

Originally Posted by MK27

But it makes sense to define inheritance more strictly -- such that it refers to a specific system of code sharing involving base and derived classes -- just I don't quite see how that could be called essential to OOP.

---

What do you mean by "specific system"? If you are saying that this system excludes say, prototype-based inheritance or my hypothetical example in post #36, then of course this "specific system of code sharing" is not essential to OOP.

Quote:

---

Originally Posted by MK27

So I guess I mean it's better to think of inheritance as an OO methodology, but not prerequisite to it...

---

What do you mean by a "prerequisite"?

Quote:

---

Originally Posted by MK27

which is why most people, when they first write classes and such, probably do not make use of inheritance until later, and why you could have an OO program that does not contain any inheritance structures.

---

That's where my motivation for considering inheritance and polymorphism as core OO concepts lies: if we say that they are not essential to OOP, then in theory we can leave them out, and progress with OO design without them. In practice, a considerable amount of what makes OOP a useful paradigm lies in including them, in some form or another. So, I see them as essential to OOP, even if a particular program might reasonably be regarded as an "OOP program" without them.

Quote:

---

Originally Posted by laserlight

Sure, but does the "code sharing" constitute inheritance?

---

No, which is why I've kinda been changing my tune. Initially I said (somewhere,lol ) that I consider inheritance a fundamental characteristic of OOP, but following the discussion by you, Elkvis, and brewbuck, I'm now thinking that is not really true, and that I was simply regurgitating without thinking much.

Quote:

---

What do you mean by "specific system"? If you are saying that this system excludes say, prototype-based inheritance or my hypothetical example in post #36, then of course this "specific system of code sharing" is not essential to OOP.

---

Exactly. Either you have to make the concept of inheritance so general that it just means "code sharing" and therefore would always be possible -- which why do that? -- or you have to acknowledge that while inheritance is a very useful OO concept, it is not essential to (ie, prerequisite to) OOP.

Quote:

---

What do you mean by a "prerequisite"?

---

I mean, what are the "necessary and sufficient" characteristics. I think that defining things that way is possible and useful, but it in the case of OOP it would not include inheritance. The only things that are necessary are the concepts of class, method, and object instance, and deploying those concepts would be the minimum sufficient elements to identify something as OOP.

I know that is more minimal than most definitions. Eg, here's a list of "necessary and sufficient" characteristics from a textbook (part of what I regurgitated):

1. Encapsulation (incorporating code as class methods)

2. Aggregation (incorporating objects into other objects, which in reality would be more or less synonymous with the possibility of instantiating an object from a class)

3. Inheritance

4. Polymorphism

I see a clear line between 1 & 2 and 3 & 4 -- 3 & 4 depend upon 1 & 2, but 1 & 2 do not depend upon 3 & 4. So I would say 1 & 2 constitute the minimal core of OOP, which 3 & 4 require to be meaningful.

I guess it's sort of like saying a city street system requires:

1. Intersections

2. Addresses

3. Vehicles

4. Signs and signals

I'll agree with 1 & 2, and in reality 3 & 4 may expand the possibilities provided by 1 & 2, but they are not necessary.

Could you tell me how you would use polymorphism without inheritance though? Doesn't polymorphism promote code reuse because the way your client code behaves depends on the type of the objects used?

Quote:

---

Originally Posted by whiteflags

Could you tell me how you would use polymorphism without inheritance though?

---

I guess polymorphism assumes some possibilities of inheritance -- but I dunno if those possibilities are necessary and sufficient to constitute inheritance. I just started learning java, and it seems to me that interfaces involve polymorphism, but not necessarily inheritance.

If you don't know any java, I guess you could look at an interface as as sort of abstract base class. Hence, you could (I think) emulate a java interface in C++, but you would (probably) use virtual functions, which of course do exploit inheritance.

But a java interface is not actually a class, and the relationship between an interface and a class is about implementation, not inheritance.

Also, polymorphism is essentially "automatic" in dynamically typed languages and does not require the concept of inheritance, altho the concept could be applied.

Quote:

---

Doesn't polymorphism promote code reuse because the way your client code behaves depends on the type of the objects used?

---

Sure, but is code re-use essential to object orientation? Or is it just that object orientation and polymorhism are advantageous to the goal of code re-use?

My train of thought with all this is about de-tangling OOP nomenclature and making it easier to understand in relation to "procedural programming" based on what I wrote in post #6:

Quote:

---

I'd say that object oriented programming is not contra procedural programming at all. It just adds a sort of meta perspective to it, opening up and structuring different possibilities.

---

Since the OP seems intimidated by it, which is ridiculous, and perhaps the consequence of excessive mystification? Like I said earlier, you can learn to write classes and use objects before you understand anything about inheritance. At that point, I'd say you were doing OOP. Which you would have to do before you could use inheritance and/or polymorphism. Just like cars and traffic regulations make sense if you have a network of streets, but a network of streets is still a useful as a network of streets without vehicles or formal traffic control.

Quote:

---

If you don't know any java, I guess you could look at an interface as as sort of abstract base class. Hence, you could (I think) emulate a java interface in C++, but you would (probably) use virtual functions, which of course do exploit inheritance.

But a java interface is not actually a class, and the relationship between an interface and a class is about implementation, not inheritance.

---

With the limited Java knowledge that I have there is literally not a thing different about them than a abstract base class in C++. If you don't completely implement an interface in Java, then the thing that you implemented is an abstract class, and neither interfaces or abstract classes can be instantiated. The previous sentence applies exactly to abstract base classes in C++. Maybe there is a real, tangible difference between inheritance and interfaces that I'm not getting from your post but I am comfortable with the idea that this is Java's syntactic sugar at work.

Quote:

---

Sure, but is code re-use essential to object orientation? Or is it just that object orientation and polymorhism are advantageous to the goal of code re-use?

---

My opinion is that polymorphism is the biggest reason people bother with inheritance (in C++) at all. It doesn't necessarily save you time if you're working on an entirely new code base but it does when you need to extend an existing one.

I would think that code reuse is essential to object orientation. It's possible that, if some class is already tailored enough to use on task xyz, that the other meaning of code reuse applies. Here's a wheel let's not re-invent it.

If I had anything to say to the OP, it wouldn't be anything better than what's been said already though. OOP is not the big bad wolf of programming, and lots of people start by understanding encapsulation, to great effects.

Quote:

---

Originally Posted by MK27

The only things that are necessary are the concepts of class, method, and object instance, and deploying those concepts would be the minimum sufficient elements to identify something as OOP.

---

If you want to be so minimalist, then I posit to you that the concept of a class is not necessary for object oriented programming. Each object has its own type, and there need not be the subtyping - that is related to inheritance and subtype polymorphism - which can be expressed by thinking in terms of class hierarchies. (We could use prototype based inheritance instead... but inheritance is not necessary, right?)

Frankly, such a minimalist "OOP" paradigm throws out so much of what is useful to OO design that it is hardly useful, so what's the point? Just to come up with a list of "core of the core concepts" that cannot be disputed?

Quote:

---

Originally Posted by MK27

I just started learning java, and it seems to me that interfaces involve polymorphism, but not necessarily inheritance. (...) But a java interface is not actually a class, and the relationship between an interface and a class is about implementation, not inheritance.

---

A Java interface is not a Java class, but otherwise a Java interface is an abstract base class with special restrictions (and for which multiple inheritance is allowed, unlike for Java classes), just like how a C++ abstract base class with similiar characteristics is a pure interface. The relationship between a Java interface and a Java class that implements that interface is entirely about inheritance, i.e., inherit not to reuse, but to be "reused".

Quote:

---

Originally Posted by laserlight

Frankly, such a minimalist "OOP" paradigm throws out so much of what is useful to OO design that it is hardly useful, so what's the point? Just to come up with a list of "core of the core concepts" that cannot be disputed?

---

Yes, absolutely, because it seems to me that is a better place to start -- with the necessary and sufficient concepts of encapsulation and aggregation, and then bring up inheritance and polymorphism later.

I'm certainly not saying inheritance and polymorphism are unimportant esoteric topics! I think they are very useful OO methodologies, they are just not, as you say, essential "core of the core" concepts.

I agree that my thing about java interfaces is sort of semantics, and I would not bother with arguing that they cannot be explained in terms of inheritance. However, they can also be understood and explained without the concept of inheritance, which is not true of base/derived/virtual classes. Does that matter or mean anything? What's "the reality" of inheritance? It's a form of code sharing, but not all code sharing is inheritance.

Function overloading also seems to me like a form of polymorphism that can be understood and explained in terms of inheritance, but does not need to be. It just requires the concept of polymorphism and polymorphism != inheritance. If I drew a circle around "the reality" of inheritance, I'd probably restrict it to phenomenon to which it is integral, such as base and derived classing.

Quote:

---

Originally Posted by MK27

Yes, absolutely, because it seems to me that is a better place to start -- with the necessary and sufficient concepts of encapsulation and aggregation, and then bring up inheritance and polymorphism later.

---

Ah, if you are talking in terms of pedagogical order, then certainly I agree. It seemed more to me that you were talking about pedagogical syllabus instead, i.e., that inheritance and polymorphism could be deferred and hence possibly ignored as "advanced topics" rather than as part of a core syllabus.

Quote:

---

Originally Posted by MK27

they can also be understood and explained without the concept of inheritance

---

No, they can be understood and explained without mentioning inheritance, but the concept of inheritance is inherent in Java interfaces as hierarchies for subtype polymorphism a formed.

Quote:

---

Originally Posted by MK27

Function overloading also seems to me like a form of polymorphism that can be understood and explained in terms of inheritance

---

No, function overloading is ad hoc polymorphism, not subtype polymorphism that is related to inheritance.