[從設計到架構]第三回：設計的分寸

作者: Anytao 發布時間: 2008-08-16 22:38 閱讀: 1367 次推薦: 0 原文鏈接 [收藏]

1 引言

話書兩回[第一回：設計，應該多一點]和[第二回：對象的旅行---對象和人，兩個世界，一樣情懷]，作者欲言又止，吊起胃口又玩起了捉迷藏。挑起設計與架構之話題，誰料半道殺出程咬金[《你必須知道的.NET》]，招致[從設計到架構系列] 的中道擱淺。不過，擱淺不代表停止，中道不意味絆倒，而是期待更多。以設計為話題來把玩，對任何人來說都有點沉甸甸的分量，所以限于作者的一點點花拳繡腿，只能說點到一切玄機的皮毛。而更多的期待，則是拋出問題和一點淺見，迎來無數的磚頭，由更多的大牛敲打、點綴、重構，形成一個真正稱得上設計的架構。

Zhuangbility

對設計來說，或許永遠沒有唯一的答案，你只能無限的接近最好。

2 回顧

時隔已久，有必要將本系列前面的內容做個簡單的回顧。在[第一回：設計，應該多一點]里首次提出了對于設計的理解，提倡更多的人來了解技術世界中最具吸引力和持久力的元素，高舉設計與架構的大旗來充當門面，小試牛刀；而在[第二回：對象的旅行---對象和人，兩個世界，一樣情懷]中，通過一個有趣的對比，將對象的體驗和人生的品味湊到一起進行“非議”，可以說來了一次非正常的對象旅行。

小試之后，希望能夠專注更多的專題，一切就從本文開始啦:-)，那么首先應該關注的是：設計，究竟從何而來？

3 設計從由何而來？
設計，從何而來？是需求。是重構。
設計原則是系統設計的靈魂，而設計模式是系統開發的模板，靈活自如的應用才是設計以不變應萬變的準則。例如，假如實現一個用戶注冊的方法，你首先想到的可能是：

        //初次設計
        public void RegistryUser(string name, Int32 age)
        {
        }

在一定的需求條件下，這個方法已經能夠經受系統的考驗，安全而平穩的向數據庫中不斷插入新的用戶信息。然而，當需求發生變化時，你可能不得不對此做出調整，而我們就將調整稱為重構。但是重構遠不是擴充，而是設計。例如，現在的注冊項發生了變化，還需要同時注冊性別、電話，沒有設計的調整，就被實現為：

        //需求變更
        public void RegistryUser(string name, Int32 age, bool sex, Int32 phone)
        {
        }

通過重載方式，一定程度上解決了這一問題，然而這種不能稱為重構的調整，至少存在以下的弊端：

有新增的注冊信息時，還要通過不斷的重載RegistryUser方法來實現更多信息的擴展。
方法RegistryUser的參數列表實在太長了，這不是優雅的代碼實現。
需要修改系統中相關的方法調用來適應新的重載方法。

僵化的調整失去了設計靈魂的靈活性，沒有思考的程序只能使程序的擴展和維護變得不可收拾，其實對于上述問題，只需要進行簡單的重構，就可輕松避免上述3個弊端，實現更加柔性的系統。例如，我們的重構如下：

    public class UserInfo
    {

        public string Name { get; set; }
        public Int32 Age { get; set; }
        public bool Sex { get; set; }
    }

通過將用戶信息封裝為一個類，實現了更加簡單的參數列表，同時其帶來的好處還遠不止避免了3個缺陷，而且能帶來對用戶信息的封裝，實現更可靠的信息隱藏和暴露：

可以通過字段和屬性封裝，實現對于成員的只讀、可讀可寫權限的控制。.NET 3.0的自動屬性為屬性封裝實現了更為優雅的語法游戲，這些特性讓C#成為更具有吸引力的高級語言：

        //定義可讀可寫屬性
        public string Mobile { get; set; }

        //定義只讀屬性
        public string Password { get; private set; }

實現一定的邏輯封裝，例如對于電子郵件，可以檢查其合法性：

        private string email;

        public string Email
        {
            get { return email; }
            set
            {
                //string emailReg = @"\w+([-+.']\w+)*@(?!163\.)((\w+([-.]\w+)*))\.\w+([-.]\w+)*";

                string strReg = @"^([\w-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([\w-]+\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\]?)$";

                if (Regex.IsMatch(value, strReg))
                {
                    email = value;
                }
                else
                {
                    throw new InvalidCastException("No legal Email Address.");
                }

            }
        }

那么，設計是如何實現和建立的，答案就是面向對象。正如上述演化過程一樣，我們應用了面向對象中的封裝要素，完成了更加柔性的設計。在《你必須知道的.NET》的第1.3節“封裝的秘密”中，就對封裝展開了詳細的探討，基于實例的應用和對.NET實現本質的分析，能夠更加開闊我們對于面向對象基本要素的理解。這些面向對象的思想和應用，來自于實踐，來自于重構。

4 從此，重構
設計是如此重要，那么我們的基本設計能力與素質又從何下手來培養呢？
最好的辦法，就是請個老師。從框架中了解，從系統中實現，從書文中汲取。在我認為，設計能力的提升絕非一朝一夕之功，這個行業中的設計大師，往往必須具備多年的修行方可稱之為“架構師”。作為涉世未深的我們，該從何下手，下面僅僅是一點淺見之論：

在設計的廣義概念里，幾個必須的概念，是應該首先被了解和認知的，以排名不分先后的原則羅列，它們大概包括：

面向對象（Object-Oriented），關于面向對象沒有必要重復嚼舌了，《你必須知道的.NET》一書的第一章“OO大智慧”中對.NET的面向對象進行了有別于其他專著的介紹方式，除了以實例突出面向對象之思想大成，還以濃墨鋪陳了.NET是如何在底層技術上來實現繼承、多態和接口映射等機制，從而可以更加有效和深刻的把握面向對象的精髓。
面向服務（Service Oriented），SO至少是個時髦的話題，WCF伴著.NET 3.5的發布，一個一統江湖的面向服務的基礎架構橫空出世。可以想象的是，未來的分布式系統架構將變得更加柔性和統一，簡單而有效，我們也期望在本系列的隨后部分進行探討。
架構（Architecture），我理解的架構就是應用系統構建所需的基礎設施。應用程序是變化萬千的，而基礎架構是相對穩定。這正如我們基于.NET Framework來實現數以萬計的.NET應用：Windows Form Application、Web Form Application、XML Web Service等等，都體現了架構和應用的關系。.NET Framework本身就是一個基礎性架構，而經典的MFC也是一個基礎性架構。對于架構的探索和實踐，應該是每個意圖提高設計能力的人的必經之路。選擇一個或幾個典型的架構進行梳理與實踐，才能有效的了解軟件世界的龐大體系是如何和諧統一的運作。從經典框架設計中，尋找靈感，鍛煉體驗，而本系列的未來章節將為大家帶來基于Petshop三層架構的實踐體驗，通過真正的需求、設計、開發和測試，完成一次有意義的項目實踐旅程，而在這個旅程中，作者和讀者共同收獲對于設計與架構，從概念到實踐，從表面到思想的體驗。
設計原則（Design Principles），是面向對象設計程序開發的思想大成，了解面向對象，深入設計模式，則有必要深入設計原則之精髓。可以不了解全部的設計模式，但必須深入每一個設計原則。一個是內功，一個是招式，設計的第一項修煉就從內功開始。《你必須知道的.NET》第二章“OO大原則”對5大設計原則進行了一些以例說理式的實際探討和分析，幾個看似簡單的設計原則：單一職責原則、開放封閉原則、依賴倒置原則、接口隔離原則、Liskov替換原則等，5個原則貫徹了一個簡單的思想“面向抽象，松散耦合”。
設計模式（Design Pattern），23個設計模式，23個經典智慧，了解和掌握幾個重要的設計模式，是修煉面向對象招式的必經之路。無論如何，做為設計者你應該在自己心中知道什么是Abstract Factory、Iterator、Singleton、Adapter、Decorator、Observer、Façade、Template、 Command，早在一篇以推薦為性質的[必須知道的設計模式]中有過自己借鑒的歷史記錄。在博客園中，有著以設計模式為話題的光榮傳統，作為學習者我強烈的推薦TerryLee的Design Pattern系列和呂震宇的設計模式系列。

在《你必須知道的.NET》的第一部分，以“OO大智慧”和“OO大原則”兩章的篇幅，來分別講述關于面向對象的實現本質和思想理念，以面向對象技術在.NET中的應用為起點，熟悉和領略面向對象的智慧與原則，修煉深入.NET技術的基本功，為深入理解.NET的程序設計打好必備的基礎。

從某種意義上來說，本系列正是通過一個典型簡單項目的實踐來梳理這些基本架構設計的基本概念，以例說理。在一個項目的實現過程中，逐漸的了解什么是對象、什么是對抽象編程、設計模式是如何應用在實際的系統架構、設計原則到底是什么秘密武器，而重要的是完成一個項目，對于更多人來說是認識一種軟件開發的科學流程。這種體驗，才是難能可貴的經驗。一個在簡歷中輕描淡寫的“10年軟件設計經驗”，并非是所有軟件人都能修煉成的真功夫，這里沒有任何虛情假意可言。

所以，從本文開始，從架構到設計系列將開始一段闖蕩江湖的旅程，借助博客園的翅膀飛向天空，重要的是希望更多的朋友能在這里進行探討和交流，以一個項目的運作為基礎來探討一個個設計與架構中的問題，以期收獲更多的共識與爭論。

5 結論：其實每個人都是食神

我很喜歡看周星馳的電影，[食神]中的周星馳在大徹大悟之后說了句：其實每個人都是食神，引來他人不屑。不過，現實的情況卻真是如此，每個人都是食神，或者說每個人都可以是食神。軟件設計與架構，同樣如此，不經一番寒徹骨，哪得梅花撲鼻香。

Zhuangbility

其實每個人都是食神，其實每個人都是設計師。關鍵在于掌勺的你，是否能讓做飯的家伙油光锃亮。

其實，在設計的領域，你大可不必為看似高深的框架嚇倒，也不必為沒有經驗而怯場。在每個人的代碼生涯中，你隨時可以是食神，就像上例中通過簡單 Extract Class重構方法，你就可以體驗一次設計師化腐朽為神奇的力量。所以，設計無處不在，架構如影隨形。而如何將三層架構、Abstract Factory、Extract Method、MVC、OCP這一竿子打不著的概念有機的、科學的、合理的體現在活生生的軟件系統中，是一種功力和經驗的體現。

作為學習者，我們還不具備在宏觀上把握如何將上述模糊的概念進行統籌和消化，所以作為預備設計師，首先要做好的工作就是先逐個認識什么是：三層架構、Abstract Factory、Extract Method、MVC、OCP這些概念，有了基本功之后再看著唱本騎驢走遠。

系列預告

在 2008，我將集中全力對[從架構到設計]系列進行完善，從下一篇開始，我們將以實際的項目開發流程為主線，從需求開始介紹，到設計分析，再到實踐操作，完成一次設計開發的全程之旅，其中重點的應用Petshop框架給我們的分層架構概念為核心，通過不斷的設計和重構來完成一個系統的體驗。
而在這個過程中，我們會逐一分享關于設計、面向對象、設計原則、設計模式等基本概念的探討，從而能夠有效的進行循序漸進的認識旅程。
限于作者能力有限，諸多不足之處還望朋友們盡情指正，對我來說伴著從設計到架構系列，我將繼續分享自己在技術之路上的體驗和快樂。