Why do subclasses exist and how do they impact code maintenance?

[0rthodontist]

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

public class Blob
{
  public int mass;
}

then defining

public class Ball extends Blob
{
  public int radius;
}

provides all the same functionality as defining

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?

 

[neurocomp2003]

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 want to 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.InteractwithBtw is that java language or some pseudo OO u typed in?

 

[0rthodontist]

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().

 

[-Job-]

Inheritance can save you a lot 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?

 

[neurocomp2003]

Orthodontist: for simple or small code what you say may be true.
But let's 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.

 

[0rthodontist]

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.

 

[chroot]

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

 

[0rthodontist]

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).

 

[chroot]

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

 

[0rthodontist]

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.

 

[chroot]

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

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

 

[0rthodontist]

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.

 

[chroot]

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.

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

 

[0rthodontist]

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.

 

[chroot]

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

 

[0rthodontist]

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.

 

[chroot]

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

 

[0rthodontist]

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.

 

[chroot]

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.

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

 

[0rthodontist]

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.

 

[chroot]

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.

Excuse me? I have never once used an IDE to develop Java. Not even a single time! I use TextPad on Windows, and nedit on Unix. I have never been even remotely dependent on a development environment.

Sure, sure... I need to look at the API docs to remember how to do things, but that is absolutely not the same thing as being dependent on a development envrionment trying to keep me from making a mistake like coding A.b.foo() instead of A.foo().

Again, what advantage does your "inheritance" scheme offer anyone? All I can see are disadvantages -- and one is the size of an elephant. If you give programmers two methods -- A.foo() and A.b.foo() -- and expect them to never forget which is which, you are a fool.

Besides, think about how much fun it'll be when it ends up being the choice between:

A.b.c.d.foo()
A.B.c.d.foo()
A.b.C.d.foo()
..
..
..
..

Please just tell me you're backed into a corner right now and have no real arguments left. Please tell me you're kidding me that you think this is somehow "better" than the syntactically simple inheritance used by Java and C++.

- Warren

 

[0rthodontist]

I see you raising arbitrary complaints for no good reason. When I mentioned IDE's, you laughed because you don't use one, even though a great many programmers, including myself, do and find them quite useful. When I mentioned Javadoc, you said almost nothing because you had nothing to say.

Programmers would not have to write A.b.c.d.foo(). They would only write A.foo(), as I clearly explained on the previous page, which you must have read or else you wouldn't be using the function foo() to illustrate. There would only be a difference between A.foo() and A.b.foo() if A has overridden the foo method in b, and programmers using member variable inheritance would always use the version in A whenever they were treating A as a subclass of B, and they would always use the version in b whenever they were treating b as a member variable of A. It's really not very confusing.

I'm done with this discussion. You understand my point, whether or not you agree, and I don't want to argue any more.

 

[chroot]

It's extremely confusing.

Let's say you release code for class A, which inherits B as a member variable. Let's say that originally, there's a method called foo() in B that is left alone -- that is, not overriden by B.

Then, every programmer would simply use A.b.foo() to refer to that method.

A few months later, you realize there's a small bug, and you actually need A to override B.foo() to do some kind of check. You add the method to A and hit "commit."

Now, everyone who's been using your code all this time has been using A.b.foo(). Even when they download and unpack your latest release, with the bug fix, they'll continue using the buggy A.b.foo(), because that's what they coded months ago. Your "small" change has instantly rendered every piece of code on the entire planet which uses your code obsolete.

The only solutions are (a) to use some kind of an IDE which will go through every single line of code and change every single call to make sure it's now using the right one or (b) to force your users to crawl through code they wrote months ago to update A.b.foo() to A.foo(). Can you imagine the mayhem? The hundreds of engineering change orders? The enormous task of keeping track of the latest documentation and changes in hundreds of pieces of code that go into a modern, large project?

Your proposal is a recipe for disaster. Trying to force programmers to depend on an IDE to prevent errors is not an acceptable solution, particularly when a very much simpler solution already exists which is not susceptible to these kinds of bugs, and does not require the latest version of some IDE, or an IDE at all!

- Warren