Incase it doesn’t show up:

  • magic_lobster_party@fedia.io
    link
    fedilink
    arrow-up
    4
    arrow-down
    4
    ·
    4 months ago

    So things like abstract classes are mostly absent from my codebase.

    I believe the consensus nowadays is that abstract classes should be avoided like the plague even in languages like Java and C#.

    • void_star@lemmy.world
      link
      fedilink
      arrow-up
      13
      ·
      4 months ago

      I have not heard this consensus. Definitely inheritance where the base class holds data or multiple inheritance, but I thought abstract was still ok. Why is it bad?

      • magic_lobster_party@fedia.io
        link
        fedilink
        arrow-up
        7
        arrow-down
        1
        ·
        4 months ago

        In 99% of the cases, inheritance can easily be replaced with composition and/or interfaces. Abstract classes tend to cause hard dependencies that are tough to work with.

        I’m not sure why you would use abstract classes without data. Just use interfaces.

          • magic_lobster_party@fedia.io
            link
            fedilink
            arrow-up
            3
            ·
            4 months ago

            Ask Bjarne to add interfaces enough many times until he gives in.

            On a more serious note, I’m not exactly sure what the best C++ practice is. I guess you just have to live with abstract classes if you really want interfaces.

              • magic_lobster_party@fedia.io
                link
                fedilink
                arrow-up
                2
                ·
                4 months ago

                The only problem is to ensure the entire team agrees to only use it like an interface and nothing else. But I guess that’s the only proper way to do it in C++, for now.

                • SpaceNoodle@lemmy.world
                  link
                  fedilink
                  arrow-up
                  3
                  ·
                  4 months ago

                  That’s not really the job of the language, though. If they can’t read the design docs and source annotations, they don’t really have any business touching anything.

                • affiliate@lemmy.world
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  4 months ago

                  this seems like the only proper way to do anything in C++. it’s a language where there’s 5 ways to do 1 thing and 1 way to do 5 things.

          • pelya@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            4 months ago

            I know at least three ways, one of them involves variadic macros.

            You don’t even need to look that far, take any sufficiently aged library, like OpenGL.

              • pelya@lemmy.world
                link
                fedilink
                arrow-up
                2
                ·
                4 months ago

                Yet I still had an urge to explain an obvious thing. Because it’s C++, so everyhing goes. There are even tools to auto-generate C++ interfaces, because of course someone decided that C++ is inadequate and must be improved using some kind of poorly-documented ad-hoc extension language on top of C++.

        • void_star@lemmy.world
          link
          fedilink
          arrow-up
          3
          ·
          4 months ago

          Perhaps we have a terminology mismatch, I tend to use abstract class and interface interchangeably. I’m not sure it’s possible to define a class interface in c++ without using inheritance, what kind of interface are you referring to that doesn’t use inheritance?

          • ugo@feddit.it
            link
            fedilink
            arrow-up
            3
            ·
            4 months ago

            You do have a terminology mismatch. In C++, an abstract class is a class with at least one pure virtual method.

            Such classes cannot be instantiated, so they are useful only as base classes.

            An interface is more of a concept than a thing.

            Sure you can say that Iterable is an interface that provides the Next() and Prev() methods and you can say that Array is an Iterable because it inherits from Iterable (and then you override those methods to do the correct thing), and that’s one way to implement an interface in C++.

            But you can also say that Iterable<T> is a class template that provides a Next() and Prev() methods that call the methods of the same name on the type that they wrap (CRTP aka static polymorphism).

            Or you can say that an algorithm that scans a collection T forward requires the collection to have a Next() method by calling Next() on it.

            And I can think of at least 2 other ways to define an interface that isn’t using abstract classes.

            And even if using abstract classes, inheriting from them is definitely the least flexible way to use them to define an interface, because it doesn’t allow one to do something like mocking functionality in tests, because it’s not possible to redefine the class to be tested to inherit from the test interface implementation with mocked functionality, so one still needs something to the effect of dependency injection anyway.

            So yeah, abstract class is very different from inheritance, and it’s also very different from interface, even though it relates to both.

            • void_star@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              4 months ago

              I agree, my terms aren’t perfect, but as you stated there isn’t really such a thing as an interface in c++, traditionally this is achieved via an abstract base class which is what I meant by using them interchangeably.

              I know there are many things you can do in c++ to enforce an interface, but tying this back to the original comment that inheritance is objectively bad, I don’t think there’s any consensus that this is true. Abstract base classes (with no data members) and CRTP are both common use cases of inheritance in modern C++ codebases and are generally considered good design patterns.

              • ugo@feddit.it
                link
                fedilink
                arrow-up
                3
                ·
                4 months ago

                Meh. Been developing professionally with C++ for 10 years at this point. I’m one of the weird people that kinda likes C++ and its pragmatism despite all its warts.

                I’d like C++ better if it didn’t have inheritance. There are better solutions to model interfaces, and without inheritance people can’t write class hierarchies that are 10 levels deep with a different set of virtual functions overridden (and new virtual functions added) at each level.

                And yes, that is not hypothetical. Real codebases in the real world shipping working products do that, and it’s about as nice as you can imagine.

          • jorp@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            4 months ago

            I don’t think it’s what the person you’re replying to meant, but template metaprogramming in modern c++ allows the use of “duck typing” aka “static polymorphism” where you can code against an interface without requiring inheritance.

            • void_star@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              4 months ago

              Typically this is done with CRTP which does require inheritance. But I agree, you can do some meta programming or use concepts which can enforce interfaces in a different way. But back to the original comment that interfaces via inheritance are objectively bad, I don’t think there’s any consensus that this is true. And pure virtual interfaces and CRTP are both common use cases of inheritance in modern C++ codebases and are generally considered good design patterns.

        • jaybone@lemmy.world
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          4 months ago

          Say List is an interface.

          You have implementations like ArrayList and LinkedList.

          Many of those method implementations will differ. But some will be identical. The identical ones go in the abstract base class, so you can share method implementation inheritance without duplicating code.

          That’s why.

          • magic_lobster_party@fedia.io
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            4 months ago

            If the lists have shared components then that can be solved with composition. It’s semantically the same as using abstract classes, but with the difference that this code dependency doesn’t need to be exposed to the outside. This makes the dependency more loosely coupled.

            • jaybone@lemmy.world
              link
              fedilink
              arrow-up
              1
              ·
              4 months ago

              In my example, how is the code dependency exposed to the outside? The caller only knows about the List interface in my example.

              • magic_lobster_party@fedia.io
                link
                fedilink
                arrow-up
                2
                arrow-down
                2
                ·
                4 months ago

                In your example, the declaration of ArrayList look like:

                public class ArrayList extends AbstractList implements List {
                }
                

                The dependence on AbstractList is public. Any public method in AbstractList is also accessible from the outside. It opens up for tricky dependencies that can be difficult to unravel.

                Compare it with my solution:

                public class ArrayList implements List {
                    private AbstractList = new AbstractList();
                }
                

                Nothing about the internals of ArrayList is exposed. You’re free to change the internals however you want. There’s no chance any outside code will depend on this implementation detail.

        • Zangoose@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          4 months ago

          The way I was taught was that you usually start off with only an interface and then implementing classes, and then once you have multiple similar implementations it could then make sense to move the common logic into an abstract class that doesn’t get exposed outside of the package

          • magic_lobster_party@fedia.io
            link
            fedilink
            arrow-up
            3
            arrow-down
            1
            ·
            4 months ago

            I usually break it out using composition if that’s ever needed. Either by wrapping around all the implementations, or as a separate component that is injected into each implementation.