• 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.

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

                  It’s not valid Java for e.g. Lists, Maps, Strings or any programmer-defined classes.

                  Same with operator overloading.

                  myVectorA + myVectorB is not valid Java, but it is valid OOP in e.g. Python or C++. And this kind of syntactic sugar reduces verbosity enourmously, while still being OOP.

                  If you have ever worked in e.g. Python, Groovie or Kotlin you notice quickly how non-verbose OOP can be.

                  It seriously is just Java.

                  And Javas insistance on having you wrap non-OOP things in fake OOP constructs (e.g. static methods, which are just functions in modules, but you have to uselessly abuse classes as modules) isn’t helping either.

    • 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.