其他

好代碼、壞代碼之三7．安全執行緒很重要安全執行緒是重要的，在資料共用或同步的場合應將安全執行緒作為必須考慮的因素，不安全的代碼將在多線程運行時造成嚴重的問題。例如，單例模式就是這樣一個需要特別注意的例子：public sealed class Singleton{    Singleton() { }     public static Singleton Instance    {        get        {            if (instance == null)    

從此重構設計是如此重要，那麼開發人員的基本設計能力與素質又從何下手來培養呢？最好的辦法，就是請個老師。從架構中瞭解，從系統中實現，從書文中汲取。然而，設計能力的提升絕非一朝一夕之功，軟體開發中的設計大師，往往必須具備多年的修行方可稱之為“架構師”。一個在簡曆中輕描淡寫的“10年軟體設計經驗”，並非是所有軟體人都能修鍊成的真功夫，這裡沒有任何虛情假意可言。在一個項目的實現過程中，逐漸瞭解什麼是對象、什麼是對抽象編程、設計模式是如何應用在實際的系統架構、設計原則到底是什麼秘密武器，而重要的是完成一個

好代碼、壞代碼之四9．擴充無處不在擴充性是衡量一個軟體產品的重要尺度之一。通過合適的設計為軟體系統賦予一定程度的擴充，是架構師著手設計的重要考慮因素，3-16所示。擴充是個大課題，涉及軟體系統的方方面面，依賴於粒度不同的架構格局。舉例來說，資料庫設計可以考慮在橫向或縱向的擴充、在多層架構中實現可適配的資料層、為業務層實現注入邏輯設計、在UI層提供可配置的介面選擇以及為物理架構提供橫向擴充的部署設計。實現基於服務的系統，就意味著在服務層支援擴充良好的高層架構；而一個面向介面的設計，將是為擴充提供可

初始化遊戲狀態資料為了初始化遊戲狀態，程式需要建立一個Piece[][]數組，為此程式定義一個AbstractBoard抽象類別，該抽象類別的代碼如下。程式清單：codes\18\Link\src\org\crazyit\link\board\AbstractBoard.javapublic abstract class AbstractBoard{    //定義一個抽象方法, 讓子類去實現    protected abstract List<Piece>

模式的起點¡ Factory 方法（FactoryMethod Pattern）模式起點：將程式中建立對象的操作單獨進行處理，大大提高了系統擴充的柔性，介面的抽象化處理給相互依賴的對象建立提供了最好的抽象模式。典型應用：Factory

初始化遊戲狀態資料下面為該AbstractBoard實現3個子類。1．矩陣排列的方塊矩陣排列的方塊會填滿二維數組的每個數組元素，只是把四周留空即可，該子類的代碼如下。程式清單：codes\18\Link\src\org\crazyit\link\board\impl\FullBoard.javapublic class FullBoard extendsAbstractBoard{    @Override    protectedList<Piece>

對象建立的依賴關於依賴的哲學，最典型的違反莫過於對象建立的依賴。自物件導向的大旗樹立以來，對於對象建立話題的討論就從未停止。不管是原廠模式還是依賴注入，其核心的思想就只有一個：如何更好地解耦對象建立的依賴關係。所以，在這一部分，我們就以對象建立為主線，來認識對於依賴關係的設計軌跡，分別論述一般的對象建立、工廠方式建立和依賴注入建立三種方式的實現、特點和區別。1．典型的違反一般而言，以new關鍵字進行對象建立，在.NET世界裡是天經地義的事情。在本書7.1節“把new說透”中，就比較透徹地分析了n

定界分割在資料到期化處理中的應用在海量資料的資料庫設計中，可能需要提前考慮資料庫中資料存放區的時間問題，或者叫做資料的到期化問題，它的意思是，由於資料量太大，在資料庫中只保留特定時間長度的資料，比如1年，1年前的資料就需要做到期化（歸檔化）處理。這時候定界分割就能發揮非常好的作用，就像上面的例子一樣，我們可以將表做成每月1個分區，超過1年的分區可以按照使用者的需求來進行處理。對於到期的資料，通常有以下幾種處理方式。1．刪除處理曆史資料的方式相當簡單，直接刪除到期的分區以及分區上的資料（如果每個分

解構控制反轉（IoC）和依賴注入（DI）1．控制反轉控制反轉（Inversion ofControl，IoC），簡言之就是代碼的控制器交由系統控制，而不是在代碼內部，通過IoC，消除組件或者模組間的直接依賴，使得軟體系統的開發更具柔性和擴充性。控制反轉的典型應用體現在架構系統的設計上，是架構系統的基本特徵，不管是.NET Framework抑或是Java

英特爾是個可以講理的地兒“Logo Queen冶,是大家送給我的外號,我喜歡這個外號,因為以我多年的經驗,一段廣告放出來,我閉著眼睛聽就能知道是哪一家IT 廠商的廣告,而且知道Intel inside 那段音樂植入時間是否有3 秒。所以,對這個外號,我認為自己的確名副其實。·你就努力撲騰吧·我是2000 年11 月15 日加入英特爾的,至今已在內部換過三次崗位[1]

設計由何而來設計，從何而來？是需求。是重構。設計原則是系統設計的靈魂，而設計模式是系統開發的模板，靈活自如的應用才是設計以不變應萬變的準則。例如，實現一個使用者註冊的方法，首先會想到：//初次設計    public void Register(string name,Int32

處理方塊之間的連接線LinkInfo是一個非常簡單的工具類，它用於封裝兩個方塊之間的串連資訊——其實就是封裝一個List，List裡儲存了連接線需要經過的點。在實現LinkInfo對象之前，先來分析兩個方塊可以相連的情形。連連看遊戲的規則約定：兩個方塊之間最多隻能用3條線段相連，也就是說最多隻能有2個“拐點”，加上兩個方塊的中心，方塊的串連資訊最多隻需要4個連接點。圖18.5顯示了允許出現的串連情況。考慮到LinkInfo最多需要封裝4個連接點，最少需要封裝2個連接點，因此程式定義如下LinkI

關於抽象和具體什麼是抽象呢？首先不必澄清什麼是抽象，而從什麼算抽象說起，穩定的、高層的就代表了抽象。就像一個公司，最好保證了高層的穩定，才能保證全域的發展。在進行系統設計時，穩定的抽象介面和高層邏輯，也代表了整個系統的穩定與柔性。兵熊熊一窩，將良良一窩，軟體的構建也正如打仗，良好的設計都是自上而下的。而對具體的編程實踐而言，介面和抽象類別則代表了語言層次的抽象。追溯概念的分析，一一過招，首先來看依賴於具體，3-3所示。因此，為了分離這種緊耦合，最好的辦法就是隔離，引入中介層來分離變化，同時確保中

好代碼、壞代碼之一1．命名很重要，讓代碼告訴你它自己命名到底有多重要呢？重要到這幾乎是很多軟體項目成功或者失敗的“罪魁禍首”，究其原因，代碼不光支撐了0和1在電腦系統中啟動並執行商務邏輯，同時也是開發人員進行交流與研究的標準語言。沒有意義或者有歧義的命名，就像兩個等待交流的人，面對了一堆火星文無從下口，讓交流變成災難，也就導致很多問題。同時，好的命名是自說明的，讓代碼告訴開發人員“我是誰，我做什麼，我怎麼做”。當然，除了靜態式的必要的注釋說明之外，動態式的代碼也可以包含傳遞資訊的作用，讓代碼告訴

牢記將iPhone特色硬體優勢發揮到極致我們剛剛詳細介紹了iPhone的特徵要素以及各個裝置的功能，現在試著從這兩個方面來探討一下iPhone的本質。通過這些包含各種各樣要素的智能手機的平台，筆者認為，我們在分析其潛力時不能僅僅用“加法”的眼光去看待它，還要用“乘法”的眼光。要更真切地理解這些，可以從AppStore中下載幾個免費試用的應用程式到自己的手機上試試。這裡介紹幾個應用程式的例子。接觸過iPad或者iPhone

什麼是依賴，什麼是抽象1．關於依賴和耦合：從小國寡民到和諧社會在老子的“小國寡民”論中，提出了一種理想的社會狀態：鄰國相望，雞犬之聲相聞，民至老死，不相往來。這是他老人家的一種社會理想，老死不相往來的人群呈現了一片和諧景象。因為不發生瓜葛，也就無所謂關聯，進而無法導致衝突。這是先祖哲學中的至純哲理，但理想的大同總是和現實的生態有著或多或少的差距，人類社會無法避免聯絡的發生，所以小國寡民的理想成為一種美麗的夢想，不可實現。同樣的道理，映射到軟體“社會”中，也就是軟體系統結構中，也預示著不同的層次、

五年,我兩次被跳槽如今,我進入英特爾已經五年了。這五年裡,我經曆了三次崗位轉換,每次轉換都是被上司推薦到更合適和更高階的職位上去,可謂是“被跳槽冶。我知道,在英特爾,我的經曆絕不是個案,但對於我過去的經曆來說,這樣的遭遇,幾乎可以用“驚豔冶來形容———兩次轉崗,都是自己的老闆推動我挑戰自己,成就真我。“屈尊冶修電腦的首席工程師黃波·在亞太地區研發中心工作,經曆了許多難忘的事情。有一件關於黃波的小事是不得不提的。黃波何許人也?

分散式資料庫的優越性從圖12-1中可以看到，使用者可以通過任何一個資料庫訪問所有3個資料庫中的資料，而不必同時去串連3個資料庫。 分散式資料庫和資料複製型資料庫有一些關係，就是資料庫之間有關聯和相互資料訪問，但是它們的功能和目的是不同的，區別也確實顯而易見。就像前面說的那樣，分散式資料庫強調資料的分布儲存，在一個純粹的分散式資料庫中，在所有的資料庫上，一種資料可能只有一份。而資料複製型資料庫強調的是資料複製，通常是把一些資料庫的資料向一個中樞資料庫中彙集。一般來說，資料複製型資料庫的目的是提高本

好代碼、壞代碼之二4．多注釋，少廢話代碼，一定是給人看的，而代碼本身的邏輯又決定於方法、類型和依賴的關係之中，所以，必要的注釋，是必需且必要的。通過注釋的進一步解釋，來輔助性地告知代碼的邏輯、演算法或者流程，不僅是好習慣，更是好代碼。另一方面，注釋不是“無病呻吟”，沒有必要表述那些顯而易見的邏輯或者說明，同時注意區分單行注釋和多行注釋的應用。在.NET平台下，XML格式的注釋還肩負了另一項重要的使命，那就是根據注釋產生代碼文檔。例如：/// <summary>/// 根據使用者資訊，

分散式資料庫的字元集在分散式資料庫中，還有一個問題經常容易被忽略，那就是資料庫字元集。由於分散式資料庫中涉及多個資料庫的資料操作，所以保證資料庫間的字元集一致（或按照業務需求的相容），顯得非常重要。通常來說，將所有資料庫字元集設定為相同的是最簡單和安全的方式。但如果涉及在分散式資料庫中，不同的資料庫儲存有不同字元的資料，比如有簡體中文、繁體中文、日語等，當出現這樣的問題時，就要仔細考慮各個資料庫的字元集問題了。關於字元集的設定，Oracle官方推薦12-3所示的做法。 它的原則是：●