Hang your code out to DRY • Hacker News Board

Re: Hang your code out to DRY

#11

Post by activitypea » Wed, Jan 12, 2022, 3:03 PM UTC

To me, inheritance and polymorphism are two different things. Polymorphism is about different units implementing an interface or equivalent protocol and that rocks. Inheritance is, essentially, dumping a bunch of code into your new class, and most of the time just imposes constraints and breaks API boundaries for no good reason. After studying and doing OOP for about 5 years, I don't see the advantages of inheritance over composition. The only value I see is libraries exposing base classes that enforce behavior on user-written subclasses, stuff like React's Component or Java's HttpServlet. Seems to me we can have polymorphism without subclassing as long as the programming language has a half-decent type system.

Re: Hang your code out to DRY

#12

Post by hansvm » Wed, Jan 12, 2022, 3:04 PM UTC

I think a lot of people have been burned by inheritance done wrong.

With a lot of other techniques, if the implementation isn't perfect and you don't own the library you're using you still have a lot of power available to patch things up and make everything play nicely together. Inheritance mixes implementation details with your type checking, so in a lot of languages that can make it extremely painful to turn a body of almost-good-enough code into something that's actually usable.

Re: Hang your code out to DRY

#13

Post by contravariant » Wed, Jan 12, 2022, 3:05 PM UTC

There's something to be said for preferring composition over inheritance, but in that case overly DRY code consists almost entirely of glue. As with almost anything it's a matter of choosing the right tool for the job.

The only code style advices that I've found to hold nigh universally are the following:

- The best code is no code

- Don't end classes in 'er' or 'or'

Coding paradigms are good when they let you do those things and are bad when they don't do both of those things (i.e. they result in more code or clases ending in 'er'; a class named 'Helper' is a code smell worse than sulfur dioxide)

Re: Hang your code out to DRY

#14

Post by piaste » Wed, Jan 12, 2022, 3:06 PM UTC

I use, and teach juniors basically the same rule as your first one.

I phrase it a little differently though: "if something happened in the future that required a change to function A, would the same requirement apply to function B as well?"

I think your second heuristic is valid but a little dangerous, because being good at naming functions is somewhat orthogonal to being good at maintaining code.

Re: Hang your code out to DRY

#15

Post by magicalhippo » Wed, Jan 12, 2022, 3:06 PM UTC

You don't have to use OO though. We're using an OO-oriented language at work, but I do a lot of de-duplication of code by extracting common functions.

If needed I can delegate the specialization to an interface or in a function reference parameter (so anonymous functions can be passed) rather than in a subclass.

When implementing the interfaces I might use subclasses though, if I have some very similar variants.

Re: Hang your code out to DRY

#16

Post by bschwindHN » Wed, Jan 12, 2022, 3:07 PM UTC

I don't think people are necessarily against polymorphism or factoring out common logic, but they're definitely against big class hierarchies in the old "OO" style.

Plain data structures with polymorphism via traits/interfaces/protocols seems like it's becoming the more popular way to handle these problems (I have no way to prove this, of course), and I prefer that way as well.

It's just the worst though when a dev sees two chunks of code that happen to be "shaped" the same and decide to tie them together with one abstraction. It's like seeing two different cables in a building that carry radically different signals but happen to go along the same path for awhile, and someone comes along and zip ties them together. You may have wanted to be able to route one of them completely differently, or maybe you wanted to add one more of the same cable, and now you have to cut up all the zip ties and either re-apply them (shove it into the existing abstraction), or bundle them up some other new way.

Re: Hang your code out to DRY

#17

Post by rimliu » Wed, Jan 12, 2022, 3:08 PM UTC

I came to conclusion that very few people actually understand what a good OO design is and ever fewer have skills to implement it. All this talk about SOLID patterns and what is more likely to result in overengineered monstrosity than in something elegant and easy to maintain.

Re: Hang your code out to DRY

#18

Post by Jtsummers » Wed, Jan 12, 2022, 3:08 PM UTC

DRY After Multiple Permutations

Re: Hang your code out to DRY

#19

Post by contravariant » Wed, Jan 12, 2022, 3:11 PM UTC

Don't add multiple parameters.

Delete all multifunctional programs.

Don't AMPlify code.

Re: Hang your code out to DRY

#20

Post by dahart » Wed, Jan 12, 2022, 3:30 PM UTC

There are multiple metrics to describe what “works” even means. You are right that battle tested code can be more stable and fulfill its goals more than new untested code or code written without a customer. At the same time it’s also true that any sizeable codebase, especially production code, will accumulate bugs over time, will almost always slow down over time, and will eventually once large enough become crufty and smelly and unfactorable and difficult and, maybe most importantly, expensive to maintain. Big systems are hard.