• @Solemarc@lemmy.world
    8•4 months ago

    Same, I always remember this with interfaces and inheritance, shoehorned in BS where I’m only using 1 class anyway and talking to 1 other class what’s the point of this?

    After I graduated as a personal project i made a wiki for a game and I was reusing a lot of code, “huh a parent class would be nice here”.

    In my first Job, I don’t know who’s going to use this thing I’m building but these are the rules: proceeds to implement an interface.

    When I have to teach these concepts to juniors now, this is how I teach them: inheritance to avoid code duplication, interfaces to tell other people what they need to implement in order to use your stuff.

    I wonder why I wasn’t taught it that way. I remember looking at my projects that used this stuff thinking it was just messy rubbish. More importantly, I graduated not understanding this stuff…

    • @Kache@lemm.ee
      3•4 months ago

      inheritance to avoid code duplication

      What no, inheritance is not for code sharing

      Sound bite aside, inheritance is a higher level concept. That it “shares code” is one of several effects.

      The simple, plain, decoupled way to share code is the humble function call, i.e. static method in certain langs.

      • ladEnglish
        1•4 months ago

        I mostly come to prefer composition, this approach apparently even has a wiki page. But that’s in part because I use Rust that forbids inheritance, and don’t have such bullshit (from delegation wiki page):

        class A {
    void foo() {
        // "this" also known under the names "current", "me" and "self" in other languages
        this.bar();
    }

    void bar() {
        print("a.bar");
    }
}

class B {
    private delegate A a; // delegation link

    public B(A a) {
        this.a = a;
    }

    void foo() {
        a.foo(); // call foo() on the a-instance
    }

    void bar() {
        print("b.bar");
    }
}

a = new A();
b = new B(a); // establish delegation between two objects

        Calling b.foo() will result in b.bar being printed, since this refers to the original receiver object, b, within the context of a. The resulting ambiguity of this is referred to as object schizophrenia

        Translating the implicit this into an explicit parameter, the call (in B, with a a delegate) a.foo() translates to A.foo(b), using the type of a for method resolution, but the delegating object b for the this argument.

        Why would one substitute b as this when called from b.a is beyond me, seriously.