• jjjalljs@ttrpg.network
        2·
        9 days ago
        
with patch("some_file.requests.get", side_effect=SomeException("oh no")):
  result = func_using_requests()

        Though not every language makes mocking as easy, and multiple responsibilities in a single function can quickly get messy.

        • Tamo240@programming.dev
          1·
          9 days ago

          Oh I’m fully aware that python lets you cheat dependency injection with patch, its one of the many things python teaches developers to do wrong, which leads them to be unable to use any other language.

          • jjjalljs@ttrpg.network
            1·
            9 days ago

            I vaguely remember Java also has mocking libraries, as does JavaScript. (Though JavaScript isn’t a language I’d hold up as the ideal.)

            • Tamo240@programming.dev
              0·
              9 days ago

              While my experience is mostly C++, I assume these mocking libraries are similar in allowing you to create a class that can report it’s own usage, and allow for arbitrary returns values and side effects, which is incredibly useful, especially in conjunction with dependency injection.

              What patch lets you do is directly overwrite the functionality of private member functions on the fly, which if Java/JavaScript can do I’d love to know, I thought this was a uniquely Pythonic magic.

              • [object Object]@lemmy.world
                1·
                9 days ago

                JS is also just as dynamic in this regard. Both JS and Python create and modify objects at runtime and use object fields instead of static definitions of methods or properties. It’s probably inherited from Smalltalk.

        • wpb@lemmy.world
          2·
          9 days ago

          Quickest way to get a test suite so tightly coupled to structure rather than behavior that even just looking at the tests wrong makes them fail. But technically you do get test coverage I guess. Goodhart’s law in action.

          • jjjalljs@ttrpg.network
            1·
            8 days ago

            It’s not really that different from like

            
my_get_mock = Mock(side_effect=Some exception("oh no"))
result = some_func(http_getter=my_get_mock)

            There’s many ways of writing bad code and tests, but mocks and patches aren’t always a bad tool. But sure, you can definitely fuck things up with them.

  • ChickenLadyLovesLife@lemmy.worldEnglish
    11·
    9 days ago

    I started working as a professional programmer in the mid-90s when three-tiered design was all the rage: a data access layer, a business logic layer, and a presentation layer. It seems that nobody actually knew what “business logic” was even supposed to be, because I kept inheriting projects where all the middle tier did was hand data objects from the data layer to the UI. In theory this prevented the UI from being fundamentally bound to the data access, but all three layers were always written in Visual Basic which got kicked to the curb in a few years anyway.

    • Buddahriffic@lemmy.world
      2·
      9 days ago

      Business logic would be transformations to the data. Like for a spreadsheet, the data layer would handle the reading/writing of files as well as the storage of each cell’s content. The business logic layer would handle evaluating each of the formulas in the cells, and the presentation layer draws it on the screen.

      I think the part where it gets confusing is that each of these layers are pretty tightly coupled. The end destination of the presentation layer might change, one might show it on a GUI, another might print it, and another might convert it to pdf or html, but each of those presentation layers needs to understand the data that it is presenting, so it’s tightly coupled to the data layer. Same with the businesses logic layer, though it’s tightly coupled on both the input and output sides. The design of the data layer constrains the possibilities of the other two, so it’s hard to draw a clear boundary between the layers because they all need to know how to walk the same data.

      My mental flow chart for this is more of a data layer in the middle instead of business logic, where business logic is to the side with arrows going both ways between it and data layer, then the presentation layer also accessing the data layer directly, which I suppose is a different permutation of what you described.

      Though another way to look at it does make sense. For a website, think of the database as the data layer, the server scripts as the business logic layer, and the client side scripts/html/css as the presentation layer. That one also follows the layered approach where the presentation layer is talking with the business logic layer.

      • BeardedGingerWonder@feddit.ukEnglish
        4·
        9 days ago

        It’s simpler than that, if you’re working on the data layer anything you don’t want to touch is business logic.

        If you’re working on business logic the bad stuff is data layer.

        Presentation layer just isn’t my problem.

    • bitjunkie@lemmy.world
      1·
      9 days ago

      My first tech job was writing test harnesses for DCOMs. Your post was a weird trip down memory lane.

  • WanderingThoughts@europe.pub
    4·
    10 days ago

    Just got out of a discussion with a supplier. We can do what we needed by connecting to the database. Instead we have to go through four layers of different tech to arrive at the same point in the database otherwise it’s not compliant. That the supplier needs to sell a license for those layers is purely coincidental.

    • expr@piefed.socialEnglish
      3·
      9 days ago

      Obviously don’t have the full context, but rarely is it ever advisable to give third parties direct access to a database. There are many reasons for this, like, for example, the fact that doing so makes schema migrations practically impossible.

  • addie@feddit.uk
    2·
    9 days ago

    Abstraction is not very compatible with concurrency, so as well as your your beautiful abstract API, you also need some ‘cut through the layers’ functions to return the underlying classes you need to synchronise on. Now you have a right mess that’s incredibly hard to understand, infuriating to debug, and impossible to refactor. Best you can do is put another layer of abstraction on top. Repeat every six months.

    • 3abas@lemmy.world
      1·
      9 days ago

      That’s just bad interface… When you design an API as if operations were independent, but they aren’t, you run into these issues.

      Don’t add “cut through the lawyers” functions, fix your interface.

      • Buddahriffic@lemmy.world
        0·
        9 days ago

        Yeah, well-designed abstraction can help enable more concurrency. That said, concurrency isn’t easy at any point once there’s shared data that needs to be written to during the process. Maybe it’s not so bad if your language has good concurrency support (like monitor classes and such that handle most of the locking behind the scenes), but even then, there’s subtle pitfalls that can add rare bugs or crashes to your program.

    • Evotech@lemmy.world
      1·
      9 days ago

      That’s why you build the api first. If you need to “cut through” anything you build an api for that instead.

    • iegod@lemmy.zip
      1·
      9 days ago

      I’ve been around long enough to question this kind of advice. It depends, in so many ways, on the goals, strategies, and platforms.

  • db2@lemmy.world
    1·
    9 days ago

    They look so painfully awkward, like a parent should be telling them to knock it off or something.

    • Bosht@lemmy.worldEnglish
      1·
      9 days ago

      If you haven’t seen the vid it’s 500 levels of awkward cringe that’s hard to watch. Had to do with one of the MS version releases. They’re acting so awkward you can’t tell if they’re yakked out in coke or just that socially awkward. Full disclosure I’d be worse than them in that situation, just calling it like it is.

  • Randelung@lemmy.world
    0·
    9 days ago

    I recently started a new job. We use Java. There’s a class that does a few things based on explicit arguments only to decide whether to use an FTP or file output, and you supply all parameters yourself. A whole ass Rube Goldberg machine that could be replaced by a single line of Files.writeString.

    Also, there’s a great video on YT “Stop writing classes” that is incredibly relevant.

    • Buddahriffic@lemmy.world
      1·
      9 days ago

      Yeah, Java’s enforcement of everything must be a class put me off of the language right from the start. I was already used to C++ at that point and hated that I couldn’t just write a quick little test function to check something, it needed a bunch of boilerplate to even get started.

      I still think C++ has a great balance between object oriented and sequential programming. Not sure if it’s the best, but I can’t think of ways to improve on it, other than built in concurrency object stuff (like monitor classes that have built in locks that prevent more than one thread from accessing any of its functions at the same time, basically guaranteeing any code in it has mutual exclusion).

    • Windex007@lemmy.world
      0·
      9 days ago

      This hits.

      I stepped into a similar implementation. Took like 6 months and 10 people to support…

      … changing the URL of the sftp server we connected to.

  • BarneyPiccolo@lemmy.today
    7·
    8 days ago

    I used to work those corporate jobs, where I’d have to go to these boring conferences, and executives would come out and dance around and do a little comedy show, just to prove that they were just as normal as all the wage slaves, and we were supposed to get all excited and clap and shit. Fuck those losers (the execs, not the workers).