程式碼簡化之路

大盜發表於2017-12-02

這段時間一直在啃演算法，很久都沒有寫過文章了，主要是演算法這東西被人反反覆覆寫，水平高低的文章都有，我也就不想湊這個熱鬧，當然了，遇到有意思的問題，還是想記一下的。

以上與我要寫的東西沒什麼關聯，我也就不廢話了。

策略模式

在現在的開發中，大概有23種設計模式，其中用途最多最廣的無外乎單例，策略，介面卡，委託幾種模式，大概講一下策略模式，因為可能會用到。

策略模式簡單來說就是根據不同的環境和條件自動選擇不同的演算法和實現，即策略模式是對演算法的封裝，它把演算法的責任和演算法本身分割開，委派給不同的物件管理。

下面看一段程式碼（大概看上兩三行就可以繼續往下翻）：

public static void setAction(JMenuItem menuItem) {
        if (menuItem.getText().equals("New")) {
            menuItem.addActionListener(
                    event -> {
                    //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Open")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Exit")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Goto")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Help")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Windows")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        } else if (menuItem.getText().equals("Setting")) {
            menuItem.addActionListener(
                    event -> {
                        //someting to do.
                    }
            );
        }
}
複製程式碼

簡單看來，這段程式碼是用到了策略模式，不過和我們所看到的標準定義有所不同，他是通過if和else來進行的判斷。

NOTE： 所謂設計模式，其實並沒有標準定義，而我所說的“標準定義”其實是，被大家公認的，接受的定義，因為有了定義才方便我們去交流，不然我們交流起來就是——“我寫了一個方法（函式），去將各個不同的演算法封裝，然後將引數傳遞給這個方法之後，由該方法去決定如何選擇演算法。” 又臭又長，誰願意看，切記一點，設計模式是一種思想，雖然現在被形式化的定義了，但是卻並不是必要關係。有了設計模式的思想才有了形式化的定義，而不是有了形式化的定義之後才有了設計模式，不要顛倒因果關係（也別死磕）。

可以看出來這應該程式碼應該是寫的選單事件，還用了Lambda表示式，嘿喲，有點兒意思。

但是也能看出來，硬傷很多，先不說後期可能增加的選單項有多少，就說為了完善這個按鈕事件，程式碼量就絕對不會少，一個函式封裝了百行以上的程式碼，真的是很少見了。

這有違我們追求的簡潔程式碼。

簡化程式碼

對這段程式碼的簡化很簡單，每個人都有每個人不同的方法。

就比如說：

  • 按鈕事件的實現分發給其他方法，在這個方法中不對按鈕的事件進行實現，在本方法中只儲存if…else…結構，這樣一來，我們保證了一個函式\方法完成一個功能這一準則，方便了後期的維護。
  • 當然了，我們還能使用多類，每一個類職責單一，如上述程式碼，NewItem類實現按鈕New的功能，由於是一個類，我們甚至可以為這個按鈕做更多事情。不難想象，這樣會擴充類庫，使類庫變得更加臃腫（可能只有大型專案會要求避免這種問題），但，不失為一個很好的方法。
  • 路由……對上述程式碼的結構和功能可能不太實用。

簡單來條實現（真的很簡陋）：

public static void setAction(JMenuItem menuItem) {
	//這裡使用反射，也就是採用了上述第二個方法。
	if (menuItem.getText().equals("New") setAction("New", menuItem);
	//else if ……
}
複製程式碼

方法多種多樣，但要記住一句話：方法本身是沒有對不對的問題，有的只是適不適合的問題。

擇優啊，兄弟們。

隨手起標題

筆者注：標題浮誇了不行，太務實也不行，這就是我討厭起標題的原因了。

相關文章