5 ms·

For languages that support monkey patching you don't dependency injection. A lot of the design patterns I used to adore and look at as if they were rare gems i

For languages that support monkey patching you don't dependency injection. A lot of the design patterns I used to adore and look at as if they were rare gems in a sea of bad code. Over time my opinions have changed. Many patterns are good, but I don't really like to think of those as patterns. A pattern implies repetition. Something that you can used each time you have a situation that warrents it. In my opinion, this openly contradicts "Don't repeat yourself". So I think we should start trading design patterns for simple and well designed languages. No code always beats good code.

bunderbunder 8y ago
> For languages that support monkey patching you don't dependency injection. What am I missing here? We've got to be working with different definitions of the term "dependency injection" or something. Using monkey patching as a complete replacement for dependency injection seems absolutely bonkers to me. The codebase I'm imagining when I here that is one where no module's run-time behavior can be understood by simply reading its source code, because every single one of its run-time dependencies is being monkey patched in from some where else entirely. It's also one where, to take the same class and instantiate two different copies with two different sets of run-time dependencies, I'd have to do something wacky with the monkey patching instead of just creating them with different constructor arguments.
- kyleperik 8y ago
  I know what you're talking about, I realize that's how most people think of as monkey patching. That's what I thought at first. But when I tried structuring a python project with Dependency Injection it seemed overly complex. Instead of just making modules I had to put everything in a class. I had to write code to decide what things are being injected where. It didn't look like python anymore, so I stopped doing it, and I've never had problems, and I've written much less code. I only ever use monkey patching for testing. People talk about how it makes it easier to switch out other implementations, but in reality it's easier. You just import a different module.
zeveb 8y ago
> So I think we should start trading design patterns for simple and well designed languages. No code always beats good code. The problem is that a simple language will lack an implementation of hitherto-unknown patterns. That's why it's so important to use a language which permits itself to be evolved & improved — and that's why Peter Norvig noted that design patterns tend not to be needed in dynamic languages[0]. 0: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/
- kyleperik 8y ago
  Yes I agree. I'd even say that functional programming languages, even if they're staticly typed, don't need design patterns either. I just think this long overhyped Object Oriented style was the wrong way to go for programming.

bunderbunder 8y ago

> For languages that support monkey patching you don't dependency injection. What am I missing here? We've got to be working with different definitions of the term "dependency injection" or something. Using monkey patching as a complete replacement for dependency injection seems absolutely bonkers to me. The codebase I'm imagining when I here that is one where no module's run-time behavior can be understood by simply reading its source code, because every single one of its run-time dependencies is being monkey patched in from some where else entirely. It's also one where, to take the same class and instantiate two different copies with two different sets of run-time dependencies, I'd have to do something wacky with the monkey patching instead of just creating them with different constructor arguments.

kyleperik 8y ago
I know what you're talking about, I realize that's how most people think of as monkey patching. That's what I thought at first. But when I tried structuring a python project with Dependency Injection it seemed overly complex. Instead of just making modules I had to put everything in a class. I had to write code to decide what things are being injected where. It didn't look like python anymore, so I stopped doing it, and I've never had problems, and I've written much less code. I only ever use monkey patching for testing. People talk about how it makes it easier to switch out other implementations, but in reality it's easier. You just import a different module.

zeveb 8y ago

> So I think we should start trading design patterns for simple and well designed languages. No code always beats good code. The problem is that a simple language will lack an implementation of hitherto-unknown patterns. That's why it's so important to use a language which permits itself to be evolved & improved — and that's why Peter Norvig noted that design patterns tend not to be needed in dynamic languages[0]. 0: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/

kyleperik 8y ago
Yes I agree. I'd even say that functional programming languages, even if they're staticly typed, don't need design patterns either. I just think this long overhyped Object Oriented style was the wrong way to go for programming.