4 ms·

AOP creates 'hidden coupling', something I found extremely common while working in java. The logic seems to be that loose coupling is better than tight coupli

AOP creates 'hidden coupling', something I found extremely common while working in java. The logic seems to be that loose coupling is better than tight coupling, and what's looser than zero coupling? It's perfect! The trouble is that zero coupling is not really possible in a working system. Instead what you've done is introduce 'hidden coupling', where one can't see the connections between components in the system from the code. Hidden coupling makes understanding and maintaining a software system much harder than it would be otherwise.

IggleSniggle 3y ago
This is such a fantastic way to put this! Coupling is extremely important: if these two things GO together, why not make that as clear as possible? The reason we avoid tight coupling is so that our software can remain “soft.” We can continue to mould and manipulate it even as out requirements or understandings change. But software with hidden coupling might as well be the Internet. Sure, Google might crawl Wikipedia, and it provides some information as a result, and your software might rely on the result of some query. But then when your query breaks do you need to make a change to Wikipedia? That’s probably a pretty bad analogy, but it’s the way I routinely felt when I was a junior working in a “hidden coupling” software system where even knowing what queries were being made was a challenge.
oh_sigh 3y ago
It's hidden from the perspective of code represented as individual byte stream files, but that doesn't need to be the only representation, though obviously it is the most common form. Or, your IDE could surface this information.
- gorjusborg 3y ago
  > It's hidden from the perspective of code represented as individual byte stream files, but that doesn't need to be the only representation This is unarguably true. However, it seems that the tooling often doesn't offer that support, or it isn't broadly known that it does. You are also marrying the tool as well as the language at that point, which might be deemed acceptable by some, but probably not all (I am not a fan of Lombok for similar reasons to why I would not be a fan of this). To me, you are better off with simpler abstractions and practices than amping up the base requirements of your developers and tooling.

IggleSniggle 3y ago

This is such a fantastic way to put this! Coupling is extremely important: if these two things GO together, why not make that as clear as possible? The reason we avoid tight coupling is so that our software can remain “soft.” We can continue to mould and manipulate it even as out requirements or understandings change. But software with hidden coupling might as well be the Internet. Sure, Google might crawl Wikipedia, and it provides some information as a result, and your software might rely on the result of some query. But then when your query breaks do you need to make a change to Wikipedia? That’s probably a pretty bad analogy, but it’s the way I routinely felt when I was a junior working in a “hidden coupling” software system where even knowing what queries were being made was a challenge.

oh_sigh 3y ago

It's hidden from the perspective of code represented as individual byte stream files, but that doesn't need to be the only representation, though obviously it is the most common form. Or, your IDE could surface this information.

gorjusborg 3y ago
> It's hidden from the perspective of code represented as individual byte stream files, but that doesn't need to be the only representation This is unarguably true. However, it seems that the tooling often doesn't offer that support, or it isn't broadly known that it does. You are also marrying the tool as well as the language at that point, which might be deemed acceptable by some, but probably not all (I am not a fan of Lombok for similar reasons to why I would not be a fan of this). To me, you are better off with simpler abstractions and practices than amping up the base requirements of your developers and tooling.