this post was submitted on 13 Apr 2024
729 points (95.8% liked)
linuxmemes
21273 readers
443 users here now
Hint: :q!
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I've seen this thing where people dislike inheritance a lot, and I have to admit that I kind of struggle with seeing the issue when it's used appropriately. I write a bunch of models that all share a large amount of core functionality, so of course I write an abstract base class in which a couple methods are overridden by derived models. I think it's beautiful in the way that I can say "This model will do X, Y, Z, as long as there exists an implementation of methods A, B, C, which have these signatures", then I can inherit that base class and implement A, B, and C for a bunch of different cases. In short, I think it's a very useful way to express the purpose of the code, without focusing on the implementation of specific details, and a very natural way of expressing that two classes are closely related models, with the same functionality, as expressed by the base class.
I honestly have a hard time seeing how not using inheritance would make such a code base cleaner, but please tell me, I would love to learn.
What you're describing is an interface. An interface is a contract that ensures you can do something, but doesn't care how.
Abstract classes can have abstract functions. When you do this, you're basically just creating a base class with an interface on top; you're saying "all my children must implement this interface of mine" without having to actually make a separate interface.
Abstract classes also offer additional functionality though, such as the ability to define properties, and default implementations of methods. You can even utilize the base class implementation of the method in your child class, in order to perform extra steps or format your input before you do whatever it is you were doing in the first place.
So, an interface is a contract that allows you to call a method, without having to know the specific class or implementation.
Inheritance is more like "it does everything that X does, but it also does Y and Z." If you're ever finding yourself writing an abstract class with purely abstract methods, you probably want to write an interface instead. That way, you get all the same functionality, but it's more loosely coupled
Epecially when you think in "real" OOP terms:
Abstract classes are "child is a parent", fx "duck is a bird". Bird describes all the traits that all birds have in common. But not all birds fly, so flight must come from an interface. This interface can be passed around to any number of objects, and they're not as tightly coupled because unlike an abstract class, an interface doesnt imply that "duck is a flight". The interface is just something we know the duck can do.
As you can probably tell, I work with OOP on a daily basis and have for years. There are a lot of valid criticisms of the OOP philosophy, and I have heard a lot of good points for the record. I am just educating on the OOP principles because you said you were interested and to clear up any misconceptions.
Well yes, I get the differerence between an interface and a class, and what I write is typically a class, which contains properties and functionality that may or may not be overridden in derived classes.
For example, calling a parent class implementation can be useful when I have a derived model that needs to validate its input in some specific way, but otherwise does the same as the base class.
What I don't understand is why this makes OOP bad?