引用透明性

① 什麼是 RMI / IIOP 協議

RMI定義了一組遠程介面，可以用於生成遠程對象。客戶機可以象調用本地對象的方法一樣用相同的語法調用遠程對象。RMI API提供的類和方法可以處理所有訪問遠程方法的基礎通信和參數引用要求的串列化。

遠程方法調用類似於Sun公司1985年提出的遠程過程調用（RPC）特徵。RPC也要求串列化參數和返回數值數據，但由於沒有涉及對象，情況比較簡單。Sun開發了外部數據表示（XDR）系統，支持數據串列化。RPC和RMI之間的一個重要差別是RPC用快速而不夠可靠的UDP協議，RMI用低速而可靠的TCP/IP協議。

遠程方法調用（RMI）和CORBA都是分布式計算技術，在進行分布式時各有其優缺點，為了有助於了解RMI的特點和用途，有必要討論一下CORBA和RMI的區別。

CORBA（Common Object Request Broker Architecture）是OMG的Object Management Architecture（對象管理結構），它是面向對象的分布式系統建立所依據的標准。CORBA被設計成一個能供所有編程語言使用的一個開放性說明，就是說一個機器上的Java客戶可以要求另一個用SmallTalk或C++的機器服務。正是由於這種語言的獨立性使得CORBA這么靈活和吸引人。為了適應語言獨立性，CORBA採用了非常通用的標准作為其介面。在不同的語言中，遠程調用、簽名和對象的引入有各自不同的定義，所以CORBA必須盡可能的中立和開放。正是這種通用性是CORBA的一個弱點。當開發人員都採用CORBA時，他們要用一種新的標準定義語言介面，它要求開發者學習新的編程介面，從而減小了遠程模型的透明性。

RMI是為僅在Java對Java的分布式計算中而開發的。遠程調用的標準是為了Java和應用Java的自然Java簽名和調用而開發的，這使得RMI對Java的開發者相當透明而且易於實現。RMI用Java語言緊密集成從而同CORBA相比能夠提供非常好的容錯能力及對異常的處理。盡管Java的RMI標准不像CORBA那樣語言獨立，但Java本身是一個獨立的平台，這就使RMI在跨平台的分布軟體開發中是一個很好的選擇。

IIOP
它是一個用於CORBA 2.0及兼容平台上的協議。這個協議的最初階段是要建立以下幾個組件部分：一個IIOP到HTTP的網關，使用這個網關可以讓CORBA客戶訪問WWW資源；一個HTTP到IIOP的網關，通過這個網關可以訪問CORBA資源；一個為IIOP和HTTP提供資源的伺服器，一個能夠將IIOP作為可識別協議的瀏覽器。

② 增量式開發的優點

進展的可見性
利用增量式開發，每一步增量實現了一個或多個最終用戶功能。每一步增量包含所有早期的已開發的功能集加上一些新的功能；系統在逐步累積的增量中增長。例如，在早期增量結束時，開發者很有信心地說：系統的20%已100%完成了，而不是推測系統已完成了20%。
智能控制
增量式開發通過引用透明性，實現了整個系統開發過程中的智能控制。當在後續增量待實現的函數的子規范被嵌入當前增量流程邏輯中時，這種特性，即等式的等量替換令人滿意。當擁有引用透明性時，一個系統的部件無需回溯就能根據其子規范得以實現。無需重做前期增量。這里策略有利於在一個完整系統中對每個增量進行正確性驗證。
增量系統集成
凈室增量式開發允許在整修開發生命期引用透明的用戶函數增量的連續集成。因為每一步增量設計基於一個已驗證的子規范和前期增量已測試的介面，因此幾乎沒有更深的設計和介面錯誤。較好的定義增量貫穿於整修系統開發過程，系統在良好定義的增量中深化。測試和驗證工作始於開發周期早期。
連續質量反饋貫穿統計過程式控制制
已在凈室中實踐的增量式開發為統計過程式控制制提供了基礎。每一個凈室增量都是過程的一個完整周期，包含規范、開發和新的用戶函數的驗證，加上到目前為止所有已工作的測試。作為統計過程式控制制的典型，把過程的每一次反復的性能度量與性能目標相比較，以決定是否過程一直在控制之下(即：是否正如所期望的那樣發生)。
凈室軟體小組常使用在測試中的開發性能度量作為過程式控制制的標准。通常使用的度量包括每千行代碼的錯誤數、失效的間隔時間(MTTF)、可靠性及可信性。其他過程式控制制方法或許依賴於所管理的事務，而不是產品的質量。進度一致性一、預算一致性瑟整體計劃的一致性等等，都是按增量的實際性能與目標性能相比較而言。凈室增量度量依據的標准描述了過程式控制制的具體級別，要按計劃繼續該項目，開發小組要求此級別。如果標准不符合，開發小組能從增量中檢測執行數據，確定問題所在，必要時調整項目計劃，修改軟體開發過程，避免此類問題的再次發生。例如，如果增量的測試提示過程失去控制(如：質量標准不符合)，開發者們應停止測試，返回設計階段，如果過程是在控制之下，下一歨增量工作才能繼續。
統計過程式控制制(Statistical Process Control ,SPC)是為數據悼念和分析提供較好的開發技術的成熟的工程實踐。豐富的方法和工具支持是希望從事更高實踐的設計者可利用的。然而，SPC的基本實踐要求少量的投資和努力就能產生充足的回報。統計過程式控制制應用的基本任務很簡單：每一過程周期的性能度量，比較實際性能與預先定義的目標性能，確定不可接受偏差的原因，以及通過過程改變改進將來的性能。
例如，如果一個凈室小組開發的一個產品在測試中習慣於每千行代碼有三個或更少失效，那麼一個增量每千行有5個失效或許認為是不可接收的偏差。在調查中，小組或許發現失效是由錯誤引起的，實際上在驗證過程中錯誤才能被發現，不能證實代碼改變的正確性。從這種分析中，小組認識到直到所有錯誤代碼的改變被驗證為正確之前這種驗證不視為完整的。小組相應地修改驗證過程，決心在將來的增量設計中避免因不正確的補丁而引起的失效。以這種方式，每步增量中產生的反饋用於改進下一歨增量過程。
統計過程式控制制的能力取決於針對正在進行的計劃性能與實際性能的對比檢驗。確定造成不可接受的偏差的原因，制定專門過程改進措施，以重新獲得控制或改善控制。凈室軟體小組實踐這些基本原理，並加以發展。每個凈室增量都是針對完善的期望來測試，任何失效都被認為是不可接受的。仔細分析由錯誤發生的失效與開發過程的關系，錯誤的來源是什麼？為什麼在小組評審中錯誤被忽視？如何改進過程避免相同錯誤站起來重犯？凈室軟體小組真誠地追求完美，統計過程式控制制是衡量和提高小組成果的工程規范。
用戶使用中不斷的功能反饋
增量式開發有助於用戶對一個進貨系統的執行功能做出盡早的不斷的反饋，必要時允許改變。因為增量執行於系統環境並代表了用戶功能的子集，早期的增量能通過用戶對系統功能性和實用性的檢測來反饋。這種反饋有助於避免開發出失效的系統和建立用戶可接受的最終產品。
變更的適應性
在系統需求和項目環境中增量式開發允許不可避免變更的系統適應性。在每一步增量完成時，系統需求的積累變更所產生的影響能根據當前規范和增量設計來評估。如果變更與將來增量想到獨立，則通常與現已存在的增量開發計劃相合並，並對進度和資源進行可能的調整。如果變更影響已完成的增量，自頂向下修改系統開發，通常重用絕大多數已存在的增量代碼(通常是全部)，按照要求的進度和資源來進行相應調整。
進度與資源管理
項目資源在增量式開發全過程中能在可控制的方式下分配。可用進度是決定待開發的增量數據和其規模的一個因素。在短進度中，小規模增量將有助於在增量交付與認證組之間維持充分的時間段，允許一個有序的測試過程。然而，這將給項目開發小組設計和實現更大、更復雜的增量帶來更多負擔。進度和復雜性的折衷能夠反映增量式開發計劃。另外，從後續增量得到的反饋，為過程和產品性能的目標度量提供了管理，以允許在開發和測試中對不足和意外收獲的適應。

③ 為什麼主函數和中斷函數不能調用同一函數

中斷服務函數ISR不被任何函數調用，ISR和main可以看作是並行發生的。

函數式編程：
函數式編程是種編程典範，它將電腦運算視為函數的計算。函數編程語言最重要的基礎是 λ 演算（lambda calculus）。而且λ演算的函數可以接受函數當作輸入（參數）和輸出（返回值）。和指令式編程相比，函數式編程強調函數的計算比指令的執行重要。和過程化編程相比，函數式編程里，函數的計算可隨時調用。
在經常被引用的論文 「Why Functional Programming Matters」（請參閱 參考資料） 中，作者 John Hughes 說明了模塊化是成功編程的關鍵，而函數編程可以極大地改進模塊化。在函數編程中，編程人員有一個天然框架用來開發更小的、更簡單的和更一般化的模塊， 然後將它們組合在一起。函數編程的一些基本特點包括：
支持閉包和高階函數，支持惰性計算（lazy evaluation）。使用遞歸作為控制流程的機制。加強了引用透明性。沒有副作用。我將重點放在在 Java 語言中使用閉包和高階函數上，但是首先對上面列出的所有特點做一個概述。
閉包和高階函數：
函數編程支持函數作為第一類對象，有時稱為 閉包或者 仿函數（functor）對象。實質上，閉包是起函數的作用並可以像對象一樣操作的對象。與此類似，FP 語言支持 高階函數。高階函數可以用另一個函數（間接地，用一個表達式） 作為其輸入參數，在某些情況下，它甚至返回一個函數作為其輸出參數。這兩種結構結合在一起使得可以用優雅的方式進行模塊化編程，這是使用 FP 的最大好處。
惰性計算：
除了高階函數和仿函數（或閉包）的概念，FP 還引入了惰性計算的概念。在惰性計算中，表達式不是在綁定到變數時立即計算，而是在求值程序需要產生表達式的值時進行計算。延遲的計算使您可以編寫可能潛在地生成無窮輸出的函數。因為不會計算多於程序的其餘部分所需要的值，所以不需要擔心由無窮計算所導致的 out-of-memory 錯誤。一個惰性計算的例子是生成無窮 Fibonacci 列表的函數，但是對 第 n 個Fibonacci 數的計算相當於只是從可能的無窮列表中提取一項。
遞歸：
FP 還有一個特點是用遞歸做為控制流程的機制。例如，Lisp 處理的列表定義為在頭元素後面有子列表，這種表示法使得它自己自然地對更小的子列表不斷遞歸。
引用透明性：
函數程序通常還加強引用透明性，即如果提供同樣的輸入，那麼函數總是返回同樣的結果。就是說，表達式的值不依賴於可以改變值的全局狀態。這使您可以從形式上推斷程序行為，因為表達式的意義只取決於其子表達式而不是計算順序或者其他表達式的副作用。這有助於驗證正確性、簡化演算法，甚至有助於找出優化它的方法。
副作用：
副作用是修改系統狀態的語言結構。因為 FP 語言不包含任何賦值語句，變數值一旦被指派就永遠不會改變。而且，調用函數只會計算出結果 ── 不會出現其他效果。因此，FP 語言沒有副作用