this post was submitted on 11 Apr 2024
13 points (93.3% liked)

Programming Languages

1167 readers
1 users here now

Hello!

This is the current Lemmy equivalent of https://www.reddit.com/r/ProgrammingLanguages/.

The content and rules are the same here as they are over there. Taken directly from the /r/ProgrammingLanguages overview:

This community is dedicated to the theory, design and implementation of programming languages.

Be nice to each other. Flame wars and rants are not welcomed. Please also put some effort into your post.

This isn't the right place to ask questions such as "What language should I use for X", "what language should I learn", and "what's your favorite language". Such questions should be posted in /c/learn_programming or /c/programming.

This is the right place for posts like the following:

See /r/ProgrammingLanguages for specific examples

Related online communities

founded 1 year ago
MODERATORS
[email protected]
13
If Inheritance is so bad, why does everyone use it? (buttondown.email)
submitted 7 months ago by [email protected] to c/[email protected]
31 comments fedilink hide all child comments
 

This essay says that inheritance is harmful and if possible you should "ban inheritance completely". You see these arguments a lot, as well as things like "prefer composition to inheritance". A lot of these arguments argue that in practice inheritance has problems. But they don't preclude inheritance working in another context, maybe with a better language syntax. And it doesn't explain why inheritance became so popular in the first place. I want to explore what's fundamentally challenging about inheritance and why we all use it anyway.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 7 months ago (1 children)

It does frustrate me that people say "composition over inheritance" and then act like the problem is solved.

For a start, dependency injection is an abomination. Possibly the single worst programming paradigm in the history of software development.

The only codebases I've seen that deliver on some of the promises of composition have been entity-component systems, but this concept hasn't even matured to the point of being a first-class language construct yet, so the programming style is pretty janky and verbose.

[–] [email protected] 8 points 7 months ago (2 children)

dependency injection is an abomination

I don’t think so, dependency injection has made testing easier in all static typed code bases I worked on.

[–] [email protected] 4 points 7 months ago* (last edited 7 months ago)

The general idea is to not test things that need to be mocked, keep all logic out of those and keep them at the edges of the application. Then you test the remaining 90% of your code which would ideally be pure functions that don't need mocks .

The remaining 5% can be integration tests which doesn't care about DI.

In reality this doesn't always work, because sometimes it's better to write a complex query with logic and let your database do the processing.

[–] [email protected] -1 points 7 months ago (1 children)

How does DI make testing easier, or the lack of it make it harder?

Having a framework scan your code tree for magic annotation and configurations, etc, in order to instantiate "beans" or what not, is the worst imaginable tradeoff I've ever seen in software development. Calling it an abomination sounds exactly right.

[–] [email protected] 4 points 7 months ago (2 children)

@okamiueru @balder1993

It's an overloaded term:

"Dependency inversion" is a language-agnostic technique for producing testable, loosely-coupled software.

"Dependency injection" just means dependencies should be passed in through the constructor, instead of being magically new()'d whereever.

"DI frameworks" are Satan's farts. Classpath-scanning nonsense that turns compile-time errors into runtime errors. Not only is your Ctr still coupled to your Svc, but both are now coupled to Spring.

[–] [email protected] 1 points 7 months ago* (last edited 7 months ago)

"DI frameworks" are Satan's farts. Classpath-scanning nonsense that turns compile-time errors into runtime errors. Not only is your Ctr still coupled to your Svc, but both are now coupled to Spring.

Let's qualify this: DI frameworks that use configuration files to specify the dependencies are Satan's farts. You can use the DI pattern but do the injection in source code to get full compile-time type checking and all the benefits of a fully packaged JAR or similar binary. The root of the evil is having text files as part of the packaging, and not having the tooling to treat those files as part of the source code at build time.

[–] [email protected] 1 points 7 months ago* (last edited 7 months ago)

I see. Thanks! Looking at wikipedia, it sure seems to be a case of an overloaded term.

I don't generally use the first and second one you mention, because it's in the "common sense / obvious" realm, and I don't like to use complicated sounding jargon for simple concepts. For example:

// Good:
MyClass(Resource(configValue))

// Bad:
MyClass(configValue) // which insides does something a'la resource = Resource(configValue))

If this is an example of dependency inversion... hm, I suppose. I suppose having a word for it is fine. "Inversion" also doesn't make much sense if you start out thinking that's what makes sense to begin with. As for the "dependency injection"? Sounds complicated, but really isn't. Not sure who these kinds of terms are supposed to help.

As for DI frameworks using the word injection. I've always thought made sense. Because the connotations of injections feel applicable. No one looks forward to "an injection", and aside from the obvious, its usually done by someone else, and you might not be aware of the details of what happened, and you have no good way of figuring out what it was, or why you suddenly start feeling weird.