|
|
|
|
|
by falcolas
4359 days ago
|
|
It's not DRY, but then again, the chances of not overwriting, or more likely adding something to that method are pretty small when your project becomes more than an illustration of a principle. For example, what if you want to add custom animations any time your `Character` takes an action? Suddenly, all that boilerplate you "abstracted" away through mix-ins is back, with a vengeance. How about if your physics for a `Projectile` are different than for a `Pickup`? What if your character suddenly picks up a Sling of Thrown Voices, and needs to apply conversation snippets to its projectiles? In simple examples, mixins are great and reduce a lot of boilerplate, but in reality they are rarely so clean. |
|
What's wrong with this?
For me, it's still clear that 'attack' and 'defend' extends the funcionality of the 'FightMixin'. I can see even the first glance, those are inherited methods, because they use super() (call parent methods)> How about if your physics for a `Projectile` are different than for a `Pickup`?
You need to implement two classes anyway. I see two possibilities:
I. If you have to implement this kind of different physics behavior only for Projectile. (Maybe you don't even need a mixin.)
II. If you have more Projectile-like objects, but they are not all the same. > What if your character suddenly picks up a Sling of Thrown Voices, and needs to apply conversation snippets to its projectiles?Is this a weapon which doesn't shoot projectiles, but make damage with voice or what? :D Then I think it's totally different, because if Character can have all kinds of different weapons and those behave different ways, mixins don't fit here. I would rather implement that like this:
then weapon can be instance of either Sword or SlingOfThrownVoices. Note that Mixins are still in use and no complicated inheritance problem occured even if you have hundreds of weapons.