• Solemarc@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    10 hours ago

    You’re not wrong but I think when you’re teaching someone just having 1 parent and 1 child class makes for a bad example I generally prefer to use something with a lot of different children.

    My go-to is exporters. We have the exporter interface, the generic exporter, the accounting exporter and the payroll exporter, to explain it.

    At school, the only time I used inheritance was 1 parent (booking) and 1 child (luxury) this is a terrible example imo.

    • pfm@scribe.disroot.org
      link
      fedilink
      arrow-up
      1
      ·
      5 hours ago

      Maybe that example was made terrible because the author couldn’t think of a good ways to show how great this can be. I’m obviously a fan of SOLID, and OCP is exactly why I don’t worry if I have only one class at the beginning. Because I know eventually requirements would change and I’d end up with more classes.

      Some time ago I was asked by a less experienced coworker during a code review why I wrote a particularly complex piece of code instead just having a bunch of if statements. Eventually this piece got extended to do several other things, but because it was structured well, extending it was easy with minimum impact for the code-base. This is why design matters.

      Above claims are based on nearly 2 decades of writing software, 3/4 of it in big companies with very complex requirements.