1. 程序設計語言從程序設計方法來分可分為什麼
程序設計語言分為:
1、命令式語言;2、函數式語言,基於數學函數概念的值映射的λ運算元可計算模型;3、邏輯式語言,基於一組已知規則的形式邏輯系統;4、面向對象語言。
程序設計語言分為:
1、命令式語言。
這種語言的語義基礎是模擬「數據存儲/數據操作」的圖靈機可計算模型,十分符合現代計算機體系結構的自然實現方式。
其中產生操作的主要途徑是依賴語句或命令產生的副作用。現代流行的大多數語言都是這一類型,比如Fortran、Pascal、C++obol、C、C++、Basic、Ada、Java、C#等,各種腳本語言也被看作是此種類型。
2、函數式語言。
這種語言的語義基礎是基於數學函數概念的值映射的λ運算元可計算模型。這種語言非常適合於進行人工智慧等工作的計算。典型的函數式語言如Lisp、Haskell、ML、Scheme、F#等。
3、邏輯式語言。
這種語言的語義基礎是基於一組已知規則的形式邏輯系統。這種語言主要用在專家系統的實現中。最著名的邏輯式語言是Prolog。
4、面向對象語言。
現代語言中的大多數都提供面向對象的支持,但有些語言是直接建立在面向對象基本模型上的,語言的語法形式的語義就是基本對象操作。主要的純面向對象語言是Smalltalk。
雖然各種語言屬於不同的類型,但它們各自都不同程度地對其他類型的運算模式有所支持。
2. 程序設計主要有哪些方法
程序設計主要方法有面向結構的方法和面向對象的方法。
結構化程序設計
隨著計算機的價格不斷下降,硬體環境不斷改善,運行速度不斷提升。程序越寫越大,功能越來越強,講究技巧的程序設計方法已經不能適應需求了。記得是哪本書上講過,一個軟體的開發成本是由:程序設計 30% 和程序維護 70% 構成。這是書上給出的一個理論值,但實際上,從我十幾年的工作經驗中,我得到的體會是:程序設計占 10%,而維護要佔 90%。也許我說的還是太保守了,維護的成本還應該再提高。下面這個程序,提供了兩種設計方案,大家看看哪個更好一些那?
題目:對一個數組中的100個元素,從小到大排序並顯示輸出。(BASIC)
方法1:冒泡法排序,同時輸出。
FOR I=1 TO 100
FOR J=I+1 TO 100
IF A[I] > A[J] THEN T=A[J]: A[J]=A[I]: A[I]=T
NEXT J
? A[I]
NEXT I
方法2:冒泡法排序,然後再輸出。
FOR I=1 TO 100
FOR J=I+1 TO 100
IF A[I] > A[J] THEN T=A[J]: A[J]=A[I]: A[I]=T
NEXT
NEXT
FOR I=1 TO 100
? A[I]
NEXT
顯然,「方法1」比「方法2」的效率要高,運行的更快。但是,從現在的程序設計角度來看,「方法2」更高級。原因很簡單:(1)功能模塊分割清晰——易讀;(2)也是最重要的——易維護。程序在設計階段的時候,就要考慮以後的維護問題。比如現在是實現了在屏幕上的輸出,也許將來某一天,你要修改程序,輸出到列印機上、輸出到繪圖儀上;也許將來某一天,你學習了一個新的高級的排序方法,由「冒泡法」改進為「快速排序」、「堆排序」。那麼在「方法2」的基礎上進行修改,是不是就更簡單了,更容易了?!這種把功能模塊分離的程序設計方法,就叫「結構化程序設計」。
面向對象的程序設計
隨著程序的設計的復雜性增加,結構化程序設計方法又不夠用了。不夠用的根本原因是「代碼重用」的時候不方便。面向對象的方法誕生了,它通過繼承來實現比較完善的代碼重用功能。很多學生在應聘工作,面試的時候,常被問及一個問題「你來談談什麼是面向對象的程序設計」,學生無言,回來問我,這個問題應該怎麼回答。我告訴他,你只要說一句話就夠了「面向對象程序設計是對數據的封裝;範式(模板)的程序設計是對演算法的封裝。」後來再有學生遇到了這個問題,只簡單的一句對答,對方就對這個學生就刮目相看了(學生後來自豪地告訴我的)。為什麼那?因為只有經過徹底的體會和實踐才能提煉出這個精華。
面向對象的設計方法和思想,其實早在70年代初就已經被提出來了。其目的就是:強製程序必須通過函數的方式來操縱數據。這樣實現了數據的封裝,就避免了以前設計方法中的,任何代碼都可以隨便操作數據而因起的BUG,而查找修改這個BUG是非常困難的。那麼你可以說,即使我不使用面向對象,當我想訪問某個數據的時候,我就通過調用函數訪問不就可以了嗎?是的,的確可以,但並不是強制的。人都有惰性,當我想對 i 加1的時候,干嗎非要調用函數呀?算了,直接i++多省事呀。呵呵,正式由於這個懶惰,當程序出BUG的時候,可就不好捉啦。而面向對象是強制性的,從編譯階段就解決了你懶惰的問題。
巧合的是,面向對象的思想,其實和我們的日常生活中處理問題是吻合的。舉例來說,我打算丟掉一個茶杯,怎麼扔那?太簡單了,拿起茶杯,走到垃圾桶,扔!注意分析這個過程,我們是先選一個「對象」------茶杯,然後向這個對象施加一個動作——扔。每個對象所能施加在它上面的動作是有一定限制的:茶杯,可以被扔,可以被砸,可以用來喝水,可以敲它發出聲音......;一張紙,可以被寫字,可以撕,可以燒......。也就是說,一旦確定了一個對象,則方法也就跟著確定了。我們的日常生活就是如此。但是,大家回想一下我們程序設計和對計算機的操作,卻不是這樣的。拿DOS的操作來說,我要刪除一個文件,方法是在DOS提示符下:c:> del 文件名<回車>。注意看這個過程,動作在前(del),對象在後(文件名),和面向對象的方法正好順序相反。那麼只是一個順序的問題,會帶來什麼影響那?呵呵,大家一定看到過這個現象:File not found. 「啊~~~,我錯了,我錯了,文件名敲錯了一個字母」,於是重新輸入:c:> del 文件名2<回車>。不幸又發生了,計算機報告:File read only. 哈哈,痛苦吧:)。所以DOS的操作其實是違反我們日常生活中的習慣的(當然,以前誰也沒有提出過異議),而現在由於使用了面向對象的設計,那麼這些問題,就在編譯的時候解決了,而不是在運行的時候。obj.fun(),對於這條語句,無論是對象,還是函數,如果你輸入有問題,那麼都會在編譯的時候報告出來,方便你修改,而不是在執行的時候出錯,害的你到處去捉蟲子。
同時,面向對象又能解決代碼重用的問題——繼承。我以前寫了一個「狗」的類,屬性有(變數):有毛、4條腿、有翹著的尾巴(耷拉著尾巴的那是狼)、鼻子很靈敏、喜歡吃肉骨頭......方法有(函數):能跑、能聞、汪汪叫......如果它去抓耗子,人家叫它「多管閑事」。好了,狗這個類寫好了。但在我實際的生活中,我家養的這條狗和我以前寫的這個「狗類」非常相似,只有一點點的不同,就是我的這條狗,它是:捲毛而且長長的,鼻子小,嘴小......。於是,我派生一個新的類型,叫「哈巴狗類」在「狗類」的基礎上,加上新的特性。好了,程序寫完了,並且是重用了以前的正確的代碼——這就是面向對象程序設計的好處。我的成功只是站在了巨人的肩膀上。當然,如果你使用VC的話,重用最多的代碼就是MFC的類庫。