fix: rename getAssiciatedResource to getSecondaryResource

[csviri]

getResource is either called on event source or dependent resource. In both context it should be obivius from getResource that it is about the resource dependent resource / or event source is managing / caching.

[metacosm]

I think that getAssociatedResource or maybe even getAssociatedWith is more explicit because if you look at code like https://github.com/java-operator-sdk/java-operator-sdk/pull/1100/files#diff-4a699996771e27e06c424cfbd90ae19efb23d49ff489240c9e5a6375180a3ec9R31 it's easy to get confused about what you're trying to retrieve. Ideally, there wouldn't be any possible confusion and the method name should make that explicit so that you don't need to look at the object on which the method is called to figure out the intent of the method.

[csviri]

This will be the primary API that everybody will use if any, should be short, and it is pretty obvious I think mainly for DependentResource.getResource() that is about the dependent resource. Actually for me the associated was confusing. Mainly we don't use associated anywhere else in domain language, we use secondary usually. Even the mapping functions were renamed because of this.

The associated wording itself is not good imho.

Maybe with the event sources is not that straigforward, but we use the same interface (maybe we should not?, ResourceOwner is not really used anywhere explicitly)

[metacosm]

Associated is quite explicit, in my opinion: it's the resource associated with the one we specify as a parameter.

We could rename it something different but again, ideally, in a good API, one should not have to look at the type of an object to resolve any ambiguity on what a method does. getResource doesn't achieve that goal, in my opinion, because the resource that gets retrieved is not the one that is pointed to by the specified parameter. It doesn't need to be associated but some qualifier to make things more explicit would be better than just getResource.

[csviri]

Associated is quite explicit, in my opinion: it's the resource associated with the one we specify as a parameter.

We could rename it something different but again, ideally, in a good API, one should not have to look at the type of an object to resolve any ambiguity on what a method does. getResource doesn't achieve that goal, in my opinion, because the resource that gets retrieved is not the one that is pointed to by the specified parameter. It doesn't need to be associated but some qualifier to make things more explicit would be better than just getResource.

I would then name is as getSecondaryResource , this will match the current glossary, so we will have always:

• primary resource
• secondary resource
• dependent resource (feature )

So it will be then straightforward that we get secondary resource (ideally) either from event source or (if the feature is used) dependent resource.
What do you think?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

14.3% Coverage
0.0% Duplication

[metacosm]

Thank you!