上傳人：1***

認(rèn)證信息

認(rèn)證類型：個(gè)人認(rèn)證

認(rèn)證主體：羅**（實(shí)名認(rèn)證）

IP屬地：廣西

IP屬地：廣西 上傳時(shí)間：2024-05-07 格式：DOC 頁數(shù)：15 大?。?2KB 積分：12 舉報(bào) 版權(quán)申訴

架構(gòu)師之路(1)---面向過程和面向?qū)ο笸鯘少e收藏1、引言

機(jī)算機(jī)科學(xué)是一門應(yīng)用科學(xué)，它的知識(shí)體系是典型的倒三角結(jié)構(gòu)，所用的根底知識(shí)并不多，只是隨著應(yīng)用領(lǐng)域和方向的不同，產(chǎn)生了很多的分支，所以說編程并不是一件很困難的事情，一個(gè)高中生經(jīng)過特定的訓(xùn)練就可以做得到。但是，會(huì)編程和編好程絕對(duì)是兩碼事，同樣的程序員，有的人幾年之后成為了架構(gòu)師，有的人卻還在不停地coding，只不過ctrl-c、ctrl-v用得更加純熟了。在中國，編程人員最終的歸途無外乎兩條：一是轉(zhuǎn)向技術(shù)管理，它的終點(diǎn)是CTO；二是繼續(xù)深入，它的終點(diǎn)是首席架構(gòu)師，成為CEO的人畢竟是少數(shù)。如果你現(xiàn)在還是個(gè)普通的程序員，希望繼續(xù)在技術(shù)這條路上前進(jìn)的話，我想你還是應(yīng)該先補(bǔ)充一點(diǎn)軟件工程的思想，學(xué)習(xí)一點(diǎn)有關(guān)設(shè)計(jì)模式的知識(shí)，只有具備這些能力，你才能從整體和宏觀層面來考慮問題、分析問題和解決問題。本人Coding了很多年，中間走了不少彎路，雖然最終沒什么大成就，但總算有一些心得，很愿意把自己的一些經(jīng)驗(yàn)?zāi)贸鰜砀蠹曳窒?，這或許對(duì)你的開展有所幫助。由程序員轉(zhuǎn)為架構(gòu)師，最繞不開的概念就算是面向?qū)ο?OO)了。記得在大學(xué)的時(shí)候，我們專業(yè)開了一門課叫《面向?qū)ο蟮木幊獭?。那個(gè)時(shí)候，我們剛剛學(xué)了一門C語言，開發(fā)環(huán)境用的還是DOS下的TurboC，半點(diǎn)工程開發(fā)的經(jīng)驗(yàn)都沒有，純粹的空對(duì)空。所以，一學(xué)期下來，我始終處于一種懵懂狀態(tài)，既沒領(lǐng)會(huì)面向過程和面向?qū)ο蟮降子惺裁磪^(qū)別，也沒搞懂面向?qū)ο竽軒硎裁春锰帯?、面向過程(OP)和面向?qū)ο?OO)2.1蛋炒飯和蓋澆飯

有人這么形容OP和OO的不同：用面向過程的方法寫出來的程序是一份蛋炒飯，而用面向?qū)ο髮懗鰜淼某绦蚴且环萆w澆飯。所謂蓋澆飯，北京叫蓋飯，東北叫燴飯，廣東叫碟頭飯，就是在一碗白米飯上面澆上一份蓋菜，你喜歡什么菜，你就澆上什么菜。我覺得這個(gè)比喻還是比擬貼切的。

蛋炒飯制作的細(xì)節(jié)，我不太清楚，因?yàn)槲覜]當(dāng)過廚師，也不會(huì)做飯，但最后的一道工序肯定是把米飯和雞蛋混在一起炒勻。蓋澆飯呢，那么是把米飯和蓋菜分別做好，你如果要一份紅燒肉蓋飯呢，就給你澆一份紅燒肉；如果要一份青椒土豆蓋澆飯，就給澆一份青椒土豆絲。

蛋炒飯的好處就是入味均勻，吃起來香。如果恰巧你不愛吃雞蛋，只愛吃青菜的話，那么唯一的方法就是全部倒掉，重新做一份青菜炒飯了。蓋澆飯就沒這么多麻煩，你只需要把上面的蓋菜撥掉，更換一份蓋菜就可以了。蓋澆飯的缺點(diǎn)是入味不均，可能沒有蛋炒飯那么香。

到底是蛋炒飯好還是蓋澆飯好呢？其實(shí)這類問題都很難答復(fù)，非要比個(gè)上下上下的話，就必須設(shè)定一個(gè)場景，否那么只能說是各有所長。如果大家都不是美食家，沒那么多講究，那么從飯館角度來講的話，做蓋澆飯顯然比蛋炒飯更有優(yōu)勢，他可以組合出來任意多的組合，而且不會(huì)浪費(fèi)。2.2軟件工程

蓋澆飯的好處就是“菜”“飯”別離，從而提高了制作蓋澆飯的靈活性。飯不滿意就換飯，菜不滿意換菜。用軟件工程的專業(yè)術(shù)語就是“可維護(hù)性”比擬好，“飯”和“菜”的耦合度比擬低。蛋炒飯將“蛋”“飯”攪和在一起，想換“蛋”“飯”中任何一種都很困難，耦合度很高，以至于“可維護(hù)性”比擬差。軟件工程追求的目標(biāo)之一就是可維護(hù)性，可維護(hù)性主要表現(xiàn)在3個(gè)方面：可理解性、可測試性和可修改性。面向?qū)ο蟮暮锰幹痪褪秋@著的改善了軟件系統(tǒng)的可維護(hù)性。

面向過程(OP)和面向?qū)ο?OO)是不是就是指編碼的兩種方式呢？不是！你拿到了一個(gè)用戶需求，比方有人要找你編個(gè)軟件，你是不是需要經(jīng)過需求分析，然后進(jìn)行總體/詳細(xì)設(shè)計(jì)，最后編碼，才能最終寫出軟件，交付給用戶。這個(gè)過程是符合人類根本行為方式的：先想做什么，再想如何去做，最后才是做事情。有的同學(xué)說：“我沒按照你說的步驟做啊，我是直接編碼的”。其實(shí)，你一定會(huì)經(jīng)歷了這三個(gè)階段，只不過你潛意識(shí)里沒有分得那么清楚。對(duì)于拿到需求就編碼的人，可能編著編著，又得倒回去重新琢磨，還是免不了這些過程，

以O(shè)O為例，對(duì)應(yīng)于軟件開發(fā)的過程，OO衍生出3個(gè)概念：OOA、OOD和OOP。采用面向?qū)ο筮M(jìn)行分析的方式稱為OOA，采用面向?qū)ο筮M(jìn)行設(shè)計(jì)的方式稱為OOD，采用面向?qū)ο筮M(jìn)行編碼的方式稱為OOP。面向過程(OP)和面向?qū)ο?OO)本質(zhì)的區(qū)別在于分析方式的不同，最終導(dǎo)致了編碼方式的不同。2.3面向過程(OP)和面向?qū)ο?OO)2.3面向過程編程(OPP)和面向?qū)ο缶幊?OOP)的關(guān)系

關(guān)于面向過程的編程(OPP)和面向?qū)ο蟮木幊?OOP),給出這它們的定義的人很多，您可以從任何資料中找到很專業(yè)的解釋，但以我的經(jīng)驗(yàn)來看，講的相對(duì)枯燥一點(diǎn)，不是很直觀。除非您已經(jīng)有了相當(dāng)?shù)姆e累，否那么說起來還是比擬費(fèi)力。我是個(gè)老程序員出身，雖然現(xiàn)在的日常工作更多傾向了管理，但至今依然保持編碼的習(xí)慣，這句話什么意思呢？我跟大家溝通應(yīng)該沒有問題。無論你是在重復(fù)我走過的路，或者已經(jīng)走在了我的前面，大家都會(huì)有那么一段相同的經(jīng)歷，都會(huì)在思想層面上有一種理解和默契，所以我還是會(huì)盡量按照大多數(shù)人的常規(guī)思維寫下去。面向過程的編程(OPP)產(chǎn)生在前，面向?qū)ο蟮木幊?OOP)產(chǎn)生在后，所以面向?qū)ο蟮木幊?OOP)一定會(huì)繼承前者的一些優(yōu)點(diǎn)，并摒棄前者存在的一些缺點(diǎn)，這是符合人類進(jìn)步的自然規(guī)律。兩者在各自的開展和演變過程中，一定會(huì)相互借鑒，相互融合，吸收對(duì)方的優(yōu)點(diǎn)，從而出現(xiàn)某些方面的趨同性。但是，即使兩者有更多的相似點(diǎn)，也不會(huì)改變它們本質(zhì)上的不同，因?yàn)樗鼈兊某霭l(fā)點(diǎn)不同，完全是兩種截然不同的思維方式。關(guān)于兩者的關(guān)系，我的觀點(diǎn)是這樣的：面向?qū)ο缶幊?OOP)在局部上一定是面向過程(OP)的，面向過程的編程(OPP)在整體上應(yīng)該借鑒面向?qū)ο?OO)的思想。這一段說的確實(shí)很空洞，而且也一定會(huì)有引來爭議，不過，我勸您還是在閱讀了后面的內(nèi)容之后，再來評(píng)判我觀點(diǎn)的正確與否。象C++、C#、Java等都是面向?qū)ο蟮恼Z言，c,php(暫且這么說，因?yàn)閜hp4以后就支持OO)都是面向過程的語言，那么是不是我用C++寫的程序一定就是面向?qū)ο?，用c寫的程序一定就是面向過程呢？這種觀點(diǎn)顯然是沒有真正吃透兩者的區(qū)別。語言永遠(yuǎn)是一種工具，前輩們每創(chuàng)造出來的一種語言，都是你用來實(shí)現(xiàn)想法的利器。我覺得好多人用C#,Java寫出來的代碼，要是仔細(xì)看看，那實(shí)際就是用面向?qū)ο?OO)的語言寫的面向過程(OP)的程序。所以，即使給關(guān)羽一根木棍，給你一桿青龍偃月刀，他照樣可以打得你滿頭是包。你就是扛著個(gè)偃月刀，也成不了關(guān)羽，因?yàn)槟闳狈﹃P(guān)羽最本質(zhì)的東西---絕世武功。同樣的道理，如果你沒有領(lǐng)會(huì)OO思想，怎么可能寫得出真正的OO程序呢？那是不是面向過程就不好，也沒有存在的必要了？我從來沒有這樣說過。事實(shí)上，面向過程的編程(OPP)已經(jīng)存在了幾十年了，現(xiàn)在依然有很多人在使用。它的優(yōu)點(diǎn)就是邏輯不復(fù)雜的情況下很容易理解，而且運(yùn)行效率遠(yuǎn)高于面向?qū)ο蟆睴O〕編寫的程序。所以，系統(tǒng)級(jí)的應(yīng)用或準(zhǔn)實(shí)時(shí)系統(tǒng)中，依然采用面向過程的編程(OPP)。當(dāng)然，很多編程高手以及大師級(jí)的人物，他們由于對(duì)于系統(tǒng)整體的掌控能力很強(qiáng)，也喜歡使用面向過程的編程(OPP)，比方像Apache,QMail,PostFix,ICE等等這些比擬經(jīng)典的系統(tǒng)都是OPP的產(chǎn)物。象php這些腳本語言，主要用于web開發(fā)，對(duì)于一些業(yè)務(wù)邏輯相對(duì)簡單的系統(tǒng)，也常使用面向過程的編程(OPP)，這也是php無法跨入到企業(yè)級(jí)應(yīng)用開發(fā)的原因之一，不過php5目前已經(jīng)能夠很好的支持OO了。2.4詳解面向過程的編程(OPP)

在面向?qū)ο蟪霈F(xiàn)之前，我們采用的開發(fā)方法都是面向過程的編程(OPP)。面向過程的編程中最常用的一個(gè)分析方法是“功能分解”。我們會(huì)把用戶需求先分解成模塊，然后把模塊分解成大的功能，再把大的功能分解成小的功能，整個(gè)需求就是按照這樣的方式，最終分解成一個(gè)一個(gè)的函數(shù)。這種解決問題的方式稱為“自頂向下”，原那么是“先整體后局部”，“先大后小”，也有人喜歡使用“自下向上”的分析方式，先解決局部難點(diǎn)，逐步擴(kuò)大開來，最后組合出來整個(gè)程序。其實(shí)，這兩種方式殊路同歸，最終都能解決問題，但一般情況下采用“自頂向下”的方式還是較為常見，因?yàn)檫@種方式最容易看清問題的本質(zhì)。我舉個(gè)例子來說明面向過程的編程方式:用戶需求：老板讓我寫個(gè)通用計(jì)算器。最終用戶就是老板，我作為程序員，任務(wù)就是寫一個(gè)計(jì)算器程序。OK，很簡單，以下就是用C語言完成的計(jì)算器：假定程序的文件名為：main.c。intmain(intargc,char*argv[]){

//變量初始化

intnNum1,nNum2;

charcOpr;

intnResult;

nNum1=nNum2=0;

cOpr=0;

nResult=0;

//輸入數(shù)據(jù)

printf("Pleaseinputthefirstnumber:\r\n");

scanf("%d",&nNum1);

printf("Pleaseinputtheoperator:\r\n");

scanf("%s",&cOpr);

printf("Pleaseinputthesecondnumber:\r\n");

scanf("%d",&nNum2);

//計(jì)算結(jié)果

if(cOpr=='+'){

nResult=nNum1+nNum2;

}elseif(cOpr=='-'){

nResult=nNum1-nNum2;

}else{

printf("Unknownoperator!");

return-1;

}

//輸出結(jié)果

printf("Theresultis%d!",nResult);

return0;

}拋開細(xì)節(jié)不講，我想大多數(shù)人差不多都會(huì)這么實(shí)現(xiàn)吧，很清晰，很簡單，充分表達(dá)了“簡單就是美”的原那么，面向過程的編程就是這樣有條理的按照順序來逐步實(shí)現(xiàn)用戶需求。但凡做過程序的人都知道，用戶需求從來都不會(huì)是穩(wěn)定的，最多只能夠做到“相對(duì)穩(wěn)定”。用戶可能會(huì)隨時(shí)提出加個(gè)功能，減個(gè)功能的要求，也可能會(huì)要求改動(dòng)一下流程，程序員最煩的就是頻繁地變動(dòng)需求，尤其是程序已經(jīng)寫了大半了，但這種情況是永遠(yuǎn)無法防止的，也不能完全歸罪到客戶或者需求分析師。以我們上面的代碼為例，用戶可能會(huì)提出類似的要求：

首先，你程序中實(shí)現(xiàn)了“加法”和“減法”，我還想讓它也能計(jì)算“乘法”、“除法”。

其次，你現(xiàn)在的人機(jī)界面太簡單了，我還想要個(gè)Windows計(jì)算器的界面或者M(jìn)ac計(jì)算器的界面。用戶需求開始多了，我得琢磨琢磨該如何去寫這段代碼了。我今天加了“乘”“除”的運(yùn)算，明天保不齊又得讓我加個(gè)“平方”、“立方”的運(yùn)算，這要是把所有的運(yùn)算都窮盡了，怎么也得寫個(gè)千八百行代碼吧。還有，用戶要求界面能夠更換，還得寫一大堆界面生成的代碼，又得來個(gè)千八百行。以后，這么多代碼堆在一起，怎么去維護(hù)，找個(gè)變量得半天，看懂了代碼得半天，萬一不小心改錯(cuò)了，還得調(diào)半天。另外，界面設(shè)計(jì)我也不擅長，得找個(gè)更專業(yè)的人來做，做完了之后再加進(jìn)來吧。這個(gè)過程也就是“軟件危機(jī)”產(chǎn)生的過程。伴隨著軟件廣泛地應(yīng)用于各個(gè)領(lǐng)域，軟件開發(fā)的規(guī)模變得越來越大，復(fù)雜度越來越高，而其用戶的需求越來越不穩(wěn)定。根據(jù)用戶提出的兩個(gè)需求，面向過程的編程該如何去應(yīng)對(duì)呢？我想大家都很清楚怎么去改。Veryeasy，把“計(jì)算”和“界面”分開做成兩個(gè)獨(dú)立的函數(shù)，封裝到不同的文件中。

假定程序的文件名為：main.c。#include"interface.h"

#include"calculate.h"

intmain(intargc,char*argv[]){

//變量初始化

intnNum1,nNum2;

charcOpr;

intnResult;

nNum1=nNum2=0;

cOpr=0;

nResult=0;

//輸入數(shù)據(jù)

if(getParameters(&nNum1,&nNum2,&cOpr)==-1)

return-1;

//計(jì)算結(jié)果

if(calcMachine(nNum1,nNum2,cOpr,&nResult)==-1)

return-1;

//輸出結(jié)果

printf("Theresultis%d!",nResult);

return0;

}interface.h:

intgetParameters(int*nNum1,int*nNum2,char*cOpr);interface.c:

intgetParameters(int*nNum1,int*nNum2,char*cOpr){

printf("Pleaseinputthefirstnumber:\r\n");

scanf("%d",nNum1);

printf("Pleaseinputtheoperator:\r\n");

scanf("%s",cOpr);

printf("Pleaseinputthesecondnumber:\r\n");

scanf("%d",nNum2);

return0;

}calculate.h:

intcalcMachine(intnNum1,intnNum2,charcOpr,int*nResult);calculate.c:

intcalcMachine(intnNum1,intnNum2,charcOpr,int*nResult){

if(cOpr=='+'){

*nResult=nNum1+nNum2;

}elseif(cOpr=='-'){

*nResult=nNum1-nNum2;

}else{

printf("Unknownoperator!");

return-1;

};

return0;

}“計(jì)算”和“界面”分開之后，添加新功能或者修改bug就方便多了，遇到與“計(jì)算”相關(guān)的需求就去修改calculate模塊，遇到與“界面”相關(guān)的需求就去修改interface模塊，因此，整個(gè)系統(tǒng)模塊之間的“耦合度”就被放松了，可維護(hù)性有了一定程度的改善。面向過程的編程(OPP)就是將用戶需求進(jìn)行“功能分解”。把用戶需求先分解成模塊(.h,.c)，再把模塊(.h,.c)分解成大的功能(function)，然后把大的功能(function)分解成小的功能(function)，如此類推。功能分解是一項(xiàng)很有技術(shù)含量的工作，它不僅需要分解者具有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，而且需要科學(xué)的理論作為指導(dǎo)。如何分解，分解原那么是什么，模塊粒度多大適宜？這些都是架構(gòu)師的要考慮的問題，也是我們后面要著重講的內(nèi)容。面向過程的編程(OPP)優(yōu)點(diǎn)是程序順序執(zhí)行，流程清晰明了。它的缺點(diǎn)是主控程序承當(dāng)了太多的任務(wù)，各個(gè)模塊都需要主控程序進(jìn)行控制和調(diào)度，主控和模塊之間的承當(dāng)?shù)娜蝿?wù)不均衡。

有的人把面向過程定義為：算法+數(shù)據(jù)結(jié)構(gòu)，我覺得也很準(zhǔn)確。面向過程的編程中算法是核心，數(shù)據(jù)處于附屬地位，數(shù)據(jù)隨算法而流動(dòng)。所以采用面向過程的方式進(jìn)行編程，一般在動(dòng)手之前，都要編寫一份流程圖或是數(shù)據(jù)流圖。

--------------------------------------------------------如果大家對(duì)本文有意見盡可爭論，歡送大家隨時(shí)拍磚。我有著鋼鐵一樣的心臟和城墻一樣的臉皮，承受能力極強(qiáng)，所以無論是支持意見還是反對(duì)反對(duì)意見，我都會(huì)認(rèn)真閱讀，只要不是色情淫穢和反動(dòng)言論，我盡量不刪貼。如果碰到不能理解或者錯(cuò)誤之處，請(qǐng)指出，我會(huì)進(jìn)行驗(yàn)證和修改。由于個(gè)人能力和時(shí)間有限，也只能寫到這樣的水平了，大家諒解。有的朋友找我的qq號(hào)，我的資料里就有，加為好友后就可以看到，我的qq對(duì)任何人開放3架構(gòu)師的職責(zé)

近來看到CSDN上有個(gè)CTO俱樂部，里面聊得是不亦樂乎。我懷著無比崇敬的態(tài)度，拜讀了一下牛人們的發(fā)言。里面有個(gè)哥們發(fā)起一個(gè)話題：“CTO,你多久沒有寫程序了？”。有人答復(fù)：“不寫代碼的CTO,屬于......這公司問題大了!”?？吹竭@里，我就趕緊撤了，怕忍不住反駁幾句，反而遭到牛人們的群毆。試想，一個(gè)上點(diǎn)規(guī)模的IT公司，還得靠CTO來寫程序的話，那是不是才叫問題大了呢。當(dāng)然，我沒有做過CTO，所以我有我的不同看法，而且還愿意表達(dá)出來，無知者無畏。我情愿相信：我所理解的CTO跟這位CTO所理解的是兩回事。所以我想，如果有人能把CTO的職責(zé)給標(biāo)準(zhǔn)化了，也許就不會(huì)有這么多的爭論了。

同樣的道理，關(guān)于架構(gòu)師的定義，大家也有著不同的理解。什么是架構(gòu)師？架構(gòu)師有哪些職責(zé)？我覺得有必要提前明確一下，要不然大家溝通起來也會(huì)產(chǎn)生類似問題，子說子理，卯說卯理，但是壓根說得不是一碼子事。3.1什么是架構(gòu)師

曾經(jīng)有這么個(gè)段子：

甲：我已經(jīng)應(yīng)聘到一家中型軟件公司了，今天上班的時(shí)候，全公司的人都來歡送我。

乙：羨慕ing，都什么人來了？

甲：CEO、COO、CTO、Allof程序員，還有會(huì)計(jì)、司機(jī)都來了。

乙：哇，他們太重視你了，人才啊，這么多人迎接你！

甲：沒有啊，就一個(gè)人！

乙：靠，#%￥$%...3.5詳解面向?qū)ο蟮木幊?OOP)什么是面向?qū)ο?/p>

剛接觸編程的時(shí)候，多數(shù)人本能的反映可能是面向過程(OP)的，而不是面向?qū)ο?OO)的。這種現(xiàn)象其實(shí)是很正常的，改變思維方式是需要一個(gè)過程的，我大體歸納了一下其形成的原因：1、直接原因

你還沒有養(yǎng)成面向?qū)ο蠓治鰡栴}和解決問題的習(xí)慣。建立面向?qū)ο蟮乃季S方式需要一定時(shí)間的訓(xùn)練和揣摩才能形成，所以你可以在學(xué)習(xí)或具體工程中刻意地強(qiáng)化這種意識(shí)。一般情況下，經(jīng)過一段時(shí)間之后，你會(huì)覺得這是自然而然的事情，只有心中OO，眼中自然OO了。2、歷史原因

我們從小接受的培訓(xùn)都是采用面向過程(OP)的方式分析問題和解決問題，尤其是數(shù)學(xué)，多數(shù)是強(qiáng)調(diào)按部就班的解決問題，計(jì)算機(jī)軟件的開展一直就與數(shù)學(xué)是很有淵源，所以，順理成章的，把面向過程(OP)的方式帶入到軟件開發(fā)也是很自然的事情。

什么是面向?qū)ο?，或者談?wù)勀銓?duì)面向?qū)ο蟮睦斫?，這恐怕是軟件開發(fā)人員，尤其是程序員和設(shè)計(jì)師應(yīng)聘的時(shí)候，面試官常最掛在嘴邊的問題吧。面向?qū)ο髮?duì)應(yīng)的英文是Object-Oriented，把Object-Oriented翻譯成“面向?qū)ο蟆?，我一直覺得這個(gè)譯法不太確切，因?yàn)槎鄶?shù)人第一次看到“面向?qū)ο蟆边@四個(gè)字，都很難從字面上理解它到底是什么意思。后來，我又查閱了一些有關(guān)的資料，發(fā)現(xiàn)港澳臺(tái)的計(jì)算機(jī)書籍中是把它翻譯成了“物件導(dǎo)向”，這個(gè)譯法，我感覺不錯(cuò)，于我心頗有些戚戚焉?！拔锛?dǎo)向”比擬準(zhǔn)確地反映了面向?qū)ο笳J(rèn)識(shí)和解決問題都是要圍繞對(duì)象展開的。

所以，面向?qū)ο蟮乃季S方式認(rèn)為：軟件系統(tǒng)是一組交互的對(duì)象的集合。一組相關(guān)的對(duì)象組合為一個(gè)子系統(tǒng)，一組子系統(tǒng)繼續(xù)組合為更復(fù)雜的子系統(tǒng)，直至組合成整個(gè)系統(tǒng)。

面向?qū)ο蠓绞降某霭l(fā)點(diǎn)是盡可能模擬人類習(xí)慣的思維方式，將“問題域”中涉及的內(nèi)容抽象為“對(duì)象”，使軟件開發(fā)的方法與過程盡可能接近人類認(rèn)識(shí)世界解決問題的方法與過程。

面向過程就是分析出解決問題所需要的步驟，然后用函數(shù)把這些步驟一步一步實(shí)現(xiàn)，使用的時(shí)候一個(gè)一個(gè)依次調(diào)用就可以了。面向?qū)ο笫前褬?gòu)成問題事務(wù)分解成各個(gè)對(duì)象，建立對(duì)象的目的不是為了完成一個(gè)步驟，而是為了描敘某個(gè)事物在整個(gè)解決問題的步驟中的行為。

面向過程認(rèn)識(shí)和解決問題的思維，可以稱為“流程論”，重點(diǎn)放在處理過程的步驟，流程是整個(gè)系統(tǒng)的核心。

面向?qū)ο笳J(rèn)識(shí)和解決問題的思維，可以稱為“組裝論”，重心放在對(duì)象的抽象和提取上，然后將對(duì)象組裝為整體。所以O(shè)O和OP從思維方式來講，出發(fā)點(diǎn)還是完全不同的。OPPKOO

咱們用象棋對(duì)戰(zhàn)的例子，來比擬OP和OO的不同：

紅方：功夫熊貓黑方：悍嬌虎裁判：龜仙人

采用面向過程(OPP)的設(shè)計(jì)思路，首先分拆整個(gè)對(duì)戰(zhàn)過程，分析雙方對(duì)戰(zhàn)的步驟，得到如下流程：

把上面每個(gè)步驟分別用函數(shù)進(jìn)行實(shí)現(xiàn)，問題就解決了。

我們?cè)賮砜纯疵嫦驅(qū)ο笫侨绾蝸斫鉀Q問題，整個(gè)象棋游戲可以抽象出3種對(duì)象：

1、棋手，負(fù)責(zé)行棋，這兩者行為一致。

2、棋盤，負(fù)責(zé)繪制棋盤畫面。

3、裁判，負(fù)責(zé)判定諸如吃子、犯規(guī)和輸贏。

三者之間的關(guān)系如下：

第一類對(duì)象棋手負(fù)責(zé)行棋，并告知第二類對(duì)象棋盤中棋子布局的變化，棋盤接收到了棋子布局的變化后，負(fù)責(zé)在繪制屏幕，同時(shí)利用第三類對(duì)象裁判來對(duì)棋局進(jìn)行判定。

從以上兩種的實(shí)現(xiàn)方式可以看出幾點(diǎn)：1、可維護(hù)性

面向?qū)ο笫且詳?shù)據(jù)和功能來劃分問題，而不是依據(jù)流程和步驟。同樣是繪制棋盤的行為，在面向過程的設(shè)計(jì)中分散在了很多的步驟中，很可能出現(xiàn)在不同的繪制版本中，只是不是很像一份“蛋炒飯”中的雞蛋？在面向?qū)ο蟮脑O(shè)計(jì)中，繪圖只可能在棋盤對(duì)象中出現(xiàn)，從而保證了繪圖的統(tǒng)一，這就是把雞蛋從“蛋炒飯”中別離出來的效果。2、可擴(kuò)展性

假設(shè)我要參加悔棋的功能，如果要改動(dòng)面向過程的設(shè)計(jì)，那么從行棋到顯示再到判定這一連串的步驟都要改動(dòng)，甚至步驟之間的循序都要進(jìn)行大規(guī)模調(diào)整。如果是面向?qū)ο蟮脑挘挥酶膭?dòng)棋盤對(duì)象就行了，棋盤對(duì)象保存了雙方的棋譜，簡單回溯，減一就可以了，而顯示和判定不涉及，同時(shí)整體對(duì)各個(gè)對(duì)象功能的調(diào)用順序都沒有變化，改動(dòng)只限定在了局部。OO的深層思考

OO認(rèn)為：軟件系統(tǒng)是一組交互的對(duì)象的集合。

因?yàn)槿祟悓?duì)現(xiàn)實(shí)世界是非常熟悉的，所以O(shè)O就是通過抽象的方式，把問題域映射到現(xiàn)實(shí)世界，盡量模擬現(xiàn)實(shí)世界的萬事萬物。通過這種方式，就可以運(yùn)用現(xiàn)實(shí)世界中解決問題的方法與過程，來解決軟件領(lǐng)域內(nèi)的問題。

有人說：OO眼里一切皆對(duì)象，這句話還是很有道理的。

OO到底給軟件開發(fā)帶來了什么樣的好處？OO的抽象的尺度是如何把握的呢？這都是問題。

很多的創(chuàng)業(yè)公司，一人身兼數(shù)職的情形還是很常見的。至少，我是經(jīng)歷過的，一個(gè)人包辦了所有的開發(fā)過程，連測試我都做了，絕對(duì)的一條龍，但是經(jīng)常踩鋼絲、騎獨(dú)輪車總會(huì)有失足的時(shí)候，結(jié)果有一次，從我手里發(fā)出去的光盤母盤，含有病毒僵尸，以至于被迫收回已經(jīng)推上市場的2萬張光盤，從那之后，我的心臟就開始變得無比堅(jiān)強(qiáng)，現(xiàn)在就是整個(gè)后臺(tái)效勞都癱瘓了，我也只是微微一笑。其實(shí)，一個(gè)人身兼架構(gòu)師和程序員，甚至多種角色，沒什么不妥，后面還會(huì)講這個(gè)話題，這種現(xiàn)象不是中國特色，跟國外是完全接軌的。我曾經(jīng)跟米國的一個(gè)工程師在msn中聊過類似的話題，發(fā)現(xiàn)他們的路子跟咱們沒什么不同，在IT這個(gè)行業(yè)，我們跟世界的差距只有1天，他們剛弄出來的新東西，我們這里第2天保準(zhǔn)見得到。

架構(gòu)師這個(gè)稱呼不是拍腦袋想出來的，是有國際標(biāo)準(zhǔn)〔ISO/IEC42010〕可查的。架構(gòu)師是軟件開發(fā)活動(dòng)中的眾多角色之一，它可能是一個(gè)人、一個(gè)小組，也可能是一個(gè)團(tuán)隊(duì)。微軟對(duì)架構(gòu)師有一個(gè)分類參考，我們參考一下，他們把架構(gòu)師分為4種：企業(yè)架構(gòu)師EA(EnterpriseArchitect)、根底結(jié)構(gòu)架構(gòu)師IA(InfrastructureArchitect)、特定技術(shù)架構(gòu)TSA(Technology-SpecificArchitect)和解決方案架構(gòu)師SA(SolutionArchitect)。微軟的這個(gè)分類是按照架構(gòu)師專注的領(lǐng)域不同而劃分的。

EA的職責(zé)是決定整個(gè)公司的技術(shù)路線和技術(shù)開展方向。蓋茨給自己的Title就是首席軟件架構(gòu)師，網(wǎng)易丁磊也喜歡這么稱呼自己，實(shí)際上就是EA角色；IA的工作就是提煉和優(yōu)化技術(shù)方面積累和沉淀形成的根底性的、公共的、可復(fù)用的框架和組件，這些都是一個(gè)技術(shù)型公司傳承下來的最珍貴的財(cái)富之一；特定技術(shù)架構(gòu)師TSA，他們主要從事類似平安架構(gòu)、存儲(chǔ)架構(gòu)等專項(xiàng)技術(shù)的規(guī)劃和設(shè)計(jì)工作；SA的工作那么專于解決方案的規(guī)劃和設(shè)計(jì)，“解決方案”這個(gè)詞在中國已經(jīng)到了嚴(yán)重泛濫的程度，大忽悠們最喜歡把它掛在嘴邊。所謂解決方案，就是把產(chǎn)品、技術(shù)或理論，不斷地進(jìn)行組合，來創(chuàng)造出滿足用戶需求的選擇。售前工程師一般都是帶著它到客戶那里去發(fā)揮的。

大公司會(huì)把各種類型的架構(gòu)師分得很清楚，小公司一般就不那么講究了，架構(gòu)師多數(shù)是是IA+TSA+SA，一人包打天下，所以說大公司出專才，小公司出全才。

實(shí)際工作中，我們也經(jīng)常會(huì)見到另一種比擬簡單的分類方式，把架構(gòu)師分為軟件架構(gòu)師和系統(tǒng)架構(gòu)師。軟件架構(gòu)師根本上是TSA+IA，這也是程序員最容易突破，最可能走上的一條道路，比方JAVA架構(gòu)師、DotNet架構(gòu)師、LAPM架構(gòu)師等等，我后面所講的內(nèi)容都是與軟件架構(gòu)師的相關(guān)的話題。系統(tǒng)架構(gòu)師實(shí)際上是SA+TSA，更著力于綜合運(yùn)用已有的產(chǎn)品和技術(shù)，來實(shí)現(xiàn)客戶期望的需求。系統(tǒng)架構(gòu)師要求通曉軟、硬件兩方面的知識(shí)，所以它的知識(shí)體系相對(duì)龐雜。關(guān)于系統(tǒng)架構(gòu)師的話題，我們可以稍后再作討論。3.2架構(gòu)師的職責(zé)架構(gòu)師需要參與工程開發(fā)的全部過程，包括需求分析、架構(gòu)設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)、集成、測試和部署各個(gè)階段，負(fù)責(zé)在整個(gè)工程中對(duì)技術(shù)活動(dòng)和技術(shù)說明進(jìn)行指導(dǎo)和協(xié)調(diào)。

架構(gòu)師主要職責(zé)有4條：1、確認(rèn)需求

在工程開發(fā)過程中，架構(gòu)師是在需求規(guī)格說明書完成后介入的，需求規(guī)格說明書必須得到架構(gòu)師的認(rèn)可。架構(gòu)師需要和分析人員反復(fù)交流，以保證自己完整并準(zhǔn)確地理解用戶需求。2、系統(tǒng)分解

依據(jù)用戶需求，架構(gòu)師將系統(tǒng)整體分解為更小的子系統(tǒng)和組件，從而形成不同的邏輯層或效勞。隨后，架構(gòu)師會(huì)確定各層的接口，層與層相互之間的關(guān)系。架構(gòu)師不僅要對(duì)整個(gè)系統(tǒng)分層，進(jìn)行“縱向”分解，還要對(duì)同一邏輯層分塊，進(jìn)行“橫向”分解。

軟件架構(gòu)師的功力根本表達(dá)于此，這是一項(xiàng)相對(duì)復(fù)雜的工作。3、技術(shù)選型

架構(gòu)師通過對(duì)系統(tǒng)的一系列的分解，最終形成了軟件的整體架構(gòu)。技術(shù)選擇主要取決于軟件架構(gòu)。

WebServer運(yùn)行在Windows上還是Linux上？數(shù)據(jù)庫采用MSSql、Oracle還是Mysql？需要不需要采用MVC或者Spring等輕量級(jí)的框架？前端采用富客戶端還是瘦客戶端方式？類似的工作，都需要在這個(gè)階段提出，并進(jìn)行評(píng)估。

架構(gòu)師對(duì)產(chǎn)品和技術(shù)的選型僅僅限于評(píng)估，沒有決定權(quán)，最終的決定權(quán)歸工程經(jīng)理。架構(gòu)師提出的技術(shù)方案為工程經(jīng)理提供了重要的參考信息，工程經(jīng)理會(huì)從工程預(yù)算、人力資源、時(shí)間進(jìn)度等實(shí)際情況進(jìn)行權(quán)衡，最終進(jìn)行確認(rèn)。4、制定技術(shù)規(guī)格說明

架構(gòu)師在工程開發(fā)過程中，是技術(shù)權(quán)威。他需要協(xié)調(diào)所有的開發(fā)人員，與開發(fā)人員一直保持溝通，始終保證開發(fā)者依照它的架構(gòu)意圖去實(shí)現(xiàn)各項(xiàng)功能。

架構(gòu)師與開發(fā)者溝通的最重要的形式是技術(shù)規(guī)格說明書，它可以是UML視圖、Word文檔，Visio文件等各種表現(xiàn)形式。通過架構(gòu)師提供的技術(shù)規(guī)格說明書，保證開發(fā)者可以從不同角度去觀察、理解各自承當(dāng)?shù)淖酉到y(tǒng)或者模塊。

架構(gòu)師不僅要保持與開發(fā)者的溝通，也需要與工程經(jīng)理、需求分析員，甚至與最終用戶保持溝通。所以，對(duì)于架構(gòu)師來講，不僅有技術(shù)方面的要求，還有人際交流方面的要求。3.3架構(gòu)師的誤區(qū)1、架構(gòu)師就是工程經(jīng)理

架構(gòu)師不是工程經(jīng)理。工程經(jīng)理側(cè)重于預(yù)算控制、時(shí)間進(jìn)度控制、人員管理、與外部聯(lián)系和協(xié)調(diào)等等工作，具備管理職能。一般小型工程中，常見工程經(jīng)理兼架構(gòu)師。2、架構(gòu)師負(fù)責(zé)需求分析

架構(gòu)師不是需求分析員。需求分析人員的工作是收集需求和分析需求，并與最終用戶、產(chǎn)品經(jīng)理保持聯(lián)系。架構(gòu)師只對(duì)最終的需求審核和確認(rèn)，提出需求不清和不完整的局部，他會(huì)跟需求分析員時(shí)刻保持聯(lián)系。架構(gòu)師是技術(shù)專家，不是業(yè)務(wù)專家。3、架構(gòu)師從來不寫代碼

這是一個(gè)尚存爭論的問題。目前有兩種觀點(diǎn)：

觀點(diǎn)1：架構(gòu)師不寫代碼，寫代碼純體力活，架構(gòu)師寫代碼大材小用。架構(gòu)師把UML的各種視圖交給開發(fā)人員，如果有不明確的地方，可以與架構(gòu)師隨時(shí)溝通。

觀點(diǎn)2：架構(gòu)師本來自于程序員，只是比程序員站的層面更高，比程序員唯一多的是經(jīng)驗(yàn)和知識(shí)，所以架構(gòu)師也免不了寫代碼。

我個(gè)人覺得這兩種說法是與架構(gòu)師的出身和所處的環(huán)境有關(guān)。

架構(gòu)師首先是一個(gè)技術(shù)角色，所以一定是來自于技術(shù)人員這個(gè)群體，比方系統(tǒng)架構(gòu)師，多是來自于運(yùn)維人員，可能本身代碼寫得并不多，或者說寫不出來很漂亮的代碼。軟件架構(gòu)師多是來自于程序員，有著程序員的血統(tǒng)和情懷，所以在工程開發(fā)過程中，可能會(huì)寫一些核心代碼。我們的理想是架構(gòu)師不用寫代碼，但事實(shí)上有時(shí)候過于理想。架構(gòu)師寫不寫代碼，可能取決于公司的規(guī)模、文化、開發(fā)人員的素質(zhì)等現(xiàn)實(shí)情況。另外，架構(gòu)師也不是跟程序員界限分得那么清楚，按照能力也有高中低之分，寫不寫代碼不是區(qū)分兩者的根本標(biāo)準(zhǔn)。3.4架構(gòu)師的根本素質(zhì)周星馳有個(gè)片子《喜劇之王》，劇中的尹天仇整天揣著本《演員的自我修養(yǎng)》，一個(gè)好演員不僅需要天賦，也需要一定的理論指導(dǎo)，無師自通的人畢竟是少數(shù)。架構(gòu)師的成長過程也是這樣。從普通程序員到高級(jí)程序員，再到架構(gòu)師，是一個(gè)經(jīng)驗(yàn)積累和思想升華的過程。經(jīng)驗(yàn)積累是一個(gè)方面，素質(zhì)培養(yǎng)是另一個(gè)方面，兩者相輔相成，所以我覺得有必要把架構(gòu)師的所要具備的素質(zhì)羅列一下，作為程序員努力的方向。1、溝通能力

為了提高效率，架構(gòu)師必須贏得團(tuán)隊(duì)成員、工程經(jīng)理、客戶或用戶認(rèn)同，這就需要架構(gòu)師具有較強(qiáng)的溝通能力。溝通能力是人類最普遍性的素質(zhì)要求，技術(shù)人員好似容易忽略，想成為架構(gòu)師就不能忽略。千萬不要抱著這樣的觀念：懷才跟懷孕似的，時(shí)間久了總會(huì)被人發(fā)現(xiàn)的。還是天橋上賣大力丸的哥們說得對(duì)：光說不練假把式，光練不說傻把式?？纯茨阒車念^頭腦腦們，哪一個(gè)不是此中高手，我們千萬不要鄙視，認(rèn)為這是阿諛奉承、投機(jī)鉆營，凡事都要看到積極的一面，“溝通”確實(shí)是一種能力。我認(rèn)為自己是一個(gè)略內(nèi)向的人，因?yàn)槲沂寝r(nóng)村出來的孩子，普通話都說不好，以前或多或少帶有點(diǎn)自卑感，夢(mèng)想著是金子總會(huì)發(fā)光，所以在職業(yè)生涯中吃了不少虧?，F(xiàn)在，我深深懂得了溝通的重要性，我會(huì)很主動(dòng)地跟同事們，跟老大們不定時(shí)地溝通，感覺工作起來順暢多了。

這一條我認(rèn)為最為重要，所以排在首位。我甚至認(rèn)為下面幾條都可以忽略，唯一這一條得牢記，而且要常常提醒自己。2、領(lǐng)導(dǎo)能力

架構(gòu)師能夠推動(dòng)整個(gè)團(tuán)隊(duì)的技術(shù)進(jìn)展，能在壓力下作出關(guān)鍵性的決策，并將其貫徹到底。架構(gòu)師如何來保證這種執(zhí)行力？這就需要架構(gòu)師具有領(lǐng)導(dǎo)能力。

架構(gòu)師的領(lǐng)導(dǎo)能力的取得跟工程經(jīng)理不太一樣。工程經(jīng)理主要負(fù)責(zé)解決行政管理，這種能力與技術(shù)關(guān)系不大，他有人權(quán)和財(cái)權(quán)，再扯上一張“領(lǐng)導(dǎo)”的虎皮，采用“胡蘿卜加大棒”的方式，根本上可以保證執(zhí)行力。架構(gòu)師在工程里面可能更多地使用非正式的領(lǐng)導(dǎo)力，也就是我們常說的影響力，里面包括個(gè)人魅力、技術(shù)能力、知識(shí)傳遞等等。3、抽象思維和分析能力

架構(gòu)師必須具備抽象思維和分析的能力，這是你進(jìn)行系統(tǒng)分析和系統(tǒng)分解的根本素質(zhì)。只有具備這樣的能力，架構(gòu)師才能看清系統(tǒng)的整體，掌控全局，這也是架構(gòu)師大局觀的形成根底。你如何具備這種能力呢？一是來自于經(jīng)驗(yàn)，二是來自于學(xué)習(xí)。架構(gòu)師不僅要具備在問題領(lǐng)域上的經(jīng)驗(yàn)，也需要具備在軟件工程領(lǐng)域內(nèi)的經(jīng)驗(yàn)。也就是說，架構(gòu)師必須能夠準(zhǔn)確得理解需求，然后用軟件工程的思想，把需求轉(zhuǎn)化和分解成可用計(jì)算機(jī)語言實(shí)現(xiàn)的程度。經(jīng)驗(yàn)的積累是需要一個(gè)時(shí)間過程的，這個(gè)過程誰也幫不了你，是需要你去經(jīng)歷的。但是，如果你有意識(shí)地去培養(yǎng)，不斷吸取前人的經(jīng)驗(yàn)的話，還是可以縮短這個(gè)周期的。這也是我寫作此系列的始動(dòng)力之一。4、技術(shù)深度和廣度

架構(gòu)師最好精通1-2個(gè)技術(shù)，具備這種技術(shù)能力可以更加深入的理解有關(guān)架構(gòu)的工作原理，也可以拉近和開發(fā)人員的距離，并形成團(tuán)隊(duì)中的影響力。

架構(gòu)師的技術(shù)知識(shí)廣度也很重要，需要了解盡可能多的技術(shù)，所謂見多識(shí)廣，只有這樣，才可能綜合各種技術(shù)，選擇更加適合工程的解決方案。有的人說，架構(gòu)師技術(shù)廣度的要求高于技術(shù)深度的要求，這是很有道理的。

總而言之，一句話：架構(gòu)師是工程團(tuán)隊(duì)中的技術(shù)權(quán)威。面向過程和面向?qū)ο筮@兩個(gè)根本概念，不僅架構(gòu)師需要非常清楚，程序員、設(shè)計(jì)師也要非常清楚，這也是系統(tǒng)分析、設(shè)計(jì)和編碼最根本的常識(shí)。我接觸的程序員，很多人只停留在一種“似是而非”的程度，這是不行的，想要繼續(xù)前進(jìn)，就得把根底夯實(shí)，所以我覺得很有必要先回回爐，補(bǔ)補(bǔ)課。架構(gòu)師之路(5)---面向?qū)ο蟮脑O(shè)計(jì)原那么王澤賓收藏1

OO的設(shè)計(jì)原那么

我們已經(jīng)知道：面向?qū)ο蟮乃季S，為我們分析問題和解決問題提供了一種全新的方式。接下來的問題是：我們?nèi)绾芜M(jìn)行面向?qū)ο蟮脑O(shè)計(jì)呢？

在軟件工程中，人們依據(jù)以往的經(jīng)驗(yàn)，總結(jié)了五個(gè)面向?qū)ο蟆财鋵?shí)遠(yuǎn)不止〕的常見而且簡單的設(shè)計(jì)原那么。它們是我們進(jìn)行面向?qū)ο笤O(shè)計(jì)的根本依據(jù)：1、單一職責(zé)原那么SRP

對(duì)于一個(gè)類，它應(yīng)該只專注于做一件事和僅有一個(gè)引起它變化的原因。2、“開-閉”原那么OCP

應(yīng)當(dāng)能夠改變一個(gè)類的環(huán)境，而無須改變類本身。3、

里氏代換原那么LSP

防止造成派生類的方法非法或退化，一個(gè)基類的用戶應(yīng)當(dāng)不需要知道這個(gè)派生類。4、

依賴倒轉(zhuǎn)原那么DIP

用依賴于接口和抽象類來替代依賴容易變化的具體類。5、

接口隔離原那么ISP

給一個(gè)對(duì)象的每一個(gè)用戶一個(gè)接口，這個(gè)接口僅有用戶需要的方法。其中，“開-閉”原那么是面向?qū)ο蟮目蓮?fù)用設(shè)計(jì)的基石，其他設(shè)計(jì)原那么〔里氏代換原那么、依賴倒轉(zhuǎn)原那么、合成/聚合復(fù)用原那么、迪米特法那么、接口隔離原那么〕是實(shí)現(xiàn)“開-閉”原那么的手段和工具。

我會(huì)為大家一一進(jìn)行講解。2

單一職責(zé)原那么SRP(Single-ResponsibilityPrinciple)2.1

什么是單一職責(zé)

單一職責(zé)就是指一個(gè)類應(yīng)該專注于做一件事?，F(xiàn)實(shí)生活中也存在諸如此類的問題：“一個(gè)人可能身兼數(shù)職，甚至于這些職責(zé)彼此關(guān)系不大，那么他可能無法做好所有職責(zé)內(nèi)的事情，所以，還是專人專管比擬好。”我們?cè)谠O(shè)計(jì)類的時(shí)候，就應(yīng)該遵循這個(gè)原那么：單一職責(zé)。

我們以計(jì)算器編程為例：

在有些人眼里，計(jì)算器就是一件東西，是一個(gè)整體，所以它把這個(gè)需求進(jìn)行了抽象，最終設(shè)計(jì)為一個(gè)Calculator類，代碼如下：classCalculator{

publicStringcalculate(){

Console.Write("Pleaseinputthefirstnumber:");

StringstrNum1=Console.ReadLine();

Console.Write(Pleaseinputtheoperator:");

StringstrOpr=Console.ReadLine();

Console.Write("Pleaseinputthesecondnumber:");

StringstrNum2=Console.ReadLine();

StringstrResult="";

if(strOpr=="+"){

strResult=Convert.ToString(Convert.ToDouble(strNum1)+Convert.ToDouble(strNum2));

}

elseif(strOpr=="-"){

strResult=Convert.ToString(Convert.ToDouble(strNum1)-Convert.ToDouble(strNum2));

}

elseif(strOpr=="*"){

strResult=Convert.ToString(Convert.ToDouble(strNum1)*Convert.ToDouble(strNum2));

}

elseif(strOpr=="/"){

strResult=Convert.ToString(Convert.ToDouble(strNum1)/Convert.ToDouble(strNum2));

}

Console.WriteLine("Theresultis"+strResult);

}

}另外，還有一局部人認(rèn)為：計(jì)算器是一個(gè)外殼和一個(gè)處理器的組合。classAppearance{

publicintdisplayInput(String&strNum1,String&strOpr,String&strNum2){

Console.Write("Pleaseinputthefirstnumber:");

strNum1=Console.ReadLine();

Console.Write(Pleaseinputtheoperator:");

strOpr=Console.ReadL