How to prevent predicate, condition naming collisions?

[weilbith]

Hey 👋

First of all, I love ArchUnit. I haven't known it for too long and I'm super motivitated now. Thank you. 🙏

Currently I'm writing a bunch oft custom predicates and conditions. But my problem is the naming. Often times there is a predicate that I also need as condition. So far no issue. But then I end up with naming problems.

In the beginning I though I could always differ predicate and condition with natural language. Like this (stupid) example: classes().that(areFromTheDomainPackage).should(beInsideTheDomainPackage). The latter condition is based on the earlier predicate with ArchCondition.from(areFromTheDomainPackage).

But that approach seems to fall short sooner or later. Rather soon. An approach would be to accumulate predicates and conditions in static classes, kinda similar to how it is done in the library. But I think this hurts the readability a lot. While the top example (as useless it is) reads pretty neatless as sentence, this does not: classes().that(MyPredicates.haveAMethodWithName("foo")).should(MyConditions.haveAMethodWithName("foo")).

Sure, as long as a test class doesn't need both, predidate and condition, I can important them directly (don't even need the static accumulation class). But again, that does fall short quickly.

So I was reading your code base a lot. And while you sometimes have different names for predicate and condition and also use some static classes, the key difference is your usage of ClassesThat and ClassesShould (plus more) that allow a nice chaining of "operators". This way is is possible to do the above example like classes().that().haveAMethodWithName("foo").should().haveAMethodWithName("foo"). Same name for predicts and condition, no naming collision.
But the only way I see this is possible would be by extending the classes ClassesThat and ClassesShould and then override GivenClasses to use those. And probably also ArchRuleDefinition. Not sure if that list is complete.

Anyway, there seem to be no easy way to follow the above approch without extend a bunch of classes and replace the usage of library classes with the own ones. At least I don't see it. Also not with the concept of plugins and extensions.
So my question is simply if there is a better way to do it. Another alternative, a best practice, ...

Thank you very much for any input and help! 🙂

[nbrugger-tgm]

Not a complete solution but there are "grammar wrappers" (methods that do nothing except adding a verb to the description)

methods.that(are(locatedInPackageA))
            .should(be(locatedInPackageA))

Thats what I do for my personal predicate collection, since you have context agnostic predicate names that can be used with the regarding verbs.

The common verbs are covered by arch unit itself if I recall it correctly : "is", "are", "be", "not"

[weilbith]

Thanks for your reply! 🙏

Yes, I discovered these functions too. It is now sometimes weird to just have this base name for the predicate/condition definitions, but does already help.

Anyway, for cases where I would intuitively use have, I fail to find a different naming so I could use any of these functions to differ between that(...) and should(...). Maybe I need to become mor creative with the English language. I just feel like any replacement for have always fits for that and should interchangeably.

[weilbith]

Taking my predicate haveAMethodWithName that acts on JavaClasss and takes a methodName: String parameter. Recommendations how to rename it so afterwards I can use any of is, are, ... to make it differentiable for that and should?

• aMethodWithName reads horrible on its own, but also what to prefix it with?
• includesAMethodWithName same as have
• definesAMethodWithName same as have
• out of ideas ... 🙈

[nbrugger-tgm]

First of all I plan on contributing this mentioned predicates to the fluent DSL of Arch unit so that you can do
classes().thatDefineMethodsThat().haveName("abc") and so on, but if you manage to contribute such a thing before me go ahead i don't have too much time.

But since this is a longer term operation, because you need to wait for the PR to be reviewed, accepted, merged and then the next release, here is what i do in the meantime:
well in this case i would still opt to not use the verb have in the variable name and do the following instead

methods.that(ArchPredicates.have(noMethods))
                .should(ArchConditions.have(noMethods))

where noMethods is a Predicate.

But this isn't specifically better in terms of amount of chars than using ArchCondition.from(haveNoMethods) but arguably more readable.

Also in regard to creating a predicate as you suggest named haveAMethodWithName is probably very unmodular i would opt for this instead:

classes().that(define(methodsThat(haveName("xyz")))
    .should(implement(methodsThat(haveName("xyz")))

Where you need to define + implement

ArchPredicate<JavaClass> define(ArchPredicate<? super JavaMember> membersThat);
ArchCondition<JavaClass> implement(ArchPredicate<? super JavaMethod> methodsThat);
ArchPredicate<JavaMember> methodsThat(ArchPredicate<? super JavaMethod> methodPredicate);

haveName is defined by ArchUnit. This enables you to use methodsThat with any configuration you like for example

classes().that(define(methodsThat(areStatic())) ....

PS: haveMethods is generally very unspeciffic since it isn't very clear how it interacts with hierarchies, eg is it satisfied if the method comes from a parent, if yes how to restrict it. Is a private member of a parent my member? ... words like definesMethod, inheritsMethod, implementsMethod and haveMethods (which is a or of the first 2) this could also help with avoiding name collisions

[weilbith]

Interesting. Thank you very much for sharing.
While this is quite nice for this specific example, it falls short for my of my other custom predicates/conditions. Those are "super" special and will never make to upstream, nor would I ever intend to.
But maybe this is some inspiration how to find better/more modular naming here. Still a little unsure.