程式設計正規化的種類
很多人認同的兩個觀點:
程式 = 資料結構 + 演算法
這個表示式認為,如果資料結構設計得好,演算法也會變得簡單,而且乙個好的通用的演算法應該可以用在不同的資料結構上。
演算法 = 控制 + 業務邏輯
這個表示式則想表達的是資料結構不複雜,複雜的是演算法,演算法由兩個邏輯組成,乙個是真正的業務邏輯,另外一種是控制邏輯。也就是我們的業務邏輯是複雜的。
robert kowalski: 任何演算法都會有兩個部分, 乙個是 logic 部分,這是用來解決實際問題的。另乙個是 control 部分,這是用來決定用什麼策略來解決問題。logic 部分是真正意義上的解決問題的演算法,而 control 部分只是影響解決這個問題的效率。程式執行的效率問題和程式的邏輯其實是沒有關係的。我們認為,如果將 logic 和 control 部分有效地分開,那麼**就會變得更容易改進和維護。通過這兩個表示式,我們可以得出:
程式設計正規化,或是程式設計的方法。其實都是在圍繞著這三件事來做的。所有的語言或程式設計正規化都在解決這些問題, 也就是程式設計正規化的本質:
控制
是可以標準化的。比如:遍歷資料、查詢資料、多執行緒、併發、非同步等,都是可以標準化的。
因為控制
需要處理資料,所以標準化 控制 ,需要標準化資料結構
,我們可以通過泛型程式設計來解決這個事。
而控制
還要處理使用者的業務邏輯
。所以可以通過標準化介面 / 協議來實現,我們的 控制 模式可以適配於任何的 業務邏輯 。
有效地分離業務邏輯
、控制
和資料結構
是寫出好程式的關鍵所在!
其中,邏輯 logic 和 控制 control 是關鍵,程式的本質複雜性 是邏輯,非本質複雜性 是控制。這個和系統架構也有相通的地方,邏輯是你的業務邏輯過程的抽象,加上乙個由術語表示的資料結構的定義,控制邏輯跟你的業務邏輯是沒關係的,你控制,它執行。業務邏輯 部分才是真正有意義的
控制 部分只是影響 業務邏輯 部分的效率
那些混亂不堪的**,會把控制和業務邏輯放在一塊。裡面有些變數和流程是跟業務相關的,有些是不相關的。
業務邏輯決定了程式的複雜度,業務邏輯本身就複雜,你的**就不可能寫得簡單。於是 控制 + 業務邏輯 的相互交織成為了最終的程式複雜度。
function
check_form_x()
;}//獲取password欄位,校驗
var password =$(
'#password').
val();
if(null
== password || password.length <=8)
;}//獲取repeat_password欄位,校驗
var repeat_password =$(
'#repeat_password').
val();
if(repeat_password != password.length);}
//獲取email欄位,校驗
var email =$(
'#email').
val();
if(check_email_format
(email));
}//校驗通過
return
;}
整個邏輯頓時清晰了,細節的處理只需要在check_form中編寫一次
var meta_create_user =,,
,]};
var r =
check_form
(meta_create_user)
;
程式設計正規化基本上來說,就是兩大分支
一邊是在解決資料和演算法,
一邊是在解決邏輯和控制。
函式式和邏輯式 偏向於你定義要什麼,而不是怎麼做
程式設計正規化和物件導向程式設計正規化,偏向於怎麼做,而不是要做什麼
程式設計的本質
書名 程式設計的本質 英文版 原書名 elements of programming 作者 alexander stepanov paul mcjones isbn 9787111300274 定價 49.00元 出版社 機械工業出版社 出版年 2010年4月 豆瓣網討論 http www.doub...
程式設計正規化21
double all 123 4 246 8 incr all 123 4 234 5 define double x x2 define incr x 1 map double 1 2 3 4 24 68 eval這個過程的用法,利用它可以實現用scheme語言本身來解釋scheme表示式的功能,...
程式設計正規化總結
什麼是物件導向程式設計?object oriented programming oop 把物件作為基本單元,把物件抽象成類 class 包含成員和方法 資料封裝 繼承 多型 python中使用類來實現。過程式程式設計 函式 oop 類 類變數和例項變數的區別 區分類變數和例項變數 類變數由所有例項共...