回帖整理: 領域建模/表模組,Java/.NET 社區風格

//該回帖還沒有進行重構, 各位隨便看看便罷.

直接說點我的看法吧.., 程式/軟體到目前為止, 還是圍繞資料展開的, 而且受到資料的制約, 這並不因為OO而改變. 但我這麼說,
很明顯的, 不是說我贊成應該使用DataSet. DataSet只是用來簡化資料結構的一種手段,
就像資料庫是提取資料結構共性從而簡化資料結構更基本的手段. 這根本不涉及到模型這些. Martin把什麼表入口/領域模型等等做橫向比較,
不是不可以, 但這裡頭存在一個誤導, 就是把它們變成了一個問題的兩種實現方式, 甚至包含對立的意味在內.

用不用RecordSet
(比如DataSet)這種形式, 關鍵在於, RecordSet是否能夠簡化資料結構方面的工作. 如果以更高層次反過來看,
這隻是資料來源+DataSet代替了單純的資料來源. 然後是DTO, DTO實際上只是一種協助我們更好的工作的另一種手段,
和RecordSet沒有本質區別, 但這並非是它應該受到攻擊的原因.

然後才輪到是用不用建模啊之類問題, 如果根本無需建模,
那麼就成為了你們所攻擊的那種方法, 含有DTO或者簡單的行資料群組成的集合, 直接進入了其它層次. Martin也承認有個成本問題,
關鍵是他做了錯誤的比較, 把縱向的多個層次中根據不同情況省略了其中某幾個層次後, 造成的不同表現形式, 作為幾種方法進行了橫向的比較,
這就偏離了實質.

我不是學院派, 但是印象裡OOA也有個問題域吧. 大多數程式員不是哲學家或哪怕哲學的初學者,
所以總是過於著眼於更具體的東西. 其實是你的問題, 決定是否建模, 是否在接近資料來源的地方存在RecordSet, 等等等等.
那誰誰不是自己說過, 電腦科學, 就是通過增加一層去解決原有問題的一門科學, 本來這些都是不矛盾的, 最後讓Martin這麼一起頭,
加上國內外的Jdon/Javaeye們推波助瀾, 變成了在各種具體情況下非此即彼的論戰.

國內的程式員總是過於崇拜國外的一些大
嘴, 畢竟人家先起的步. 但是電腦科學, 尤其是現代的軟體科學, 還是很不成熟的一門科學, 所以沒有什麼是想當然正確的, 無論發言者是誰.
在我看來, 如何編寫"對的"程式, 只有通過不斷的思考, 有了自己的理解才做的到. 為什麼我說Jdon他們都鑽牛角尖鑽歪了,
因為他們用很多大嘴的言論在很大程度上作為了公理, 那麼推導的時候, 必然限制自己思維的發揮. 這麼多年過去了, 連DP95的作者都承認,
很多原來提出的概念存在不少謬誤, 這還不說明問題麼?

對我來說, GoF的DP95這樣的作品是真正的經典,
因為他們精確的提出了很多存在於軟體開發領域的問題, 開宗明義的說明了他們的方法從什麼角度以什麼程度解決它們; 而後來的這些人,
包括Martin, 包括很多很多Martin一夥的傢伙, 在著書立傳的時候, 由於選取的話題包含的內容過於繁複,
導致他們的論證過程只是在他們自己給出的例子上走個形式, 根本不具有真正的普適性.

反過來比較Gosling和Anders這兩個家
夥, 就知道為什麼Java社區始終是一個熱鬧的社區(熱鬧, 氣氛好, 一大堆新奇概念, 不代表就有一個對的方向),
卻最終升起了RoR這麼一個騎牆派且殘廢的明星. 這個地方我不多說, 你可以上網查查Anders的訪談,
看看C#是不是真的只是一個Java的複製版本，那些一個又一個的不同的設定是如何考慮的。從我的角度看，由於缺乏創造Turbo
Pascal/Dephi這樣的經曆，註定了Gosling永遠做不到像Anders那樣思考的廣度和深度，只能當個學院派；
再反過來看看現在，到底是誰還在繼續從事技術工作，就會明白差距到底在哪裡。

是的我承認，由於微軟的糖豆太多，很多.NET開發人員躺倒下來不去進行深入的思考；但從另一個方向上看，在一個錯誤的開端和基礎上，永遠只能無限接近而不能達到正確的結果；同時，每個人都參與方法論的討論，這個真的有必要嗎？

.NET
代表的是什麼路線? 不需要太多的人去思考，最終那些最先進的觀念，由很少的人提出，
但所有的人都會用(雖然現實還差很遠)。這“很少的人”不是指微軟那幫子，
而是指整個.NET社區中的少數人，但這種風格和微軟做了某物然後大多數人用是一脈相承的， POO(在這裡P不是指Program,
指Producer)永遠是少數，這也是效率最高的方式。

但是我們得等到這種結構變得真正成熟,
才能看見他的威力。POO們自然會去吸收Java社區中被證明是對的那些結論，也會去吸收Rail等實用架構的優勢。POO們的高高在上，也註定了.
NET社區和類似的社區永遠不會在Java社區的那些話題上熱鬧起來。Java社區的存在有必要麼?
在我看來，Java社區是不可或缺的，因為實際上是他們在為所有真正的POO(無論是.NET/Java/其他的)提供那些停留在低層次的但又不得不進行
的反覆權衡。

你可以看看類似於Lucene這樣的項目，可以快速的移植到.NET上，這些項目的繁榮其實並不說明Java社區的優勢，而
僅只是Java社區對整個開發社區的貢獻。起點的不同決定了角色的不同，就好比Sun創造了Java而IBM獲益一樣。這就是為什麼在我看來Martin
這樣的，只不過是一個低層次社區中討論的帶頭人，永遠也成不了一個真正優秀的POO;
所以我不得不提醒一下.NET領域裡對這些方面有興趣的愛好者，即使是印成了黑紙白字的言論，你我閱讀的時候也必須再三斟酌，二次創作。

比
如什麼“領域模型需要盡量接近現實世界”的言論。其實物件導向的書裡頭把人的思維往錯誤的地方引導的東西特別多。比如車/平治車/開車的這個例子。很明顯
的，車還可以分解成引擎/車身/傳動；引擎還可以分解成缸蓋/缸體；缸體是由鐵鑄的。那麼鐵相當於Int32之類的，於是就成了什麼基本型迷戀。這個提
法其實和RecordSet是一樣的。

不是說基本型迷戀不存在，或者說基本型迷戀是對的，關鍵是大多數人連問題域都找不準，讓他分辨
什麼是基本型迷戀，最終造成的是什麼都像是基本型迷戀（或類似的問題)，我個人就曾經經曆過這個過程，
甚至現在還得有意克服一下：你生產的明明是一個缸體，就是把鐵(基本型或者RecordSet）送進裝置(其他邏輯)裡加工成缸體，
而缸體本身就是製作引擎(其它調用者甚或就是介面)真正需要的結果， 卻怎麼也感覺不對勁，
愣要把鐵先變成一個自加工的不知道是什麼東西(因為這種東西根本就不應該存在)的東西， 否則就渾身不自在。

在我看來，Javaeye上
的多數熱火朝天的討論，在所謂的“接近現實世界”的時候，實際是背離了世界，因為連對象都沒找准(這個基本功，卻是Martin他們根本沒教過—我甚至懷
疑他是否掌握的夠好，而各種哲學/科學類書籍裡反覆討論的)，這是因為沒有切割出正確的概念，和沒有劃分出正確的問題的緣故。