丨架構(gòu)分解邊界不斷重新審視

審視模塊的接口，發(fā)現(xiàn)其中“過度的（或多余的）”約束條件，把它提高到足夠通用的、我們選的例子，是辦公軟件的IO子系統(tǒng)。從需求來說，我們首先考慮支持的是：WordRTFPS代代123456789typeSpanstructSaveWord(ctx*SaveWordContext)errorSaveRTF(ctx*SaveRTFContext)errorLoadWord(ctx*LoadWordContext)errorLoadRTF(ctx*LoadRTFContext)error}typeParagraphstructSpanCount()GetSpan(iint)SaveWord(ctx*SaveWordContext)SaveRTF(ctx*SaveRTFContext) LoadWord(ctx*LoadWordContext)20

LoadRTF(ctx*LoadRTFContext)typeTextPoolstructParagraphCount()GetParagraph(iint)SaveWord(ctx*SaveWordContext)SaveRTF(ctx*SaveRTFContext) LoadWord(ctx*LoadWordContext)32

LoadRTF(ctx*LoadRTFContext) structTextPool()SaveWord(stgIStorage)SaveRTF(f*os.File)SaveFile(filestring,formatstring)LoadWord(stgIStorage)LoadRTF(f*os.File)45

LoadFile(filestring)從上面的設(shè)計(jì)可以看出，讀盤存盤的代碼散落在 系統(tǒng)的各處，幾乎每個(gè)類都需要進(jìn)行相關(guān)的修改。這類功能我們把它叫做“全局性功能”。我們下一講將專門討論全局性功能怎么做設(shè)計(jì)。 某種程度上來說，這個(gè)架構(gòu)是受了OOP思想的毒害，以為一切都應(yīng)該以對象為中心，況且在微軟的MFC框架里面有Serialization機(jī)制支持，進(jìn)一步加劇了寫這類存盤讀盤代碼的傾這當(dāng)然是不太好的。在良好的設(shè)計(jì)中，一方面系統(tǒng)功能要少，少到只有最小子集；另一方面功能要能夠收斂，不能越加越多。WordRTFHTML，后天微軟又出來新的docx格式。文件格式總是層出不窮，難以收斂。Visitor到設(shè)計(jì)模式中的Visitor模式。什么是Visitor模式？簡單來說，它的目的是為系統(tǒng)的Model層提供一套遍歷數(shù)據(jù)的代代123456789typeVisitor{(attrsStartParagraph(attrs*ParagraphAttrs)errorStartSpan(attrs*SpanAttrs)errorCharacters(chars[]byte)errorEndSpan()EndParagraph()()typeVisitableDoc{Visit(visitorVisitor)}structVisit(visitorVisitor)}funcfunc()(docVisitableDoc),funcSaveWord(stgIStorage,docVisitableDoc)funcSaveRTF(f*os.File,docVisitableDoc)funcfuncLoadWord(stgIStorage)(VisitableDoc,error)funcLoadRTF(f*os.File)(VisitableDoc,error)funcLoadFile(filestring)(VisitableDoc,funcSaveFile(filestring,formatstring,docVisitableDoc)一方面，系統(tǒng)為IO系統(tǒng)提供了統(tǒng)一的數(shù)據(jù)接口。這樣IO子系統(tǒng)就從系統(tǒng)中另一方面，Word文檔的支持、RTF文檔的支持這些模塊在IO子系統(tǒng)中也彼此完全獨(dú)立，卻又相互可以非常融洽地進(jìn)行配合。比如我們可以很方便將RTF文件轉(zhuǎn)為Word文件，代funcConvRTF2Word(rtf*os.File,wordIStorage)errordoc,err:=iferr!=nilreturn returnSaveWord(word,7類似地，加載一個(gè)Word1234567func(stgIStorage),error)vdoc,err:=LoadWord(stg)iferr!=nil{returnnil,}return}如果你對比上一講“59|少談點(diǎn)框架，多談點(diǎn)業(yè)務(wù)”提到的SAX和DOM易看出這里的Visitor模式本質(zhì)上就是SAX模式，只不過數(shù)據(jù)源不再是磁盤中的文件，而是換成了系統(tǒng)的Model層而已。所以我前面講的SAX模式的缺點(diǎn)它一樣有。它最大的問題是有預(yù)設(shè)的數(shù)據(jù)邏輯，其客基于模型是一個(gè)非常簡陋的編程框架，與大部分IO子系統(tǒng)的需求方，比如我們這里的Word文檔存盤、RTF文檔存盤的訴求并不那么匹配。解決這種不匹配的常規(guī)做法是把數(shù)這個(gè)設(shè)計(jì)并不是假想的，實(shí)際上我當(dāng)年在做WPSOfficeIO子系統(tǒng)第一版本的架構(gòu)設(shè)計(jì)VisitorSAX另一方面，這個(gè)接口仍然是抽象而難以理解的。比如，不同的次序是什么樣的，需要較KISSIODOM所以第二次的架構(gòu)迭代，我們調(diào)整為基于DOM代代123456789typeIoSpan{Text()[]byteAttributes()IoSpanAttrs}typeIoSpans{Len()Elem(iint)}typeIoParagraph{Spans()Attributes()14typeIoParagraphs{Len()Elem(iint)19type {Paragraphs()Attributes() 2426func () structIo()3133func ()funcSaveWord(stgIStorage,doc )funcSaveRTF(f*os.File,doc )funcSaveFile(filestring,formatstring,doc )funcLoadWord(stgIStorage,doc )funcLoadRTF(f*os.File,doc )funcLoadFile(filestring,doc )在這個(gè)架構(gòu)，我們認(rèn)為有兩套DOM，一套是IODOM，即Io 接口。一套是系統(tǒng)自己的DOM，也就是 只是Io 這個(gè)DOM的超集。 類引入Io()函數(shù)來將其轉(zhuǎn)為Io在這個(gè)方案下，將RTF文件轉(zhuǎn)為Word1funcConvRTF2Word(rtf*os.File,wordIStorage)error}err}err:=LoadRTF(rtf,doc)iferr!=nil{return}returnSaveWord(word,doc:=234567812345678funcdoc:=(stgIStorage),error)err:=LoadWord(stg,doc.Io())iferr!=nil{returnnil,}returndoc,}相比前面的Visitor模式，采用IODOM除了讓所有存盤讀盤的模塊代碼工程量變低，接口的理解一致性更好外，還有一個(gè)額外的好處，是IODOM更自然，避免了驚異。因?yàn)楹诵南到y(tǒng)的Model層通常就是通過DOM接露的，而IODOM從概念上只是一個(gè)子集關(guān)系，顯然對客戶的理解成本來說是最低的。而Visitor模式你可以理解為它是系統(tǒng)Model層為IO子系統(tǒng)提供的插件機(jī)制，它對系統(tǒng)來說是額外的成本。DOMVisitorDOM我們是否解決了最初IO我們簡單分析下各類用戶故事（UserStory）就能夠發(fā)現(xiàn)其實(shí)并沒有。我們解決了所有流式PS因?yàn)閺南到y(tǒng)DOM得到的文檔，或者我們抽象的IODOM，都是流式文檔，并沒有分頁信息。如果我們PDF、PS文檔的存盤接口是這樣的：funcSavePDF(f*os.File,docfuncSavePS(f*os.File,doc))IODOM（Render），得到具備分頁信這意味著IO子系統(tǒng)在特定的場景下，其實(shí)與排版與繪制子系統(tǒng)相關(guān)，包括：可能有些人能夠回憶起來，前面在“ 22|桌面程序的架構(gòu)建議”一講介紹Model和ViewModel之間的關(guān)系時(shí)，我也是拿Office文檔舉例。系統(tǒng)的DOM，或者IO子系統(tǒng)的IODOM，通過排版（Render）功能，可以渲染出View層所需的顯示數(shù)據(jù)，我們不妨稱之為ViewDOM。ViewDOMPDF/PS代代1234funcRender(doc),funcSavePDF(f*os.File,docfuncSavePS(f*os.File,doc))但是我們在整理用戶故事（UserStory）的時(shí)候仍然把它給漏了。當(dāng)然，剪貼板帶來的影響沒有PDF/PS文檔大，它只是意味著我們的數(shù)據(jù)流不再是*os.File可以表達(dá)，而是需要用更抽象的io.Reader/Writer來表示。也就是說，以下接口：代代12345funcSaveRTF(f*os.File,docfuncLoadRTF(f*os.File,doc))funcSavePDF(f*os.File,docfuncSavePS(f*os.File,doc))代代12345funcSaveRTF(fio.Writer,docfuncLoadRTF(fio.Reader,doc))funcSavePDF(fio.Writer,docfuncSavePS(fio.Writer,doc))這其實(shí)就是我前面強(qiáng)調(diào)的“發(fā)現(xiàn)模塊接口中多余的約束”的一種典型表現(xiàn)。在我們模塊提高到足夠通用的、普適的場景來看時(shí)，實(shí)際上并不需要剪貼板這樣具體的用戶場景，也能夠及時(shí)地發(fā)現(xiàn)這種過度約束。另外，我們的IO子系統(tǒng)的級的接口12funcSaveFile(filestring,formatstring,doc)funcLoadFile(filestring,doc)1funcLoadFile(filestring,doc)(formatstring,err其二，考慮到剪貼板的支持，我們輸入的數(shù)據(jù)源不一定是文件，還可能是io.Reader、IStorageWindowsSTGMEDIUM參考。從跨平臺的角度，也可以考慮直接用Go語言中的任意類型。如下：12funcSave(srcinterface{},formatstring,doc)funcLoad(srcinterface{},doc)(formatstring,errinterface其三，考慮PDF/PS這類非流式文檔的支持，我們不能用Io 1funcSave(destinterface{},formatstring,doc)最重要的，當(dāng)然是職責(zé)。不同的業(yè)務(wù)模塊，分別做什么，它們之間通過什么樣的方式耦合在一起。這種耦合方式的需求適應(yīng)性如何，開發(fā)人員實(shí)現(xiàn)上的心智負(fù)擔(dān)如何，是我們決策的影響因素。計(jì)時(shí)，認(rèn)真細(xì)致地過一遍所有的用戶故事（UserStory），以確認(rèn)我們的架構(gòu)適應(yīng)性。其中“過度的（或多余的）”約束。如果你對今天的內(nèi)容有什么思考與解讀，歡迎給我留言，我們一起討論。下一講我們的話題按照大綱是“全局性功能的架構(gòu)設(shè)計(jì)”，但我計(jì)劃做一篇加餐，內(nèi)容是架構(gòu)思維實(shí)戰(zhàn)，把前面我們的實(shí)戰(zhàn)案例“畫圖程序”和這幾講的理論知識結(jié)合起來。大家可以提前思考以下內(nèi)容：對畫圖程序進(jìn)行子系統(tǒng)的劃分，我們的哪些代碼是系統(tǒng)， 歸科技所有 不得售賣。頁面已增加防盜追蹤，將依法其上一 59|少談點(diǎn)框架，多談點(diǎn)業(yè)下一 加餐|實(shí)戰(zhàn)：“畫圖程序”的整體架言言funcSave(srcinterface{},formatstring,docIo )errorfuncLoad(srcinterface{},docIo formatstring,errerror)第二個(gè)：funcSave(destinterface{},formatstring,do