# 拆分 Reducer 邏輯 對于任何一個有意義的應用來說，將所有的更新邏輯都放入到單個 reducer 函數中都將會讓程序變得不可維護。雖然說對于一個函數應該有多長沒有準確的規定，但一般來講，函數應該比較短，并且只做一件特定的事。因此，把很長的，同時負責很多事的代碼拆分成容易理解的小片段是一個很好的編程方式。 因為 Redux reducer 也僅僅是一個函數，上面的概念也適用。你可以將 reducer 中的一些邏輯拆分出去，然后在父函數中調用這個新的函數。 這些新的函數通常分為三類： 1. 一些小的工具函數，包含一些可重用的邏輯片段 2. 用于處理特定情況下的數據更新的函數，參數除了 `(state, action)` 之外，通常還包括其它參數 3. 處理給定 state 切片的所有更新的函數，參數格式通常為 `(state, action)` 為了清楚起見，這些術語將用于區分不同類型的功能和不同的用例： - **reducer:** 任何符合 `(state, action) -> newState` 格式的函數（即，可以用做 `Array.reducer` 參數的任何函數）。 - **root reducer:** 通常作為 `createStore` 第一個參數的函數。他是唯一的一個在所有的 reducer 函數中必須符合 `(state, action) -> newState` 格式的函數。 - **slice reducer:** 一個負責處理狀態樹中一塊切片數據的函數，通常會作為 `combineReducers` 函數的參數。 - **case function:** 一個負責處理特殊 action 的更新邏輯的函數。可能就是一個 reducer 函數，也可能需要其他參數才能正常工作。 - **higher-order reducer:** 一個以 reducer 函數作為參數，且/或返回一個新的 reducer 函數的函數（比如： `combineReducers`, `redux-undo`）。 在各種討論中 “sub-reducer” 這個術語通常表示那些不是 root reducer 的任何函數，但這個表述并不是很精確。一些人認為應該表示 "業務邏輯（business logic）" （與應用程序特定行為相關的功能）或者 “工具函數（utility functions）”（非應用程序特定的通用功能）。 將復雜的環境分解為更小，更易于理解的過程就是術語中的 [函數分解(functional decomposition)](http://stackoverflow.com/questions/947874/what-is-functional-decomposition)。這個術語可以用在任何代碼中。在 Redux 中，使用第三個方法來構造 reducer 邏輯是非常普遍的，即更新邏輯被委托在基于 state 切片的的其他函數中。Redux 將這個概念稱為 **reducer composition**，到目前為止，這個方法是構建 reducer 邏輯最常用的方法。事實上， Redux 包含一個 [`combineReducers()`](../../api/combineReducers.md) 的工具函數，它專門抽象化基于 state 切片的其他 reducer 函數的工作過程。但是你必須明確的是，這并不是唯一模式。實際上，完全可以用所有的三種方法拆分邏輯，通常情況下，這也是一個好主意。[Refactoring Reducers](./RefactoringReducersExample.md) 章節會演示一些實例。