• moosh@lemmy.world
    link
    fedilink
    arrow-up
    12
    ·
    1 year ago

    Is this a good thing I’m looking at or a bad thing? I don’t get it but then again, I’m not a programmer.

    • Eugene@waveform.social
      link
      fedilink
      arrow-up
      30
      ·
      1 year ago

      Java is a programming language that is notorious for being verbose, the joke is that you need a massively wide monitor to view it without the text being cut off

      • Distributed
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 year ago

        I don’t understand why people don’t break stuff like this up with newlines

        • TaldenNZ@lemmy.nz
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          We would. And we’d tend not to be using such verbose variable names. Avoiding abbreviation in the method and type-names is idiomatic though.

    • 1stTime4MeInMCU@mander.xyz
      link
      fedilink
      arrow-up
      14
      ·
      1 year ago

      The joke is Java is verbose. It takes many characters to accomplish simple routines. Depending on your view that could either be good or bad for reading the code later.

      • Anomandaris@kbin.social
        link
        fedilink
        arrow-up
        17
        arrow-down
        1
        ·
        edit-2
        1 year ago

        Sure, but most of the lines in the screenshot break down to:

        object1.setA(object2.getX().getY().getZ().getI().getJ().getK().getE().getF(i).getG().toString())

        Aside from creating a method inside the class (which you should probably do here in Java too) how would another language do this in a cleaner way?

        • bleistift2@feddit.de
          link
          fedilink
          English
          arrow-up
          9
          arrow-down
          1
          ·
          1 year ago

          You shouldn’t reach through an object to invoke a method. That tightly couples the classes which getJ and getG (for instance) return.

          • Anomandaris@kbin.social
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            That is an interesting point, but it’s not Java specific, you could do this exact thing in most other languages and it would look pretty much the same.

            Considering the fact that in a lot of enterprise projects the data structures are not necessarily open to change, how would you prevent reaching through objects like this?

            • 1stTime4MeInMCU@mander.xyz
              link
              fedilink
              arrow-up
              2
              ·
              1 year ago

              This is why I wasn’t too critical of Java. Java is verbose by convention and other languages are more terse by convention. You could just as easily write some nasty ‘snake_cased_object_abstract_factory_adapter_facade_broker_manager’ in python or any other language. There are a few things syntax wise working against it but you can still write (overly) terse Java and it’s just as annoying to read as in any other language. IMO it’s convention and style not the language itself. You can also say some mean things about languages with less verbosity but more operators and keywords like C++/rust. It’s a funny meme tho lol anyone who has worked in Java knows there’s at least a bit of truth to it

            • bleistift2@feddit.de
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              I’ll shrink your example. Suppose you have an object A which has a B which has a C, which is what you need.

              By writing a.getB().getC(), you are implicitly coupling A and C together without A noticing. All A knows is that it is coupled to B. Should B ever decide to use a different C’, which would make more sense for B, it may break your code without noticing it.

              The solution is to make the coupling explicit. A should define a getC function that observes the needed contract. For the time being, it may get its C from B (which is fine, because C is under B’s immediate control), but if B changes, and wants to use C’, you know to look into A (which is already explicitly coupled to B) and see if it can still function. You’d notice that it relied on B’s returning C and can find a solution to this.

              An example with fewer variables: You have a shopping cart, which manages items. Implicit coupling translates to knowing and relying on the fact that the items are stored in an array. Adding an item the bad way would be shoppingCart.getItems()[shoppingCart.getItems().getLength] = item;*

              The proposed solution adds the function ShoppingCart::addItem. Should ShoppingCart switch to a linked list, it can change the implementation of addItem accordingly. Instead of reaching through the cart into the items, you make dealing with the items the problem of ShoppingCart.

              I don’t have copy at hand, so I can’t check. I think this advice stems from “The Pragmatic Programmer” by David Thomas and Andrew Hunt.

              * I don’t actually know Java, so please forgive if this example wouldn’t really work.

          • Aceticon@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            1 year ago

            It’s sad that it took getting so far down the thread before somebody pointed out the obvious program design flaw.

            If you’re digging many levels down into your datamodel from high up for lots of datapieces, it’s probably the case that both the data is unnecessarily framented and the code design itself doesn’t have proper OO isolation of responsabilities.

            If you’re designing for performance (a well know raeson to screw OO design), then the datamodel itself would be a lot flatter (because you get more performance on the DB by trading it for space), whilst if you’re not then you break the thing into parts as you have functions were you fetch intermediate objects into memory and handle the data in them (a Visitor Pattern would probably make this a lot cleaner).

            I bet whomever designed the datamodel isn’t the same as those doing the coding.

            • bleistift2@feddit.de
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              To be fair, probably hardly anyone actually looked at the code. And now that I did, I think this is compiled, not source code.

        • Blackthorn@programming.dev
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          1 year ago

          Well I guess the point is that you shouldn’t need all these method calls to achieve simple goals. Most of those “getF” are calls to some SystemFactory to get a GenericObjectFactory and so on and so forth.

          • Anomandaris@kbin.social
            link
            fedilink
            arrow-up
            4
            arrow-down
            1
            ·
            1 year ago

            This just tells me you don’t use Java. Factory classes are just used to create objects in a standardized way, but this code isn’t creating anything, it’s just getting nested fields from already instantiated objects.

            • Square Singer@feddit.de
              link
              fedilink
              arrow-up
              5
              arrow-down
              1
              ·
              1 year ago

              Thos code is obviously nonsense to show the issue.

              But other languages would simplify stuff. For example, some languages call getters implicitly, so .getField() becomes .field. Same with list indexing, which could be done with operator overloading, so x.get(i) becomes x[i].

              In this situation that would be able to reduce the character count a fair bit.

              • Anomandaris@kbin.social
                link
                fedilink
                arrow-up
                2
                ·
                1 year ago

                But that’s functionally no different than what’s already there…

                The reason the lines are so long isn’t because of anything Java related, it’s because of the field names themselves.

              • biddy@feddit.nl
                link
                fedilink
                arrow-up
                2
                ·
                1 year ago

                The new convention in modern Java is to use .field() instead of .getField().

                What you’re complaining about isn’t Java, it’s object oriented programming, which Java basically forces on you. Verbosity is a flaw of OOP.

                • Square Singer@feddit.de
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  1 year ago

                  Compare:

                  x.field[5]

                  with

                  x.getField().get(5)

                  Both are exactly the same level of OOP, but the Java version is roughly twice as long. Add operator overloading to the mix and it becomes much worse:

                  x.getField().get(5).multiply(6).add(3)

                  vs

                  x.field[5] * 6 + 3

                  All this has nothing to do with OOP, but with syntactic sugar that is applied.

                  • biddy@feddit.nl
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    1 year ago

                    As I said, the convention is now x.field() not x.getField()

                    What language are you comparing against here? x.field[5] is valid Java if field is a public array, but that’s not OOP, at least not in a pure sense.

        • fredthedeadhead@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          1 year ago

          Kotlin would represent the getter/setters as synthetic properties (and do so automatically, since Kotlin interops with Java).

          object1.A = object2.X.Y.Z.I.J.K.E.getF(i).G.toString()
          

          Of course it’s still not great (there’s still too much nesting, there’s something fundamentally wrong with how the data is structured) but at least the code is less noisy.