为什么要花点时间去思考设计模式,代码写起来反而容易?

原创 码农  2019-12-26 11:40:35  阅读 181 次 评论 0 条

2019 马上就要过去了。相信临近年底的你一定和我一样有好多事情需要处理,比如:写年终总结 PPT、制定下个季度 OKR、需求讨论、技术方案设计、开发小伙伴找你调接口、产品小伙伴找你聊可行性等等,当然还有最重要的刷火车票。

为什么要花点时间去思考设计模式,代码写起来反而容易? 为什么要花点时间去思考设计模式,代码写起来反而容易? 编程代码

时间紧、任务重,我该怎么办?

这许多事情堆积到一起占用了大量的时间和精力,所以此时此刻留给开发的资源就更加紧张。

就是在这种情况下,我接手了一个任务。我该怎么尽可能高效的完成它?

权衡之下我们选择了跳过详细设计直接写代码。时间在走,需求再长

呵呵,你能和需求赛跑,累死你.....为什么这种为了节省时间而采取的措施最终反而却浪费了时间?实际上问题的根源是因为跳过了设计阶段。

好的实现需要有好的设计

话不多说了,先上点代码看看

/**
* 服务员
* @Author: xiuxian
*/
public class Waiter {

    /**
    * 下单
    * @param dishName 菜名
    */
    public void order(String dishName){
        System.out.println("客人点餐:" + dishName);

        System.out.println("开始烹饪:" + dishName);
        //菜品不同,做法不同。
        switch (dishName){
            case "西红柿炒鸡蛋":
                System.out.println("先炒鸡蛋");
                System.out.println("再炒西红柿");
                System.out.println("...");
                break;
            case "酸辣土豆丝":
                System.out.println("先放葱姜蒜");
                System.out.println("再放土豆丝");
                System.out.println("...");
            break;
        }
        System.out.println(dishName + "出锅");

        System.out.println(dishName + "上桌啦,请您品尝");
    }
}

细心如你一定发现了,这段代码不仅存在复用性不够的问题,而且健壮性也不够。

职责也不够清晰一个大厨把酒店的活干完了

接下来我们分招人造类分工

/**
 * 厨师
 *
 * @author xiuxian
 */
public class Chef {

    /**
     * 做饭
     * @param dishName 下单的菜名
     */
    public void cooking(String dishName) {
        System.out.println("开始烹饪:"+dishName);
        switch (dishName){
            case "西红柿炒鸡蛋":
                System.out.println("先炒鸡蛋");
                System.out.println("再炒西红柿");
                System.out.println("...");
                break;
            case "酸辣土豆丝":
                System.out.println("先放葱姜蒜");
                System.out.println("再放土豆丝");
                System.out.println("...");
                break;
        }
        System.out.println(dishName + "出锅");
    }
}

厨师类,只负责了一项职责:做饭。这就是类的单一职责原则。

在软件领域,这句话意味着你太关注于代码的细节,而忽略了整体的框架。比如:你编写的代码看起来运行良好,但那是因为你在这个类上花费了很长时间以至于忽略了它身兼多职。

package com.fanqiekt.principle.single;

/**
 * 单一职责原则的服务员
 *
 * @author xiuxian
 */
public class Waiter {
    private Chef chef = new Chef();

    /**
     * 点餐
     * @param dishName 餐名
     */
    public void order(String dishName) {
        System.out.println("客人点餐:"+dishName);

        chef.cooking(dishName);

        System.out.println(dishName+"上桌啦,请您品尝!");
    }
}

如果一开始就进行设计的话,上述示例适合使用设计模式进行封装,针对不同的数据类型分别处理,然后统一进行渲染。这样既符合单一职责原则,也符合开闭原则:

  • 单一职责原则:分离关注点,在这个示例中表现为数据与渲染分离。数据的异常不会影响渲染,反之亦然;
  • 开闭原则:对扩展开放,对修改闭合。如果有新的数据类型需要渲染,我们只需要在策略组中进行扩展即可,而不必修改原有功能。

通过上述的简单设计,我们不但显著的提升了代码的可扩展性、可读性,而且降低了维护成本。

请多花一点时间在设计上!

所以为了能够早点下班、少挠头,请多花点时间进行设计!

本文地址:https://www.itcodeit.com/post/30.html
版权声明:本文为原创文章,版权归 码农 所有,欢迎分享本文,转载请保留出处!

发表评论


表情

还没有留言,还不快点抢沙发?