Incase it doesn’t show up:

  • magic_lobster_party@fedia.io
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    2 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
      ·
      2 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
        ·
        2 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.