Question

I have this SaveCheckedStateToDB() function:

public class oDaA_DBUtils {

    // TOOD: Perhaps this should not be static, and I should force callers to instantiate the class first?
    public static void SaveCheckedStateToDB(int AOptionSelected, String id, boolean AToggledOn)
    {
      //
    }
}

…that I changed to “static” after getting static about calling it from here prior to adding the “static” keyword:

            cbOnDemand.setOnCheckedChangeListener(new OnCheckedChangeListener()
            {
            @Override 
                public void onCheckedChanged(CompoundButton buttonView, boolean isChecked)
                {
                // Contact id is a string?
                oDaA_DBUtils.SaveCheckedStateToDB(oDaA_Consts.ALERT_ON_DEMAND, id, isChecked);
                }
            });

Now it compiles, but is that a “wrong” way of working? Should I remove the “static” appendage/decoration and force callers to instantiate the class prior to calling SaveCheckedStateToDB()?

Answer 1

There is no reason to un-static it. This method does not need any of the “state” of its class, as it’s obviously a utility class, so it should be static.

If it’s indeed a utility class, you should enforce it by forbidding instantiation: make the default constructor private:

private oDaA_DBUtils {
    // no instances allowed!
}

Also, it’s good practice to follow the Java naming standards: capitalized camelcase for class names, and uncapitalized camelcase for methods. This will help you in the long run to see what you’re doing at first glance when looking at your code.

public class OdaaDbUtils
public static void saveCheckedStateToDb(....)