3 ms·

I like Rust's solution. It doesn't have inheritance, which eliminates majority of OOP "architecture astronautics". It still has encapsulation and polymorphism,

• AnimalMuppet 6y ago
  ELI5: How do you have polymorphism without inheritance? That is, if I have a Foo with a virtual function f(), and I have Bar and Baz that inherit from Foo and have their own implementations of f(), then I have polymorphism. But if I don't have inheritance, then what? Do I have different instances of Foo that have different implementations of f(), but they're still all Foo (rather than something derived from Foo)?
  • deleted 6y ago
    [deleted]
  • dralley 6y ago
    >But if I don't have inheritance, then what? Do I have different instances of Foo that have different implementations of f(), but they're still all Foo (rather than something derived from Foo)? Yes, these are called "Trait objects" in Rust. https://doc.rust-lang.org/book/ch17-02-trait-objects.html https://doc.rust-lang.org/book/ch17-02-trait-objects.html
  • PaulDavisThe1st 6y ago
    put super-simply: Inheritance: T IS-A Foo Composition: T HAS-A Foo Neither: T IS-DESCRIBED-BY Foo
    • pjmlp 6y ago
      Neither => Component Based Programming, "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/Component-Software-Beyond-Object-Oriented-Programming/dp/0201178885 https://www.amazon.com/Component-Software-Beyond-Object-Orie... https://www.amazon.com/Component-Software-Object-Oriented-Programming-Addison-wesley/dp/032175302X https://www.amazon.com/Component-Software-Object-Oriented-Pr...
  • ywei3410 6y ago
    I see the other replies mention Rust/Haskell's traits and typeclasses; but a better example to use imo is Python's duck typing. If both objects `Foo` and `Bar` have a method called `baz`, calling `object.baz` will dispatch to the objects `baz` function, no inheritance needed. In that way, there are 3 ideas when you have inheritance. The first is reuse of code. The second is a relationship between 2 classes/types such that you get the Liskov Substitution principle. The third is dynamic dispatch based on object (or type/class in most cases). Almost all FP languages have the third (type classes, traits, generic interfaces, the list goes on) and the first (default implementations of traits/typeclasses) but none have the second.
  • HelloNurse 6y ago
    Bar and Baz can be a Foo without necessarily being derived classes that inherit from base class Foo. In Python defining function f is enough for a class to be a Foo (and Foo could not exist at all in code, replaced by the informal concept that a type with method f is a Foo) In languages like Java, there are interfaces, which are not classes at all and describe with tedious compiler-friendly explicitness what a class needs to qualify as a Foo. On a different variability axis, sometimes you need to declare interface implementations explicitly ("class Bar implements Foo" in Java) and sometimes not (Python duck typing, C++ concepts)
  • unionpivo 6y ago
    You have a trait Foo that has a function f() And then you have Bar and Baz that implement trait Foo. Example: pub trait Foo { // fn f(&self) -> String; // Default implementation, can be overriden fn banana(&Self) -> String { String::from("BananaNjam!") } } pub struct Baz { pub BazThingy: String, pub Whatever: String, } impl Foo for Baz { fn f(&self) -> String { format!("{} {}", self.BazThing, self.Whatever) } } pub struct Bar { pub Bar: String, pub Tralala: String, } impl Foo for Bar { fn f(&self) -> String { format!("{} {}", self.Bar, self.Tralala) } } // Now function that uses Foo, could be any object that implements foo pub fn FooFighter( item: &impl Foo) { println!("FooFighters rocks because {}", item.f() ); } The neat thing is that Bar and Baz does not have to share all of the traits. SO you can have default trait lets sey Debug, that prints object, on most objects, but Foo only on a few, if that makes sense