JS: Is class inheritance absolute?

user_14846677 0
Viewed 86

If I have a class:

class Car {
   constructor(type, engine) {
      this.type = type;
      this.engine = engine;
   },
   makeSound() {
      return "vrooom"
   }
}

if I want a subclass called MiniVan, I know this would be how to inherit and add properties to it:

class MiniVan extends Car {
    constructor(type,engine,brand) {
       super(type,engine);
       this.brand = "Chrysler";
   }

   makeMiniVanNoise() {
      return "honk"
   }
}

do I have to inherit all properties? What if I just wanted the type but not the engine from the base class Car ?

javascript
1 Answers

Yes

When one class extends another class, the subclass constructor must (i.e. MUST) call super. As a result, every instance of the subclass will begin with whatever properties and methods the superclass normally defines. This is how class tech works.

... but no

That said, there's nothing in the rulebook that prevents the constructor from then going on to mangle the instance so it's unrecognizable as an instance of the superclass. You can delete or overwrite properties and methods pretty much however you see fit. And that isn't just limited to the constructor; you can also declare instance methods that clobber instance methods on the superclass, and so on.

... but don't.

As commenters have noted, this is frowned upon (unless you have a good reason). Why?

The number one job of code is to be understood by humans, not merely to run without errors. We have a term for code that gets the job done but does it in a confusing or counterintuitive way: "a hack."

When you define a class as a subclass of another class, you aren't merely invoking some re-use machinery. Most importantly, you are saying to future developers that a specific kind of relationship exists between these two categories of thing. The machinery of OO inheritance is designed in support of that goal.

You don't get to decide what that relationship is: the language designers picked it, and the only choice you get to make is whether to describe this logic in terms of that relationship.

It didn't have to work that way! Language designers could have decided that a subclass will only have the methods of the super class, dropping all the properties. Or they could have said it will only have the properties and methods whose names don't begin with _. Or that the subclass will only have the first 5 properties or methods that the superclass defines. Call these the "Bizarro Rules."

Programming is heavily concerned with conceptual analysis. That involves thinking about categories, distinguishing between intrinsic and extrinsic, necessary, sufficient, and accidental, etc.

The reason language designers didn't design things to follow the Bizarro Rules is because the Bizarro Rules do not flow naturally from any kind of reasonable conceptual analysis.

Your code will be easier to understand if it encodes business logic and data storage in a way that maps directly onto the ontology, relationships, and operations that exist in the problem space.

Put concretely: a spreadsheet program will be easier to understand if it has explicit constructs for Cells, Formulas, Worksheets, and so on. If you don't, future developers will have a hard time making sense of it, and will not be helped by any amount of studying spreadsheets in general. You want the opposite: if the world's greatest authority on spreadsheets looks at your code, you want their expertise to help them understand what your code is doing and why.

Class-based inheritance, and a lot of other language features, were designed to help you maintain that straightforward conceptual mapping. You can use those features in ways that undermine that, but then you're "cutting against the grain," and that will make the job of every maintainer (including Future You) harder than it has to be.

How hard do you want your job to be next week? Easier than it is today, or harder? That is what you are deciding.

Because all the other language features were designed with the assumption that you're not fighting the system, if you decide to plow ahead and fight the system anyway, you will sometimes find that you've painted yourself into a corner: you won't be able to make a desired functional change without first having to perform significant refactoring.

Here's my definition of good code:

Good code must:

  1. Do the right thing
  2. For the right reasons
  3. In the most obvious way possible

#3 is kind of like Occam's Razor. You may be able to "misuse" OO machinery to accomplish code re-use, but it's not the most obvious way to do that, and so future developers will probably misunderstand what you were trying to achieve. And when they do figure it out, their first reaction will be, "why the hell did RicardoAlvveroa say that a Pizza is-a Vehicle?!"

user_8144630
Related