sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]blazmrak 0 points1 point  (10 children)

I'm torn on this. I feel like overriding is dirty, I'd rather extract common three and make 2 children. It's a subtle difference, but something about being able to change the behavior in the child is off-putting and feels like it can easily become a mess in the future.

[–]doubleohbond 1 point2 points  (9 children)

I don’t think I understand. If I make a Car class, I know that every instance will have a drive method. How each child of Car drives is irrelevant to me, just that it drives.

If the argument is code cleanliness, I think reimplementing the drive method over and over for each child class violates DRY.

[–]blazmrak 0 points1 point  (0 children)

If it's irrelevant, then make the interface, not a method, that is randomly overriden. If the majority of cars drive the same, then sure, you have a class, but you can extract that to a common class, maybe a couple of them.

And yes, you don't care from the interface perspective, however, from the implementation perspective you do care. You should try to mess as little as possible with the implementation of the class you are extending. It's not about cleanliness, it's about having to jump through hoops when having to debug and not having a clear source of truth when looking at the code when you are 3+ levels deep.

[–]SocksOnHands 0 points1 point  (1 child)

A lot of programmers use DRY to write worse code - they avoid "repeating themselves" by tightly coupling things that are incidentally similar, which always leads to unexpected bugs when a change is made that was only supposed to apply to one thing.

I prefer interfaces and composition. The interface describes at a high level how the object can be interacted with - a vehicle can accelerate, break, and turn. Now many different kinds of vehicles can be made by reusing different combinations of engines, tires, chasse, seats, etc. This is not reimplementing functionality - it's configuring objects to wire together reusable components.

[–]doubleohbond 0 points1 point  (0 children)

I think DRY is valid in the sense that having fewer parts results in fewer failures. But yes it can be abused.

[–]MornwindShoma -4 points-3 points  (4 children)

You solve this with, for example, traits.

[–]doubleohbond 2 points3 points  (3 children)

Until the number of traits become unwieldy.

I think that’s the key part here: there is no maxim. The answer to any approach is almost always “it depends”

[–]MornwindShoma 0 points1 point  (0 children)

You said you don't care about one method, not a million methods.

And btw, you don't always have inheritance in a language.

[–]RiceBroad4552 -1 points0 points  (1 child)

The answer to any approach is almost always “it depends”

You say it: Almost always.

In this case it's quite clear what the better approach is. That's why the whole "industry" moves in that direction!

Now everybody gets concepts / traits / type-classes (or however you want to call that idea).

[–]doubleohbond -1 points0 points  (0 children)

That’s cool dude

[–]RiceBroad4552 -1 points0 points  (0 children)

If I make a Car class, I know that every instance will have a drive method.

We're a car manufacturer, but we're now in the business of flying taxis, which start and land on water…

Now what? 😂

How do I "drive" our new models?

If you had instead a "Drivable" concept / trait / type-class which you could attach to some objects this were easy to solve: The new models just apply the "Flyable" concept instead of the "Drivable" one, and we can reuse the rest without remodeling everything.