《你必須知道的.net》支援**
|anytao技術部落格
anytao
anytao.com
，原創作品，轉貼請註明作者和出處。
1 引言
話書兩回[第一回：設計，應該多一點]和[第二回：物件的旅行---物件和人，兩個世界，一樣情懷
]，作者欲言又止，吊起胃口又玩起了捉迷藏。挑起設計與架構之話題，誰料半道殺出程咬金[《你必須知道的.net》]，招致[從設計到架構系列]的中道擱淺。不過，擱淺不代表停止，中道不意味絆倒，而是期待更多。以設計為話題來把玩，對任何人來說都有點沉甸甸的分量，所以限於作者的一點點花拳繡腿，只能說點到一切玄機的皮毛。而更多的期待，則是丟擲問題和一點淺見，迎來無數的磚頭，由更多的大牛敲打、點綴、重構，形成乙個真正稱得上設計的架構。
zhuangbility
對設計來說，或許永遠沒有唯一的答案，你只能無限的接近最好。
2 回顧
時隔已久，有必要將本系列前面的內容做個簡單的回顧。在[第一回：設計，應該多一點]裡首次提出了對於設計的理解，提倡更多的人來了解技術世界中最具吸引力和持久力的元素，高舉設計與架構的大旗來充當門面，小試牛刀；而在[第二回：物件的旅行---物件和人，兩個世界，一樣情懷
]中，通過乙個有趣的對比，將物件的體驗和人生的品味湊到一起進行「非議」，可以說來了一次非正常的物件旅行。
3 設計從由何而來？
設計，從何而來？是需求。是重構。
設計原則是系統設計的靈魂，而設計模式是系統開發的模板，靈活自如的應用才是設計以不變應萬變的準則。例如，假如實現乙個使用者註冊的方法，你首先想到的可能是：
//初次設計
public
void
registryuser(
string
name, int32 age)
在一定的需求條件下，這個方法已經能夠經受系統的考驗，安全而平穩的向資料庫中不斷插入新的使用者資訊。然而，當需求發生變化時，你可能不得不對此做出調整，而我們就將調整稱為重構。但是重構遠不是擴充，而是設計。例如，現在的註冊項發生了變化，還需要同時註冊性別、**，沒有設計的調整，就被實現為：
//需求變更
public
void
registryuser(
string
name, int32 age,
bool
***, int32 phone)
通過過載方式，一定程度上解決了這一問題，然而這種不能稱為重構的調整，至少存在以下的弊端：
僵化的調整失去了設計靈魂的靈活性，沒有思考的程式只能使程式的擴充套件和維護變得不可收拾，其實對於上述問題，只需要進行簡單的重構，就可輕鬆避免上述3個弊端，實現更加柔性的系統。例如，我們的重構如下：
public
class
userinfo
public
int32 age
public
bool
*** }
通過將使用者資訊封裝為乙個類，實現了更加簡單的引數列表，同時其帶來的好處還遠不止避免了3個缺陷，而且能帶來對使用者資訊的封裝，實現更可靠的資訊隱藏和暴露： //
定義可讀可寫屬性
public
string
mobile
//定義唯讀屬性
public
string
password
private
string
email;
public
string
set\.[0-9]\.[0-9]\.)|(([\w-]+\.)+))([a-za-z]|[0-9])(\]?)$";
if(regex.ismatch(value, strreg))
else}}
那麼，設計是如何實現和建立的，答案就是物件導向。正如上述演化過程一樣，我們應用了物件導向中的封裝要素，完成了更加柔性的設計。在《你必須知道的.net》的第1.3節「封裝的秘密」中，就對封裝展開了詳細的**，基於例項的應用和對.net實現本質的分析，能夠更加開闊我們對於物件導向基本要素的理解。這些物件導向的思想和應用，來自於實踐，來自於重構。
4 從此，重構
設計是如此重要，那麼我們的基本設計能力與素質又從何下手來培養呢？
最好的辦法，就是請個老師。從框架中了解，從系統中實現，從書文中汲取。在我認為，設計能力的提公升絕非一朝一夕之功，這個行業中的設計大師，往往必須具備多年的修行方可稱之為「架構師」。作為涉世未深的我們，該從何下手，下面僅僅是一點淺見之論：
在設計的廣義概念裡，幾個必須的概念，是應該首先被了解和認知的，以排名不分先後的原則羅列，它們大概包括：
在《你必須知道的.net》的第一部分，以「oo大智慧型」和「oo大原則」兩章的篇幅，來分別講述關於物件導向的實現本質和思想理念，以物件導向技術在.net中的應用為起點，熟悉和領略物件導向的智慧型與原則，修煉深入.net技術的基本功，為深入理解.net的程式設計打好必備的基礎。
從某種意義上來說，本系列正是通過乙個典型簡單專案的實踐來梳理這些基本架構設計的基本概念，以例說理。在乙個專案的實現過程中，逐漸的了解什麼是物件、什麼是對抽象程式設計、設計模式是如何應用在實際的系統架構、設計原則到底是什麼秘密**，而重要的是完成乙個專案，對於更多人來說是認識一種軟體開發的科學流程。這種體驗，才是難能可貴的經驗。乙個在簡歷中輕描淡寫的「10年軟體設計經驗」，並非是所有軟體人都能修煉成的真功夫，這裡沒有任何虛情假意可言。
所以，從本文開始，從架構到設計系列將開始一段闖蕩江湖的旅程，借助的翅膀飛向天空，重要的是希望更多的朋友能在這裡進行**和交流，以乙個專案的運作為基礎來**乙個個設計與架構中的問題，以期收穫更多的共識與爭論。
5 結論：其實每個人都是食神
zhuangbility
其實每個人都是食神，其實每個人都是設計師。關鍵在於掌勺的你，是否能讓做飯的傢伙油光鋥亮。
其實，在設計的領域，你大可不必為看似高深的框架嚇倒，也不必為沒有經驗而怯場。在每個人的**生涯中，你隨時可以是食神，就像上例中通過簡單extract class重構方法，你就可以體驗一次設計師化腐朽為神奇的力量。所以，設計無處不在，架構如影隨形。而如何將三層架構、abstract factory、extract method、mvc、ocp這一竿子打不著的概念有機的、科學的、合理的體現在活生生的軟體系統中，是一種功力和經驗的體現。
作為學習者，我們還不具備在巨集觀上把握如何將上述模糊的概念進行統籌和消化，所以作為預備設計師，首先要做好的工作就是先逐個認識什麼是：三層架構、abstract factory、extract method、mvc、ocp這些概念，有了基本功之後再看著唱本騎驢走遠。
系列預告
溫故知新
[第一回：設計，應該多一點]
[第二回：物件的旅行---物件和人，兩個世界，一樣情懷]
*hot:《你必須知道的.net》
anytao.com
原創作品，轉貼請註明作者和出處，留此資訊。
this posting is provided "as is" with no warranties, and confers no rights.
設計模式 學習筆記 第三回
adapter 介面卡 模式 使用場景 已經給定了消費者和生產者，即呼叫者和被呼叫者，但是二者的藉口不統 一 不匹配，可以通過本模式，增加乙個翻譯層，將呼叫請求傳送給被呼叫者。從而，在不修改消費者和生產者的前提下，完成二者的匹配問題。有點像翻譯人員的作用和所處的位置，例如，乙個說英語的e要和乙個說中...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...
從架構到設計 第一回 設計，應該多一點
設計就像是轉魔方，你必須面面俱到。anytao開始想嘗試嘗試寫點設計的東西了，只所以有了這個 突如其來 的想法，原因其實很簡單 因為對設計 架構 分層 模式，我很陌生。因為陌生，所以接觸，因為接觸，所以隨筆。系列之構思就這麼誕生了。因此，這個系列是個方 是個雜文集，也是個見證史。我不期望能收穫多少掌...