Add NamingService with Java implementation

[Laurens-W]

What's changed?

Added a NamingService interface including a Java implementation

What's your motivation?

Working on

• Adjust MethodNameCasing to work with C#  rewrite-static-analysis#397

Anything in particular you'd like reviewers to focus on?

Anyone you would like to review specifically?

@knutwannheden @OlegDokuka @timtebeek

Checklist

• I've added unit tests to cover both positive and negative cases
• I've read and applied the recipe conventions and best practices
• I've used the IntelliJ IDEA auto-formatter on affected files

[timtebeek]

I figured explore what usage would look like through a test, and figured point out a few things that might influence the design:

Usage in visitor

Here's the bare bones visitor I came up with; mostly call the service to potentially get a new name (no guarantees it's actually different), and then delegate the actual work. API seems to mostly work, provided with expect folks to delegate the work of actually renaming, as otherwise you end up having the change the name.simpleName & name.type & methodType, which gets awkward.

@Override
public void defaults(RecipeSpec spec) {
    spec.recipe(toRecipe(() -> new JavaIsoVisitor<>() {
        @Override
        public J.MethodDeclaration visitMethodDeclaration(J.MethodDeclaration method, ExecutionContext ctx) {
            J.MethodDeclaration md = super.visitMethodDeclaration(method, ctx);
            String oldName = md.getName().getSimpleName();
            String newName = service(NamingService.class).standardizeMethodName(oldName);
            if (!oldName.equals(newName)) {
                doAfterVisit(new ChangeMethodName(MethodMatcher.methodPattern(md), newName, true, false).getVisitor());
            }
            return md;
        }
    }));
}

Cases I'd expect to change

Here's a couple quick examples that I'd then expect to be renamed predictably; we can argue what their new names should be, but it's perhaps to capture that in tests for any changes we might make.

@ParameterizedTest
@CsvSource(textBlock = """
  foo_bar,fooBar
  foo$bar,fooBar
  foo_bar$,fooBar
  foo$bar$,fooBar
  """)
void changeMethodName(String before, String after) {
    String template = """
      class A {
          void %1$s() {}
      }
      class B extends A {
          @Override
          void %1$s() {}
      }
      class C {
          void use() {
              new A().%1$s();
              new B().%1$s();
          }
      }
      """;
    rewriteRun(
      java(
        template.formatted(before),
        template.formatted(after)
      )
    );
}

In reality only the first is actually changes as expected, with some odd choices of changes for the others

I think it would be good to include a test like the above to capture the expected behaviour, and guard against downstream test failures if there's any updates.

[Laurens-W]

@timtebeek I guess the initial logic of the MethodNameCasing recipe didn't take this into account but I agree that if we want to provide this NamingService generically it should be able to handle these things, I'll work on adding the test you proposed!

edit: It tried to take it into account but not properly

[timtebeek]

Looks good! Thanks for adding this and the proposed fixes as well.