<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:12.666666984558105px">"Honest question: how can this problem not be solved via ES6 classes plus mixins? The original hierarchy already feels wrong. Why not create a super-class Animal, with sub-classes Human, Ape, Bird, Bee, Fish, Whale plus the mixins Walking, Flying, Swimming?"<br>
</span><br>I completely agree with you, but in the real world we don't always have the benefit of knowing future requirements enough to create the correct design from the outset. Maybe the design was correct in the beginning (immagine a classification of species, instead of a classification of species capabilities)... and that's the problem with class - "<span style="font-family:arial,sans-serif">so you go to re-implement them as mixins, but now you have to refactor all the animals that already rely on those features"<br>
<br>"</span><span style="font-family:arial,sans-serif;font-size:12.666666984558105px">I also donít see why refactoring is such a bad thing: as your knowledge of the problem domain increases, the structure of your program evolves."<br>
<br>Small refactors are not a bad thing, but class hierarchies create tight coupling between child and parent classes (yes, even ES6 class, especially with super). In these situations, the dependencies are not always obvious, or direct, and they tend to ripple out far and wide, and are not easily aided by technology -- it's not a matter of replacing some variable names across your project -- it's a matter of reengineering these to deal with systemic changes in behavior.<br>
<br>Mixins and other compositional reuse patterns don't create any tight coupling between child and parents, and much more easily provide for selective inheritance (I only want the banana, not the gorilla, banana, and entire jungle).<br>
<br>- Eric</span></div>