Problems using screen display values-13 [C # refactoring sample]

Problems of using the displayed value on the screen

You may see code that embeds the display name in the logic, even though it has the original value. The problem with this code is that if the display changes, the logic must be modified. It is shown concretely in the sample code.

Sample code

In the sample code, if the division value (IsOk) is Yes, ○ is displayed on the screen. If there is a statement in the design document that the case of ○ is bold, the code to be created will be as follows. The classification value and its display value can be obtained from the screen.

        /**Category value**/
        private enum IsOk
        {
            Yes,
            No
        }

        public void Main()
        {
            //Implemented for NG screen display. If the display is no longer ○, correction is required.
            if (GetDisplay() == "○")
            {
                SetBold();
            }
        }

        private IsOk GetValue()
        {
            //Get the flag value set on the screen. It is a fixed value because it is a build.
            return IsOk.Yes;
        }

        private string GetDisplay()
        {
            //Get the display value for the flag set on the screen. It is a fixed value because it is a build.
            return "○";
        }

        private void SetBold()
        {
            //Make the letters bold. Code omitted.
        }

java

    /**Category value**/
    private enum IsOk {
        YES, NO,
    }

    public void main() {

        if (getDisplay() == "○") {
            setBold();
        }
    }

    private IsOk getValue() {
        //Get the flag value set on the screen. It is a fixed value because it is a build.
        return IsOk.YES;
    }

    private String getDisplay() {
        //Get the display value for the flag set on the screen. It is a fixed value because it is a build.
        return "○";
    }

    private void setBold() {
        //Make the letters bold. Code omitted.
    }

problem

In the case of the sample code, if the display is changed from ○ to ◎, it is necessary to correct the inside of the if statement. In order to separate from the display on the screen, the division value may be used.

After refactoring

        /**Category value**/
        private enum IsOk
        {
            Yes,
            No
        }

        public void Main()
        {
            //It works if Yes regardless of the OK display. It is not affected by the screen display.
            if (GetValue() == IsOk.Yes)
            {
                SetBold();
            }
        }

        private IsOk GetValue()
        {
            //Get the flag value set on the screen. It is a fixed value because it is a build.
            return IsOk.Yes;
        }

        private string GetDisplay()
        {
            //Get the display value for the flag set on the screen. It is a fixed value because it is a build.
            return "○";
        }

        private void SetBold()
        {
            //Make the letters bold. Code omitted.
        }

java

    /**Category value**/
    private enum IsOk {
        YES, NO,
    }

    public void main() {

        if (getValue() == IsOk.YES) {
            setBold();
        }
    }

    private IsOk getValue() {
        //Get the flag value set on the screen. It is a fixed value because it is a build.
        return IsOk.YES;
    }

    private String getDisplay() {
        //Get the display value for the flag set on the screen. It is a fixed value because it is a build.
        return "○";
    }

    private void setBold() {
        //Make the letters bold. Code omitted.
    }

## Summary Instead of using the screen display value as it is, use the original value. At least the part that depends on the screen display can be reduced.

Previous article (when processing after conditional branching is redundant)

Next article (ignoring exceptions)

Table of Contents