10 Interview Questions Every JavaScript Developer Should Know
Eric Elliott

“5. When is classical inheritance an appropriate choice?” “never” and anything else being a red flag is incredibly short sighted.

Not going to argue that there are tons of cases when classical inheritance fits nicely (UI libraries for example). If I have a set of types that have shared logic and I want to add to it in different ways, inheritance is a straightforward concept, while composition on the other hand is clunky.

But I’m not even saying this from the technical point of view. If you ask an open question like this, and assume there is only one correct answer, you sir are almost always wrong.

There are reasons why some things in computing are the way they are. Most of the languages were designed by incredibly smart people who had good reasons for putting features in. Surely you might think that multiple inheritance in C++ is an abbomination, but that doesn’t mean you should avoid it 100% of the time (related http://stackoverflow.com/a/407885/72583). Much like GOTO does have an occasional use case. Much like Haskell people will occasionally use a nasty hack to escape their IO monad in the ugliest unsafest way possible. Last but not least, there’s also the argument of using a switch is always wrong, use polymorphism or dictionary dispatch or anything else to avoid it, which is just as equally ignorant.

Just because something is new and trendy doesn’t mean the older stuff is worse. Just because React does XYZ doesn’t mean, that we should all abandon everything and follow the one true way to do things.

Above all, people should use their brain when discussing these things. Don’t get stuck in the ways of people who try to sell their latest library on a conference last week.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.