国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

設(shè)計(jì)模式7大原則

ky0ncheng / 3142人閱讀

摘要:在面向?qū)ο笤O(shè)計(jì)中,可維護(hù)性的復(fù)用是以設(shè)計(jì)原則為基礎(chǔ)的。面向?qū)ο笤O(shè)計(jì)原則為支持可維護(hù)性復(fù)用而誕生,這些原則蘊(yùn)含在很多設(shè)計(jì)模式中,它們是從許多設(shè)計(jì)方案中總結(jié)出的指導(dǎo)性原則。

面向?qū)ο笤O(shè)計(jì)原則 概述

對(duì)于面向?qū)ο筌浖到y(tǒng)的設(shè)計(jì)而言,在支持可維護(hù)性的同時(shí),提高系統(tǒng)的可復(fù)用性是一個(gè)至關(guān)重要的問(wèn)題,如何同時(shí)提高一個(gè)軟件系統(tǒng)的可維護(hù)性和可復(fù)用性是面向?qū)ο笤O(shè)計(jì)需要解決的核心問(wèn)題之一。在面向?qū)ο笤O(shè)計(jì)中,可維護(hù)性的復(fù)用是以設(shè)計(jì)原則為基礎(chǔ)的。每一個(gè)原則都蘊(yùn)含一些面向?qū)ο笤O(shè)計(jì)的思想,可以從不同的角度提升一個(gè)軟件結(jié)構(gòu)的設(shè)計(jì)水平。 面向?qū)ο笤O(shè)計(jì)原則為支持可維護(hù)性復(fù)用而誕生,這些原則蘊(yùn)含在很多設(shè)計(jì)模式中,它們是從許多設(shè)計(jì)方案中總結(jié)出的指導(dǎo)性原則。面向?qū)ο笤O(shè)計(jì)原則也是我們用于評(píng)價(jià)一個(gè)設(shè)計(jì)模式的使用效果的重要指標(biāo)之一,在設(shè)計(jì)模式的學(xué)習(xí)中,大家經(jīng)常會(huì)看到諸如“XXX模式符合XXX原則”、“XXX模式違反了XXX原則”這樣的語(yǔ)句。
最常見(jiàn)的7種面向?qū)ο笤O(shè)計(jì)原則如下表所示:

1.單一職責(zé)原則 單一職責(zé)定義
一個(gè)類只負(fù)責(zé)一個(gè)功能領(lǐng)域中的相應(yīng)職責(zé),或者可以定義為:就一個(gè)類而言,應(yīng)該只有一個(gè)引起它變化的原因

從定義中不難思考,一個(gè)類的所做的事情越多,也就越難以復(fù)用,因?yàn)橐坏┳龅氖虑槎嗔耍氊?zé)的耦合度就變高了所以我們根據(jù)這個(gè)原則應(yīng)該將不同職責(zé)封裝在不同類中,不同的變化封裝在不同類中。從我們平常的開(kāi)發(fā)中不難發(fā)現(xiàn),如果一個(gè)類或者方法接口等等只做一件事,那么可讀性很高,并且復(fù)用性也很高,并且一旦需求變化,也容易維護(hù),假如你一個(gè)類糅雜多個(gè)職責(zé),那么很難維護(hù)。

單一職責(zé)舉例分析

從實(shí)際業(yè)務(wù)來(lái)剝離一個(gè)例子:現(xiàn)在有這么一種情況,某租車平臺(tái)個(gè)人模塊類涉及多個(gè)方法,有如下登錄、注冊(cè)、支付寶押金支付、微信押金支付、支付寶套餐支付、微信套餐支付、整個(gè)結(jié)構(gòu)如下:

      /**
     * 個(gè)人模塊
     */
    @Controller
    public class userController{
        /**
         * 登錄
         */
        public void login(){
        }

        /**
         * 注冊(cè)
         */
        public void register(){
        }
        /**
         * 押金支付(阿里)
         */
        public void payAliDeposit(){
        }

        /**
         * 押金支付(微信)
         */
        public void payWXDeposit(){
        }

        /**
         * 套餐支付(阿里)
         */
        public void payAliPackage(){
        }

        /**
         * 套餐支付(微信)
         */
        public void payWXPackage(){
        }
    }

我們可以看到很多功能都糅雜在一起,一個(gè)類做了那么多事情,很臃腫,別提維護(hù),就連找代碼都很困難,所以我們可以對(duì)這個(gè)UserController進(jìn)行拆解,與此同時(shí)我們應(yīng)該分包,比如這個(gè)應(yīng)該在xxx.xxx.userMoudule下面,可能支付相關(guān)的有公共的方法,登錄抑或也有公共的方法,那邊抽成公共服務(wù)去調(diào)用。

public class LoginController(){}
public class registerController(){}
public class depositPayController(){
    // 支付寶支付
    // 微信支付
}
public class packagePayController(){
    // 支付寶支付
    // 微信支付
}

整個(gè)方案實(shí)現(xiàn)的目的就是為了解決高耦合,代碼復(fù)用率低下的問(wèn)題。單一職責(zé)理解起來(lái)不難,但是實(shí)際操作需要根據(jù)具體業(yè)務(wù)的糅雜度來(lái)切割,實(shí)際上很難運(yùn)用。

2.開(kāi)閉原則 開(kāi)閉原則簡(jiǎn)介

開(kāi)閉原則是面向?qū)ο蟮目蓮?fù)用設(shè)計(jì)的第一塊基石,它是最重要的面向?qū)ο笤O(shè)計(jì)原則,定義如下:

一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放,對(duì)修改關(guān)閉。即軟件實(shí)體應(yīng)盡量在不修改原有代碼的情況下進(jìn)行擴(kuò)展。

軟件實(shí)體包括以下幾個(gè)部分:

項(xiàng)目或軟件產(chǎn)品中按照一定的邏輯規(guī)則劃分的模塊

抽象和類

方法

注意:開(kāi)閉原則是指對(duì)擴(kuò)展開(kāi)放,對(duì)修改關(guān)閉,并不是說(shuō)不做任何的修改

開(kāi)閉原則的優(yōu)勢(shì)

可以使原來(lái)的測(cè)試代碼依舊可以運(yùn)行,只需要對(duì)擴(kuò)展的代碼進(jìn)行測(cè)試即可

可以提高代碼的復(fù)用性

可以提高系統(tǒng)的維護(hù)性

如何使用開(kāi)閉原則

抽象約束

通過(guò)接口或者抽象類約束擴(kuò)展,對(duì)擴(kuò)展進(jìn)行邊界限定,不允許出現(xiàn)在接口或抽象類中不存在的public方法;

參數(shù)類型、引用對(duì)象盡量使用接口或者抽象類,而不是實(shí)現(xiàn)類;(針對(duì)抽象編程)

抽象層盡量保持穩(wěn)定,一旦確定即不允許修改。

元數(shù)據(jù)控制模塊行為

通俗來(lái)說(shuō)就是通過(guò)配置文件來(lái)操作數(shù)據(jù),spring的控制反轉(zhuǎn)就是一個(gè)很典型的例子。

約定優(yōu)于配置

封裝變化

將相同的變化封裝到一個(gè)接口或者類中

將不同的變化封裝到不同的類或者接口中(單一職責(zé)的體現(xiàn))

案例
某公司開(kāi)發(fā)的租車系統(tǒng)有一個(gè)押金支付功能,支付方式有支付寶、阿里支付,后期可能還有銀聯(lián)支付、易支付等等,原始的設(shè)計(jì)方案如下:

// 客戶端調(diào)用-押金支付選擇支付手段
public class DepositPay {

    void pay(String type){
        if(type.equals("ali")){
            AliPay aliPay = new AliPay();
            aliPay.pay();
        }else if(type.equals("wx")){
            WXPay wxPay = new WXPay();
            wxPay.pay();
        }
    }
}
// 支付寶支付
public class AliPay {
    public void pay() {
        System.out.println("正在使用支付寶支付");
    }
}
// 微信支付
public class WXPay{
    public void pay() {
        System.out.println("正在使用微信支付");
    }
}

在以上代碼中,如果需要增加銀聯(lián)支付,如YLPay,那么就必須要修改DepositPay中的pay方法的源代碼,增加新的判斷邏輯,違反了開(kāi)閉原則(對(duì)修改關(guān)閉,對(duì)擴(kuò)展開(kāi)放,注意這邊的銀聯(lián)支付相當(dāng)于擴(kuò)展,所以它沒(méi)有違反規(guī)則),所以現(xiàn)在必須重構(gòu)此代碼,讓其遵循開(kāi)閉原則,做法如下:

增加一個(gè)接口,使得各種具體支付實(shí)現(xiàn)其接口

DepositPay類針對(duì)接口編程,由客戶端來(lái)決定具體使用哪種支付方式

重構(gòu)后的圖如下所示:

在上圖中我們引入了接口Pay,定義了pay方法,并且DepositPay是針對(duì)接口編程,通過(guò)setPayMode()由客戶端來(lái)實(shí)例化具體的支付方式,在DepositPay的pay()方法中調(diào)用payMode對(duì)象來(lái)支付。如果需要增加新的支付方式,比如銀聯(lián)支付,只需要讓它也實(shí)現(xiàn)Pay接口,在配置文件中配置銀聯(lián)支付即可,依賴注入是實(shí)現(xiàn)此開(kāi)閉原則的一種手段,在這里不贅述,源碼如下:

public interface Pay {
    // 支付
    void pay();
}
public class AliPay implements Pay {
    @Override
    public void pay() {
        System.out.println("正在使用支付寶支付");
    }
}
public class WXPay implements Pay{
    @Override
    public void pay() {
        System.out.println("正在使用微信支付");
    }
}
// 客戶端調(diào)用-押金支付選擇支付手段
public class DepositPay {
    // 支付方式 (這邊可以通過(guò)依賴注入的方式來(lái)注入)
    // 支付方式可以寫(xiě)在配置文件中
    // 現(xiàn)在不管你選用何種方式,我都不需要更改
    @Autowired
    Pay payMode;
    void pay(Pay payMode){
        payMode.pay();
    }
}

因?yàn)榕渲梦募梢灾苯泳庉嫞也恍枰幾g,所以一般不認(rèn)為更改配置文件是更改源碼。如果一個(gè)系統(tǒng)能做到只需要修改配置文件,無(wú)需修改源碼,那么復(fù)合開(kāi)閉原則。

3.里氏代換原則 里氏替換原則簡(jiǎn)介
Barbara Liskov提出:

標(biāo)準(zhǔn)定義:如果對(duì)每一個(gè)類型為S的對(duì)象o1,都有類型為T(mén)的對(duì)象o2,使得以T定義的所有程序P在所有的對(duì)象o1代換o2時(shí),程序P的行為沒(méi)有變化,那么類型S是類型T的子類型。

上面的定義可能比較難以理解,簡(jiǎn)單理解就是所有引用基類(父類的)地方都可以用子類來(lái)替換,且程序不會(huì)有任何的異常。但是反過(guò)來(lái)就不行,所有使用子類的地方則不一定能用基類來(lái)替代,很簡(jiǎn)單的例子狗是動(dòng)物,不能說(shuō)動(dòng)物是狗,因?yàn)榭赡苓€有貓。。。。

里氏替換原則是實(shí)現(xiàn)開(kāi)閉原則的重要方式之一,由于使用基類的所有地方都可以用子類來(lái)替換,因此在程序中盡量使用基類來(lái)定義對(duì)象,在運(yùn)行時(shí)確定其子類類型

里氏替換原則約束

子類必須實(shí)現(xiàn)父類的抽象方法,但不得重寫(xiě)(覆蓋)父類的非抽象(已實(shí)現(xiàn))方法。

子類中可以添加特有方法(父類中不存在),此時(shí)則無(wú)法在以父類定義的對(duì)象中使用該方法,除非在使用的時(shí)候強(qiáng)轉(zhuǎn)基類成子類進(jìn)行調(diào)用。

當(dāng)子類覆蓋或?qū)崿F(xiàn)父類的方法時(shí),方法的前置條件(即方法的形參)要比父類方法的輸入?yún)?shù)更寬松。

當(dāng)子類的方法實(shí)現(xiàn)父類的抽象方法時(shí),方法的后置條件(即方法的返回值)要比父類更嚴(yán)格。

所以我們?cè)谶\(yùn)用里氏替換原則的時(shí)候,盡量把父類設(shè)計(jì)為抽象類或者接口,讓子類繼承父類或者實(shí)現(xiàn)接口并實(shí)現(xiàn)在父類中聲明的方法,運(yùn)行時(shí),子類實(shí)例替換父類實(shí)例,我們可以很方便地?cái)U(kuò)展系統(tǒng)的功能,同時(shí)無(wú)須修改原有子類的代碼,增加新的功能可以通過(guò)增加一個(gè)新的子類來(lái)實(shí)現(xiàn)。里氏代換原則是開(kāi)閉原則的具體實(shí)現(xiàn)手段之一。
里氏替換原則實(shí)戰(zhàn)

某租車系統(tǒng)客戶分為普通用戶(customer)和VIP客戶(VIPCustomer),系統(tǒng)需要提供一個(gè)根據(jù)郵箱重置密碼的功能。原始設(shè)計(jì)圖:

在編寫(xiě)重置密碼的時(shí)候發(fā)現(xiàn),業(yè)務(wù)邏輯是一樣的,存在著大量的重復(fù)代碼,而且還可能增加新的用戶類型,為了減少代碼重復(fù)性,使用里氏替換原則進(jìn)行重構(gòu):

圖上重置密碼交由ResetPassword類去處理,只需要傳入Customer類即可,不管任何類型的Customer類,只要繼承自Customer,都可以使用里氏替換原則進(jìn)行替換,假如有新的類型,我們只需要在配置文件中注入新的類型即可。代碼如下(簡(jiǎn)單意會(huì)一下):

// 抽象基類
public abstract class Customer {
}
public class CommonCustomer  extends Customer{
}
public class VIPCustomer  extends Customer{
}
// 重置密碼邏輯在這里實(shí)現(xiàn),只需要傳入對(duì)應(yīng)的類型即可
public class ResetPassword {
    void resetPassword(Customer customer){
    }
}

里氏替換原則是實(shí)現(xiàn)開(kāi)閉原則不可或缺的手段之一,在本例中,通過(guò)傳遞參數(shù)使用基類對(duì)象,針對(duì)抽象編程,從而滿足開(kāi)閉原則。

4.依賴倒轉(zhuǎn)原則 依賴倒轉(zhuǎn)原則簡(jiǎn)介
依賴倒轉(zhuǎn)原則(Dependency Inversion  Principle, DIP):抽象不應(yīng)該依賴于細(xì)節(jié),細(xì)節(jié)應(yīng)當(dāng)依賴于抽象。換言之,要針對(duì)接口編程,而不是針對(duì)實(shí)現(xiàn)編程。

可以通俗的定義為兩種:

高層次的模塊不應(yīng)該依賴于低層次的模塊,他們都應(yīng)該依賴于抽象。

抽象不應(yīng)該依賴于具體實(shí)現(xiàn),具體實(shí)現(xiàn)應(yīng)該依賴于抽象。

要求我們?cè)谠O(shè)計(jì)程序的時(shí)候盡量使用層次高的抽象層類,即使用接口和抽象類進(jìn)行變量的聲明、參數(shù)類型聲明、方法返回類型聲明以及數(shù)據(jù)類型轉(zhuǎn)換等等,同時(shí)要注意一個(gè)具體類應(yīng)該只實(shí)現(xiàn)抽象類或者接口中存在的方法,不要給出多余的方法,這樣抽象類將無(wú)法調(diào)用子類增加的方法.我們可以通過(guò)配置文件來(lái)寫(xiě)入具體類,這樣一旦程序行為改變,可直接改變配置文件,而不需要更改程序,重新編譯,通過(guò)依賴倒轉(zhuǎn)原則來(lái)滿足開(kāi)閉原則。

在實(shí)現(xiàn)依賴倒轉(zhuǎn)原則時(shí),我們需要針對(duì)抽象層編程,而將具體類的對(duì)象通過(guò)依賴注入(DependencyInjection, DI)的方式注入到其他對(duì)象中,依賴注入是指當(dāng)一個(gè)對(duì)象要與其他對(duì)象發(fā)生依賴關(guān)系時(shí),通過(guò)抽象來(lái)注入所依賴的對(duì)象。常用的注入方式有三種,分別是:構(gòu)造注入,設(shè)值注入(Setter注入)和接口注入

依賴倒轉(zhuǎn)原則實(shí)例

這部分可以參照上面開(kāi)閉原則案例,可以從那例子中看出,開(kāi)閉原則,依賴倒轉(zhuǎn)原則,里氏替換原則同時(shí)出現(xiàn)了,可以說(shuō)`開(kāi)閉原則是我們要實(shí)現(xiàn)的目標(biāo),而里氏替換原則是實(shí)現(xiàn)手段之一,而同時(shí)里氏替換原則又是依賴倒轉(zhuǎn)原則實(shí)現(xiàn)的基礎(chǔ),因?yàn)榧尤霙](méi)有這個(gè)理論,依賴倒轉(zhuǎn)原則是不成立的,無(wú)法針對(duì)抽象編程,要注意這3個(gè)原則基本都是同時(shí)出現(xiàn)的。

5.接口隔離原則 接口隔離原則簡(jiǎn)介
接口隔離原則的兩個(gè)定義:

1:使用多個(gè)專門(mén)的接口,而不使用單一的總接口,即客戶端不應(yīng)該依賴那些它不需要的接口

2:類間的依賴關(guān)系應(yīng)該建立在最小的接口上

接口的含義:

一個(gè)接口代表一個(gè)角色,不應(yīng)該將不同的角色都交給一個(gè)接口,因?yàn)檫@樣可能會(huì)形成一個(gè)臃腫的大接口;

特定語(yǔ)言的接口,表示接口僅僅是提供客戶端需要的行為,客戶端不需要的行為則隱藏起來(lái),應(yīng)當(dāng)為客戶端提供盡可能小的多帶帶的接口,而不要提供大的總接口。

根據(jù)接口隔離原則,我們可明白,每個(gè)接口都應(yīng)只承擔(dān)一種相對(duì)獨(dú)立的角色,不干不該干的事情.

實(shí)例演示
場(chǎng)景:模擬動(dòng)物平時(shí)的動(dòng)作,當(dāng)然也包括人,最初的設(shè)計(jì)就是一個(gè)總接口IAnimal,里面定義動(dòng)物會(huì)有的一些動(dòng)作。

代碼如下:

 public interface IAnimal{
        /**
         * 吃飯
         */
        void eat();

        /**
         * 工作
         */
        void work();

        /**
         * 飛行
         */
        void  fly();
    }
 public class Tony implements IAnimal{

        @Override
        public void eat() {
            System.out.println("tony吃");
        }

        @Override
        public void work() {
            System.out.println("tony工作");
        }

        @Override
        public void fly() {
            System.out.println("tony不會(huì)飛");
        }
    }
public class Bird implements IAnimal{

        @Override
        public void eat() {
            System.out.println("鳥(niǎo)吃");
        }

        @Override
        public void work() {
            System.out.println("鳥(niǎo)工作");
        }

        @Override
        public void fly() {
            System.out.println("鳥(niǎo)飛");
        }
    }
    

根據(jù)上面的寫(xiě)法發(fā)現(xiàn)Tony需要實(shí)現(xiàn)飛的接口,這很明顯不僅僅是多余,而且不合理,因此需要通過(guò)接口隔離原則進(jìn)行重構(gòu):

/**
 * 抽象動(dòng)物的行為
 */
public interface IAnimal {
    /**
     * 吃飯
     */
    void eat();

    /**
     * 睡覺(jué)
     */
    void sleep();
}
/**
 * 高級(jí)動(dòng)物人 的行為
 */
public interface IAdvancedAnimalBehavior {
    /**
     * 打牌
     */
    void playCard();

    /**
     * 騎車
     */
    void byBike();
}
/**
 * 低級(jí)動(dòng)物的行為
 */
public interface IJuniorAnimalBehavior {
    /**
     * fly
     */
    void fly();
}
/**
 * 實(shí)現(xiàn)高級(jí)動(dòng)物人的共通方法
 */
public class AbstractAdvancedAnimal implements IAnimal {
    @Override
    public void eat() {
        System.out.println("人吃");
    }

    @Override
    public void sleep() {
        System.out.println("人睡");
    }
}
/**
 * 實(shí)現(xiàn)低級(jí)動(dòng)物人的共通方法
 */
public class AbstractJuniorAnimal implements IAnimal {
    @Override
    public void eat() {
        System.out.println("動(dòng)物吃");
    }

    @Override
    public void sleep() {
        System.out.println("動(dòng)物睡");
    }
}
// tony
public class Tony extends AbstractAdvancedAnimal implements IAdvancedAnimalBehavior {
    @Override
    public void playCard() {
        System.out.println("tony打牌");
    }

    @Override
    public void byBike() {
        System.out.println("tony騎車");
    }
}
// 鳥(niǎo)
public class Bird extends AbstractJuniorAnimal implements IJuniorAnimalBehavior{
    @Override
    public void fly() {
        System.out.println("鳥(niǎo)飛");
    }
}

重構(gòu)之后,首先定義了一個(gè)總的動(dòng)物接口的大類,然后分別使用了兩個(gè)抽象類(一個(gè)是高級(jí)動(dòng)物,一個(gè)是低級(jí)動(dòng)物)分別去實(shí)現(xiàn)這些公共的方法,實(shí)現(xiàn)中可以拋出異常,表明繼承此抽象類的類可以選擇性的重寫(xiě),可不重寫(xiě)。之后再定義了兩個(gè)行為接口表明高級(jí)動(dòng)物和低級(jí)動(dòng)物所特有的,這樣使得接口之間完全隔離,動(dòng)物接口不再糅雜各種各樣的角色,當(dāng)然接口的大小尺度還是要靠經(jīng)驗(yàn)來(lái)調(diào)整,不能太小,會(huì)造成接口泛濫,也不能太大,會(huì)背離接口隔離原則。

6.合成復(fù)用原則 合成復(fù)用原則簡(jiǎn)介
合成復(fù)用原則(Composite Reuse Principle, CRP):盡量使用對(duì)象組合,而不是繼承來(lái)達(dá)到復(fù)用的目的。

通過(guò)合成復(fù)用原則來(lái)使一些已有的對(duì)象使之成為對(duì)象的一部分,一般通過(guò)組合/聚合關(guān)系來(lái)實(shí)現(xiàn),而盡量不要使用繼承。因?yàn)榻M合和聚合可以降低類之間的耦合度,而繼承會(huì)讓系統(tǒng)更加復(fù)雜,最重要的一點(diǎn)會(huì)破壞系統(tǒng)的封裝性,因?yàn)槔^承會(huì)把基類的實(shí)現(xiàn)細(xì)節(jié)暴露給子類,同時(shí)如果基類變化,子類也必須跟著改變,而且耦合度會(huì)很高。

7.迪米特法則

參考:https://www.cnblogs.com/muzon...
參考:https://blog.csdn.net/lovelio...
參考:https://blog.csdn.net/qq_3496...

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/72715.html

相關(guān)文章

  • 6大原因?qū)е隆缸畎踩某绦颉挂矔?huì)出現(xiàn)隱患!

    摘要:所有即使是公司制定了最嚴(yán)格的代碼安全規(guī)范同時(shí)每個(gè)程序員都有能并完美執(zhí)行了安全編碼規(guī)范,也只能解決最多的潛在問(wèn)題。大型為了確保安全還可以采用滲透測(cè)試和分析公司提出來(lái)的一項(xiàng)新興技術(shù),稱運(yùn)行應(yīng)用程序自我保護(hù)功能。 盡管像銀行、大型電商以及政府等大型機(jī)構(gòu)在確保程序員寫(xiě)出最安全的軟件上付出了巨大的努力:比如雇傭最有經(jīng)驗(yàn)的程序員,使用昂貴的代碼分析工具等等。但是媒體頭條上還是經(jīng)常可以看到大型組織出...

    ytwman 評(píng)論0 收藏0
  • 設(shè)計(jì)模式概述

    概念:設(shè)計(jì)模式(Design Pattern)---人們?cè)诿鎸?duì)同類型軟件工程設(shè)計(jì)問(wèn)題所總結(jié)的經(jīng)驗(yàn)。模式不是代碼,而是某類問(wèn)題的通用設(shè)計(jì)方案。目的:為了代碼的重用性、讓代碼易于理解,保證代碼的可靠性。分類:總體可以分為三大類:設(shè)計(jì)模式的5+2大原則:1,單一責(zé)任原則(Single Responsibility Principle)2,開(kāi)放封閉原則(Open Closed Principle)3,里氏...

    社區(qū)管理員 評(píng)論0 收藏0
  • 常見(jiàn)設(shè)計(jì)模式遵循的設(shè)計(jì) - 開(kāi)放關(guān)閉原

    摘要:搞論文準(zhǔn)備答辯的時(shí)候,仔細(xì)思考以及仔細(xì)閱讀很多設(shè)計(jì)模式的文章后,終于對(duì)開(kāi)閉原則有了一點(diǎn)認(rèn)識(shí)。其實(shí),我們遵循設(shè)計(jì)模式其他幾大原則,以及使用種設(shè)計(jì)模式的目的就是遵循開(kāi)閉原則。 之前簡(jiǎn)單介紹了常見(jiàn)設(shè)計(jì)模式遵循的設(shè)計(jì)原則--單一職責(zé)原則,這篇介紹一下另外一個(gè)相當(dāng)重要和具有指導(dǎo)性的一個(gè)原則,開(kāi)放關(guān)閉原則。但是,關(guān)于這一個(gè)原則的使用,經(jīng)驗(yàn)是相當(dāng)重要的一個(gè)因素。 但是個(gè)人感覺(jué)開(kāi)閉原則可能是設(shè)計(jì)模式幾...

    icyfire 評(píng)論0 收藏0
  • PHP基礎(chǔ)系列之正表達(dá)式(一)

    摘要:正則表達(dá)式作為一個(gè)匹配的模板,是由定界符,原子普通字符,例如有特殊功能的字符稱為元字符,例如等以及模式修正符等部分組成的文字模式。正則表達(dá)式中可以使用編碼。限定符限定符用來(lái)指定正則表達(dá)式的一個(gè)給定原子必須要出現(xiàn)多少次才能滿足匹配。 正則表達(dá)式的定義 正則表達(dá)式就是描述字符排列模式的一種自定義的語(yǔ)法規(guī)則。由于正則表達(dá)式本身具有一套非常完整的、可以編寫(xiě)模式的語(yǔ)法體系,提供了一種靈活且直觀的...

    Anchorer 評(píng)論0 收藏0
  • 前端也要學(xué)系列:設(shè)計(jì)模式之策略模式

    摘要:做前端開(kāi)發(fā)已經(jīng)好幾年了,對(duì)設(shè)計(jì)模式一直沒(méi)有深入學(xué)習(xí)總結(jié)過(guò)。今天第一天,首先來(lái)講策略模式。什么是策略模式四兄弟的經(jīng)典設(shè)計(jì)模式中,對(duì)策略模式的定義如下定義一系列的算法,把它們一個(gè)個(gè)封裝起來(lái),并且使它們可互相替換。 做前端開(kāi)發(fā)已經(jīng)好幾年了,對(duì)設(shè)計(jì)模式一直沒(méi)有深入學(xué)習(xí)總結(jié)過(guò)。隨著架構(gòu)相關(guān)的工作越來(lái)越多,越來(lái)越能感覺(jué)到設(shè)計(jì)模式成為了我前進(jìn)道路上的一個(gè)阻礙。所以從今天開(kāi)始深入學(xué)習(xí)和總結(jié)經(jīng)典的設(shè)計(jì)模...

    Anchorer 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<