Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Superclass or Member Variable

  1. Aug 2, 2006 #1

    0rthodontist

    User Avatar
    Science Advisor

    There is essentially no difference between a superclass of a class and a public member variable of that class. For example, if you define
    Code (Text):

    public class Blob
    {
      public int mass;
    }
     
    then defining
    Code (Text):

    public class Ball extends Blob
    {
      public int radius;
    }
     
    provides all the same functionality as defining
    Code (Text):

    public class Ball
    {
      public Blob b;
      public int radius;
    }
     
    The only difference is a slight one of notation.

    So why have subclasses at all? Are there object oriented languages that explicitly take advantage of this?
     
  2. jcsd
  3. Aug 2, 2006 #2
    inheritance/Polymorphism? One example would be the concept of Entities and Interactions and Scene Management/N-body tree codes. You have different Physical Entities in your world...and you wanna manage them by Scenetrees and you want interactions amongest different entities(eg game development). Rather than having to code scene functions for every type of of physical entity. You employ inheritance and Polymorphism.
    And allow the scene to handle some base class(physics struct). with some common functions like Update/Collide with/Distance/time before collision.Interactwith


    Btw is that java language or some pseudo OO u typed in?
     
    Last edited: Aug 2, 2006
  4. Aug 3, 2006 #3

    0rthodontist

    User Avatar
    Science Advisor

    It's Java.

    But my point is that having something as a member variable is all you need to inherit its functions. If A extends B, and B has the function "foo" then you can write A.foo();. If A contains a member variable b, where b is an instance of B, then you can write A.b.foo(); and it means exactly the same thing.

    Polymorphism isn't so nicely accounted for in this system, but I suspect it wouldn't be difficult to allow it to be. The only noticeable change you'd have to have is the syntactic nudge of allowing reference to A.b.foo() by just saying A.foo().
     
    Last edited: Aug 3, 2006
  5. Aug 3, 2006 #4

    -Job-

    User Avatar
    Science Advisor

    Inheritance can save you alot of code. Maybe Blob has a bunch or methods that you'd like Ball to have; with inheritance you don't have to recode those, or create wrappers. Polymorphism is a great advantage too. You might get away with using an interface but why would you if you can use inheritance?
     
  6. Aug 3, 2006 #5
    Orthodontist: for simple or small code what you say may be true.
    But lets say you have 3 more extensions. C.A.B.foo() D.C.A.B.foo E.A.B.foo.
    Now you needed a function (in or not in a class) to call all these without knowing which object its being passed. THen you would need to overload the smae function for each...or create different function names.
    eg. void Fx(TType x) { x.foo()} where TType is all the classes you have.
    You could use a template but i don't know if Java uses a Template.
    And if java doesn't use a template than a vector template class is another example of inheritance...though it may not be efficient as coding each class..and more than likely you could use #define coding.
     
  7. Aug 3, 2006 #6

    0rthodontist

    User Avatar
    Science Advisor

    I think you're getting bogged down in the technical details. The point is that IN ESSENCE inheritance and public member variables are the same, even if you have to add some syntax to make them actually look the same. If you define the rule:
    --if a is an instance of A, and A contains as a public member variable b, which is an instance of B, all public member variables in b can be referred to just as if they were public member variables in a. So instead of a.b.foo(), you can write a.foo().
    --if the above is true, if A has any names that are the same as public variables in b, then those names override the names in b. So if A already has declared a foo() function, then A.foo() means only A.foo() and not A.b.foo().

    If this is done, and a rule or two added to allow member variable polymorphism without producing a compile error, then inheriting a class just IS the same as having the class as a member variable.

    In the case of your C.A.B.foo(), D.C.A.B.foo(), or E.A.B.foo() (referring to the class names as if they were instances) then this would mean you could say D.C.A.foo() by the first rule above. Then you could say instead D.C.foo() again by the first rule above. And then you could say D.foo() and in summary, by a threefold application the first rule above it means exactly the same thing as D.C.A.B.foo(). The same goes for the others: you could say C.foo(), or E.foo(), instead of having to say C.A.B.foo() or E.A.B.foo(). It would work in exactly the same way as inheritance.
     
    Last edited: Aug 3, 2006
  8. Aug 3, 2006 #7

    chroot

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    I can appreciate that, in small textbook examples, it can seem like inheritance is just a novelty with no real purpose.

    However, in large designs, it can be a tremendous advantage. Let's say you write some kind of computing engine, and decide to use a Model-View-Controller design pattern for its user interface.

    Your system might have a bunch of different views. Users might be interacting with the system through a web browser, or a mobile phone. Operators might be interacting with the system through Unix commands.

    If you code it correctly, each of these different views connects to the rest of your system via some standard interface. WebView and MobileView and CommandLineView might all be subclasses of a View class, which defines all the methods of the view interface.

    Then, when you change your underlying system, all the views react accordingly without having to change a single line of code in them.

    - Warren
     
  9. Aug 3, 2006 #8

    0rthodontist

    User Avatar
    Science Advisor

    The point is not that inheritance isn't useful--it is--but that there is no compelling need to have a separate "inheritance" mechanism that is different from having the superclass as a member variable, (with the syntactic modifications mentioned).
     
    Last edited: Aug 3, 2006
  10. Aug 3, 2006 #9

    chroot

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    You need true inheritance -- not just superclass member variables -- if you want polymorphism. My previous example about the Model-View-Controller pattern was supposed to have made that clear.

    - Warren
     
  11. Aug 3, 2006 #10

    0rthodontist

    User Avatar
    Science Advisor

    If you alter the syntax to allow objects to be polymorphic with their member variables, it works exactly the same.

    The only unaddressed capabilities in Java are abstract classes and the protected keyword. Abstract classes can be easily worked into a member-variable-based inheritance, but the protected keyword is a snag.
     
  12. Aug 3, 2006 #11

    chroot

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    No, it doesn't. Polymorphism has to be a feature of the language itself, and cannot be "emulated" with syntactic tricks.

    For example, say you have two classes A and B, each of which are supposed to be derived from C. Also, you have a piece of code, X(), which intends to operate on any derivative of C.

    If A and B are distinct classes, and only have an instance of C as a member variable, then X() actually has to be written twice -- once to accept type A, and once to accept type B.

    Java is a strongly-typed language, and the mere fact that A and B each have a member variable C does not somehow make the compiler see them as polymorphic.

    - Warren
     
  13. Aug 3, 2006 #12

    0rthodontist

    User Avatar
    Science Advisor

    I'm saying, you alter the syntax, not the way you write the code. The current Java language does not have syntax to support member variable polymorphism. Another language, maybe similar or maybe not, could have such syntax.
     
  14. Aug 3, 2006 #13

    chroot

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    So.... what you're saying is that you could design a polymorphic language with a different syntax.

    Let me be the first to say... duh?

    - Warren
     
  15. Aug 3, 2006 #14

    0rthodontist

    User Avatar
    Science Advisor

    The non-"duh" about it is that member variables are similar enough to superclasses that only small syntactic changes have to be made to turn Java into such a language.
     
  16. Aug 3, 2006 #15

    chroot

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    Sure, but that also complicates method inheritance.

    If A and B "inherit" C, then A and B have to have a copy of the declaration of every method in C. All the methods which are inherited without change end up having bodies that look like this:

    public method(Argument a)
    {
    return c.method(a);
    }

    Sorta pointless to have to write all these "shell" functions everytime you want to use inheritance, isn't it? Not to mention the performance hit you'll take for all those extra, unnecessary stack frames.

    Besides, I don't know why you have an issue with the way the Java (and C++) implement polymorphism in the first place. Your proposal just makes more work for the programmer, doesn't look nearly as elegant, and produces less-efficient machine code.

    Why are you trying to re-design a language before you really even know how to use it?

    - Warren
     
  17. Aug 3, 2006 #16

    0rthodontist

    User Avatar
    Science Advisor

    No, with the syntactic modifications I suggested earlier, you can refer to functions in a member variable as if they were functions of the object, with some provisos. No need to rewrite methods like that.

    The advantage is a reduction of syntactic sugar.
     
  18. Aug 3, 2006 #17

    chroot

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    Oh, great. So then you're going to force the users of your class to know which methods exist in the class itself, or in the "superclass member variable?"

    So if A inherits C, then there are two methods floating around, A.foo() and A.c.foo(), and the user has know and remember which one to call, or Bad Things happen.

    Damn, that sounds really stupid. No offense intended, but you need to think about this a bit more.

    - Warren
     
  19. Aug 3, 2006 #18

    0rthodontist

    User Avatar
    Science Advisor

    Well, the superclass member variable DOES have to be public, so it wouldn't be any trouble. I'm sure it wouldn't be hard to modify the development environment to make it easy to look at such functions, just like Eclipse now makes it easy to look at functions of a superclass as if they were functions of the object.
     
  20. Aug 3, 2006 #19

    chroot

    User Avatar
    Staff Emeritus
    Science Advisor
    Gold Member

    :surprised

    So now you're suggesting that, instead of making the language easy to use, we should make programmers become RELIANT ON THEIR DEVELOPMENT ENVIRONMENTS (which are probably not bug-free!)???

    :rofl: :rofl: Just give it up, man. This is a guaranteed way to write dysfunctional software.

    - Warren
     
  21. Aug 3, 2006 #20

    0rthodontist

    User Avatar
    Science Advisor

    Java is CURRENTLY dependent on the development environment for anyone to know what functions an arbitrary object has! Or on the Javadoc, and of course member variable inheritance could easily be incorporated into the javadoc as well.
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Have something to add?



Similar Discussions: Superclass or Member Variable
Loading...