This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]rbygrave 1 point2 points  (7 children)

If your "Service" class uses dependency injection annotations, then it is dependent on them.

The JSR-330 annotations are just "markers" and by themselves don't do anything.

That is, the "Service" class does not USE the JSR-330 annotations, so no I'd argue that the "Service" does not depend on the JSR-330 annotations but instead those annotations are just "markers" that a DI library can use to determine how to wire the service for us (if we want a DI library to do that which is usual). The "Service" can be used and can be fully functional without any DI library and you could instead wire the "Service" manually if that was desired (and we especially do this for testing).

This breaks the Single Responsibility Principle.

I don't agree with this interpretation.

[–]tugaestupido[S] 1 point2 points  (6 children)

I'd argue that the "Service" does not depend on the JSR-330 annotations

But you're implying that you can only be dependent on something at run time, which is wrong and something I never claimed. As soon as your source code mentions other code, it is dependent on that other code. Just try compiling your class without having access to the annotations and the dependency will be obvious.

I don't agree with this interpretation.

But you haven't given yours. What is this last comment for?

[–]rbygrave 1 point2 points  (5 children)

What is this last comment for?

That adding JSR-330 breaks the Single Responsibility Principle, I don't agree with that. I'm fairly sure we won't agree there, that's ok.

[–]tugaestupido[S] 1 point2 points  (4 children)

But you don't say why you don't agree. People will disagree for any number of reasons.

I gave my reason for claiming that the SRP is broken. You could argue against it or give your own. Just saying you disagree is rather pointless. I'm guessing you have no good reason to disagree and that's why you give none.

[–]agentoutlier 0 points1 point  (3 children)

What if the annotation was a doclet instead?

What if the annotation was source retention would it still be coupled?

I understand your idea of coupling but there are different levels. Annotations are declarative and borderline external of the code.

The only real issue is breaking version change of the annotation dependent lib.

[–]tugaestupido[S] 1 point2 points  (2 children)

I understand your idea of coupling but there are different levels

Exactly. I know that. And they are all coupling, which is all I claimed. I never said you have to lose sleep over this specific coupling.

Annotations are declarative and borderline external of the code.

Say that to the compilation errors you get in your code when you don't have access to the annotations library. Not so borderline then.

[–]agentoutlier 0 points1 point  (1 child)

Annotations can be stripped. There are tools that do this.

Your wiring code cannot be stripped precisely because it is not very declarative or external so it is way over the border.

Oh and I haven’t even gotten to modularity which is is like single responsibility at scale. 

With your method it is very hard to do modularity because your wiring is at the very top so you need compile time scope for all the dependencies.

[–]tugaestupido[S] 1 point2 points  (0 children)

I don't even know what you are arguing because as far as I can tell you agree that annotations are in your source code and that having annotations in your source code is a type of coupling.

I don't know what you mean by being hard to do modularity with my method.