Safer compile-time String.format() alternative iss

With String.format, there seems to be a large opening for programmatic error that isn't found at compile-time. This can make fixing errors more complex and / or take longer. This was the issue for me that I set out to fix (or hack a solution). I came close, but I am not close enough. For this problem, this is more certainly over-engineered. I understand that, but I just want to find a good compile-time solution to this.

More information can be found here. My question dealing with

Basic Program

2 calculators. 1 Logic backend. Could be expanded to include other simple calculators.

I wanted 1 class to deal with all the operations (listeners) for any such kind of simple calculator.

I decided to abstract the format string away with Enums due to this reasoning - https://stackoverflow.com/a/9850656/2333021. Every expression will have a set number of "divisions", and it will be in a more readable and reliable form.

OnClickListener

I have a listener that should only deal with performing the logic getting the numbers from the UI, executing the calculation, and setting the result to the UI. It should not know the format of the results. The solution should allow errors to be found by compile-time, not run-time.

Right now my implementation seems to meet some of those

    @Override
    public void onClick(View v) {

         // Get number 1 and number 2. Perform operation via Strategy Pattern

         {

            // ISSUE This seems to be fine if I only cared about THIS class only dealing with one expression, but I want it to handle both (not at the same time though)
            // These seem too coupled right now. I just have both Expression and 
            // DogeExpression here for now. But I do kind of like the the execution

            Expression.Number1.update(num1);  // Enum Expression
            Expression.Number2.update(num2);
            Expression.Operator.update(operator.getSign());
            Expression.Result.update(total);

            DogeExpression.Total.update(total);  // Enum DogoExpression

         }

         UI.setResult(Expression.Update.print());
         // UI.setResult(DogeExpression.Update.print()); // Switch to this for DogeExpression

    }

Issue

With OperationClick, the is only an issue, I think, due to how I set up the project. I wanted to have multiple UIs, that look, have slightly different controls, and act a little different...

MainActivity : displays enum Expression String
MainActivityDoge : displays enum DogeExpression String
MainActivity_X : displays enum X_Expression String for example...each UI has the same buttons, and each connected to OperationClick

btnAdd.setOnClickListener(new OperationClick(Add).listenerOn(this)); btnSub.setOnClickListener(new OperationClick(Subtract).listenerOn(this)); btnMul.setOnClickListener(new OperationClick(Multiply).listenerOn(this)); btnDiv.setOnClickListener(new OperationClick(Divide).listenerOn(this));

My OperationClick class has my onClick(View v) code, and I don't wnat to have duplicates. I abstracted the math logic out using the Strategy pattern. This class should only be concerned about how to do the math operations. It should not care about the way it will be displayed on the UI, but it needs to assign/update the expression.