一个游戏程序员的代码书写观（一）

一个游戏程序员的代码书写观（一）

故事

游戏中基本都有MessageBox的需求，虽然可以使用OS层面的MessageBox，但是一般而言都不能满足游戏的需求，有鉴于此，我们实现了第一版的定制MessageBox：

public class MessageBoxManager
{
    public enum Mode
    {
        Confirm,
        ConfirmCancel,
    }

    public static void ShowMessageBox(
                                       string title, 
                                       string content, 
                                       Mode mode = Mode.Confirm,
                                       Action onConfirm = null,
                                       Action onCancel = null
                                     )


    // implementations

}

这个实现感觉还可以，虽然参数总共有5个，感觉有些略多，但是我们有预见性的提供了默认参数，同时我们提供了基本的MessageBox功能，可以设置标题，内容，显示模式以及可能的回调函数，基本不用编写什么使用文档，稍有经验的程序员都可以顺畅的写出使用代码：

MessageBoxManager.ShowMessageBox("Title", "My First Message Box !");

随着初版MessageBox的广泛使用，相关的需求也在不断升级，现在我们需要支持可以主动关闭的MessageBox了，分析需求后我们意识到这是一种新的MessageBox模式，经过一定扩展，我们有了第二版的MessageBox：

public class MessageBoxManager
{
    public enum Mode
    {
        Confirm,
        ConfirmClose,
        ConfirmCancel,
        ConfirmCancelClose,
    }

    public static void ShowMessageBox(
                                       string title, 
                                       string content, 
                                       Mode mode = Mode.Confirm,
                                       Action onConfirm = null,
                                       Action onCancel = null,
                                       Action onClose = null,
                                     )


    // implementations

}

Mode的类型增加了，并且接口参数也增加至6个，这里似乎已经有些坏味道了，但是毕竟只增加了一个参数，并且也提供了默认参数，使用上的复杂度似乎还可以接受~

很快的，更多的需求又接踵而至了，现在我们又需要定制MessageBox的按钮文字了，按照之前的思路，我们继续往接口中添加参数：

public class MessageBoxManager
{
    public enum Mode
    {
        Confirm,
        ConfirmClose,
        ConfirmCancel,
        ConfirmCancelClose,
    }

    public static void ShowMessageBox(
                                       string title, 
                                       string content, 
                                       Mode mode = Mode.Confirm,
                                       Action onConfirm = null,
                                       Action onCancel = null,
                                       Action onClose = null,
                                       string confirmText = null,
                                       string cancelText = null,
                                     )


    // implementations

}

还没等这版MessageBox实现完毕，我们又收到了新的需求：MessageBox需要支持超时！好吧，我们又不假思索的继续添加接口参数：

public class MessageBoxManager
{
    public enum Mode
    {
        Confirm,
        ConfirmClose,
        ConfirmCancel,
        ConfirmCancelClose,
    }

    public static void ShowMessageBox(
                                       string title, 
                                       string content, 
                                       Mode mode = Mode.Confirm,
                                       Action onConfirm = null,
                                       Action onCancel = null,
                                       Action onClose = null,
                                       string confirmText = null,
                                       string cancelText = null,
                                       float timeOut = 0,
                                       Action onTimeOut = null,
                                     )


    // implementations

}

现在，我们之前相对简洁的接口已经变的非常冗长，参数更是达到了惊人的10个，使用上也变得非常困难，虽然提供了默认参数，但是仍然容易产生误用，考虑我们使用新接口来定制确认按钮的文字

MessageBoxManager.ShowMessageBox("Title", 
                                 "My Customize Message Box !", 
                                 MessageBoxManager.Mode.Confirm, 
                                 null, 
                                 null, 
                                 null,
                                 null,
                                 "好的");

不仅长串的null参数让人心烦，而且接口的调用还是错误的：我们不小心将confirmText参数设置给了cancelText……

方法

放弃原接口的默认参数实现方式，转而使用重载的方式来提供多个接口已达到分解功能的目的，虽然仍然存在参数组合过多导致接口数量过多的问题，但是感谢二八原则，在实际的重载过程中，我们可以根据使用情况来达到相对平衡的封装程度，对于第三方的代码，如果遇到类似参数过多的问题，我们也可以借助外观模式等方法做类似的处理

据此我们实现的新版MessageBox：

public class MessageBoxManager
{
    public enum Mode
    {
        Confirm,
        ConfirmClose,
        ConfirmCancel,
        ConfirmCancelClose,
    }

    public static void ShowMessageBox(
                                       string title, 
                                       string content, 
                                       Mode mode = Mode.Confirm,
                                       Action onConfirm,
                                       Action onCancel,
                                       Action onClose,
                                       string confirmText,
                                       string cancelText,
                                       float timeOut,
                                       Action onTimeOut,
                                     )

    public static void ShowMessageBox(
                                       string title, 
                                       string content, 
                                       Action onConfirm,
                                     )
    {
        ShowMessageBox(title, content, Mode.Confirm, onConfirm, null, null, null, null, 0, null);    
    }

    public static void ShowMessageBox(
                                       string title, 
                                       string content, 
                                       Action onConfirm,
                                       Action onCancel,
                                     )
    {
        ShowMessageBox(title, content, Mode.ConfirmCancel, onConfirm, onCancel, null, null, null, 0, null);  
    }

    // other useful overrides

    // implementations

}

准则

函数的参数数量应该尽可能的控制（Rob大叔在《CleanCode》中描述过的一个观点是尽量减少函数参数的数量，最好不要超过三个），但是实际开发中因为需求增加、时间压力等情况，往往会出现函数参数数量增加甚至爆炸的情况，这种情况下可以考虑采取重载等方式进行进一步的封装，同时基于实际的使用情况来达到尽可能的平衡~

简单一句话：遇到复杂度偏高的代码，考虑进行平衡的封装吧!