4 ms·

I frequently find DI pattern to show up in Java... But I also frequently find that Java gives me all the handcuffs of systems languages with few of the benefits

I frequently find DI pattern to show up in Java... But I also frequently find that Java gives me all the handcuffs of systems languages with few of the benefits of more flexible duck-typing languages. If you can't monkey-patch the getDate function with a mock in a testing context because your language won't allow it, that's a language smell, not a pattern smell.

akoboldfrying 1y ago
> If you can't monkey-patch the getDate function with a mock in a testing context because your language won't allow it, that's a language smell, not a pattern smell. Not so fast. Constraints like "no monkeypatching allowed" are part of what make it possible to reason about code at an abstract level, i.e., without having to understand in detail every control path that could possibly have run before. Allowing monkeypatching at the language level means discarding that useful reasoning tool. I'm not saying that "no monkeypatching allowed" is always ideal, but it is a tradeoff. (Consider why so many languages have something like a "const" modifier, which purely restricts what you can do with the object in question. The restriction reduces what you can do with it, but increases what you know about it.)
- shadowgovt 1y ago
  In practice, we accomplish that by not monkeypatching the production code. But for unit testing? Go nuts.
  - akoboldfrying 1y ago
    Sure, a policy like that helps, but relying on programmer discipline like this only scales so far. In a large enough code base, if something can be done, someone will have done it somewhere. (If you have linter rules or static analysis that can detect monkeypatching and runs on every commit (or push to main, or whatever), you're good.)
arjvik 1y ago
You CAN in fact monkeypatch getDate - look at a Mockito add-on known as PowerMockito! While it's impossible to mock it out in the normal JVM "happy path," the JVM is powerful enough to let you mess with classloading and edit the bytecode at load-time to mock out even system classes. (Disclaimer: have not used PowerMockito in ages, am not confident it works with the new module system.)
surgical_fire 1y ago
> If you can't monkey-patch the getDate function with a mock in a testing context because your language won't allow it, that's a language smell, not a pattern smell. Of course you can do it in Java. But it is widely considered poor practice, for good reason, and is generally avoided.
- shadowgovt 1y ago
  Interesting. Why is it considered poor practice to monkey-patch getDate for testing purposes in Java?

akoboldfrying 1y ago

> If you can't monkey-patch the getDate function with a mock in a testing context because your language won't allow it, that's a language smell, not a pattern smell. Not so fast. Constraints like "no monkeypatching allowed" are part of what make it possible to reason about code at an abstract level, i.e., without having to understand in detail every control path that could possibly have run before. Allowing monkeypatching at the language level means discarding that useful reasoning tool. I'm not saying that "no monkeypatching allowed" is always ideal, but it is a tradeoff. (Consider why so many languages have something like a "const" modifier, which purely restricts what you can do with the object in question. The restriction reduces what you can do with it, but increases what you know about it.)

shadowgovt 1y ago
In practice, we accomplish that by not monkeypatching the production code. But for unit testing? Go nuts.
- akoboldfrying 1y ago
  Sure, a policy like that helps, but relying on programmer discipline like this only scales so far. In a large enough code base, if something can be done, someone will have done it somewhere. (If you have linter rules or static analysis that can detect monkeypatching and runs on every commit (or push to main, or whatever), you're good.)

arjvik 1y ago

You CAN in fact monkeypatch getDate - look at a Mockito add-on known as PowerMockito! While it's impossible to mock it out in the normal JVM "happy path," the JVM is powerful enough to let you mess with classloading and edit the bytecode at load-time to mock out even system classes. (Disclaimer: have not used PowerMockito in ages, am not confident it works with the new module system.)

surgical_fire 1y ago

> If you can't monkey-patch the getDate function with a mock in a testing context because your language won't allow it, that's a language smell, not a pattern smell. Of course you can do it in Java. But it is widely considered poor practice, for good reason, and is generally avoided.

shadowgovt 1y ago
Interesting. Why is it considered poor practice to monkey-patch getDate for testing purposes in Java?