Like Tree15Likes

Explain Object-Oriented Programming Like I'm 5

This is a discussion on Explain Object-Oriented Programming Like I'm 5 within the General Discussions forums, part of the Community Boards category; Originally Posted by Elkvis I would say that inheritance and virtual functions should be considered core concepts of OOP. Yeah, ...

  1. #31
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  2. #32
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,498
    Quote Originally Posted by laserlight View Post
    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 .
    Manasij Mukherjee | gcc-4.8.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  3. #33
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #34
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by manasij7479 View Post
    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.
    MK27 likes this.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #35
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by manasij7479 View Post
    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.
    Last edited by MK27; 01-12-2012 at 08:47 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #36
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    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".
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #37
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by laserlight View Post
    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?".

    "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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #38
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #39
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by laserlight View Post
    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.

    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.

    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.
    Last edited by MK27; 01-12-2012 at 12:37 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  10. #40
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,656
    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?

  11. #41
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by whiteflags View Post
    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.

    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:

    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.
    Last edited by MK27; 01-12-2012 at 03:56 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  12. #42
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,656
    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.

    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.
    Last edited by whiteflags; 01-12-2012 at 06:14 PM.
    MK27 likes this.

  13. #43
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    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".
    Last edited by laserlight; 01-12-2012 at 07:09 PM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #44
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by laserlight View Post
    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.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  15. #45
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,588
    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.
    MK27 likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. [help] Object-Oriented Programming
    By null321 in forum C++ Programming
    Replies: 4
    Last Post: 08-02-2009, 12:29 PM
  2. object oriented programming
    By l2u in forum C++ Programming
    Replies: 10
    Last Post: 11-06-2006, 09:18 AM
  3. Object Oriented Programming
    By eric123 in forum C++ Programming
    Replies: 6
    Last Post: 11-30-2005, 03:56 AM
  4. Replies: 4
    Last Post: 11-19-2002, 08:18 PM
  5. C++ and Object Oriented Programming
    By Visual Develope in forum C++ Programming
    Replies: 3
    Last Post: 05-05-2002, 05:27 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21