@Jack.Wang
你誤導了太多的人。。
。。。。。
現在對于常量池的解釋一片混亂。
說 在堆區 在棧區 在靜態區 在數據區 的都有。。
媽的。。。

不錯。。。還有研究 dump文件的阿 不錯不錯呵呵

朋友是bea的？ 。。。 我們公司用了spring作了框架 然后再weblogic中 redeploy的話似乎spring的context沒有被銷毀。 我們已經在listener中調用了context的關閉銷毀方法但是似乎沒啥效果。。。 redeploy多次后java heap就不行了。。。 不知道其他地方有沒有這種情況？？？？？

@arlen
以前我的想法與你一樣。我在我們公司的一體化項目中極力推薦其他架構。但是由于各種原因最后還是用了這種table module架構。

結果發現，使用這種應用架構在強依賴于關系數據的應用中卻是有效。

之前在看PoEAA中提到，能夠與“TABLE”交互的接口越多這種模式約有效。
在實踐過程中發現，其實只要提供一種通用的簡潔的序列化方式既可。比如，在于界面交互式（尤其是HTTP的web方式）可以用JSON來實現序列化過程。對于數據庫接口的交互其實就是一個加了循環的Record處理。

關于你提到的TABLE存儲在那里？ 其實這個問題很簡單，因為大部分企業應用都是“事務”應用所以，在一個Tx中提交這些數據到數據庫就結束了。

很久沒有上來了，那個一體化項目作了1年多了。呵呵。要好好總結一下。

4.1是周六。。。 還上班。。。 上班還出事故。。 真背啊。。。

我們公司有個部門 就使用這個作為界面基礎的。。。。不過。。。性能好像有點問題。。。

事實上 即便自己覺得理解了 還是會跟你所講的原意有所出入。。。 。。。 hoho

為啥要用 斜體字。。。 看起來實在難受啊。。。。。。。。。。。。。。。。

只談結構是否缺少行為表述呢？？還是認為結構描述先天由于行為描述？？


“.....著它們處于復雜性的不同級列（可以實現平滑的過渡）...”
又看到這個詞了 -_-b

樓主的注釋寫錯了。。。 被注冊到shutdownhook上的是TestShutdownHook的實例作清理工作的也是TestShutdownHook的run() 他將無限循環的TestThread.run()中止了。

恩。。。 是的，許多事務組件其實已經實現了提到的所模式。我這里只是說明一下，原理而已。嘿嘿。。。

。。。jdon 還是有些份量的。。。 和javaeye 一樣 都是有年頭的。。。

還有 抽象 本身不只是軟件工程的東西，而是哲學的東西，軟件工程只是借用。

比較期待 你的來自自然科學 級列論

不要用某些人啦。。。 那個只是我個人觀點啦。。。。

......對于你的一般性 基本知道是根抽象性有區別了 。。。。。。不過說老實話 相對論沒zm學 所以還是不太理解你舉的例子 能不能舉個 通俗點的例子。。。

關于

service層, data object層, dao層
其實 只是分析到某個抽象層次。。。職責 分類。。。而且有個問題環境 就是“ 交互型應用來說的”

你說：“. 但實際上, 我們肯定可以想見更加復雜的情形, 僅僅三層并不足以充分表達程序的結構”
確實是這樣，然而問題是就像你批評說的“有哪么復雜么”。既然，大家都知道，過于復雜就無用的。哪只分析到一個一般人能夠接受的復雜程度就停止。難道有錯？
其實我只是想說明 問題出在人們在實現中濫用這些東西 。分析出這些東西的本身無可厚非。

還有：關于你舉的例子 你說的只有 crud。。。 這里假設你所指crud是 這些方法或函數以及參數就是 服務接口的職責 其實更service 處于同一職責。。。 crud內部比然有對狀態的處理以保證這些crud的功能就是預想的那樣。。。 其實些東西的更 domain object 層次職責一樣。 （說老實話 data object我沒有看到過）
dao層 與 crud 中直接跟你的“數據庫” 交互的部分 其職責也使相近的。

如果要按照你的級列理論來說： 這里的職責也更你舉的例子是不同緯度的級列層次。

怎么不發到 架構師之家來呢？

我也寒一下。。。。。。。。。。。。。。。看來你學到了模式的精髓了。。。。。

不知道可不可以這樣理解。
你所指的“一般”與“特殊”就是： “相對抽象” 以及 “相對具體”。
你所指的“一般”到“特殊”，“特殊”到“一般”連個方向就是指：具化過程，抽象泛化過程，這兩個過程。

而級列就是指“相對抽象” 與“相對具體”存在著不同抽象層次。而且這寫層次客觀存在并且連續。

關于 你所說的“偏偏要在service層, data object層, dao層”部分可能你沒有理解定義這些層次的原始意義。 這些東西只是對“職責”的描述并不是實現，在實現中應該根據實際情況進行合并與取舍。而且這些“職責”也是由“事務”(這里并不是指原子操作的概念)這個職責具化而來。 我想你也應該知道一旦具化（特殊化），適用范圍就變小了。

不錯啊。。。 以前還沒用過這個。。。 先收了

haha... OO 被你們討論成這樣 我也夠佩服的。。。

我覺得你們去證明或取否定基礎都沒有意義。。。
因為：
1。OO本來是哲學概念。
2。OO是用來描述的，不是用來計算和證明的。
3。任何體系都沒有辦法證明自己的正確性，而只是基于一些公理存在，而這些公理指在于信與不信。


不過我覺得還是很有分量的。。。 先收了。。。。

對于“可退化性“ 不太了解
請問 根據你的定義
“架構的可退化性(degragation)指的是架構的結構可以從元素比較豐富,層次比較多,比較復雜的情況退化到比較簡單的情況“

是不是 退化就是指 不同職責部分 的合并但是這些職責依然存在？

我想 對于這樣非常理論化的歸納 估計很多人都不愿意看。 不過作為以后杜撰文章的，可復用模塊是不錯的材料。。。。呵呵

我個人感覺還是，比較接近的。
之所以現今的軟件架構與建筑架構有較大差異，主要是因為軟件領域和建筑領域的發展階段不同。一個幾十年，一個上千年了。成熟度不一樣。如果類比現今的軟件領域和早期的建筑領域會發現很多共同點的。

不錯不錯。

軟件架構師注重整體把握，高級程序員負責細節精華。者這個觀點來說，兩者級別是一樣的，只是關注點不同。

“另外作為架構師還要考慮的問題很多，甚至比技術架構更重要如授權模式、部署模式及成本、維護方案、安裝及升級方案、商標及商標的相關元素、發布及發布管理、安全因素、市場因素及技術市場架構（個人認為這個因素最難也最重要）“
。。。。。。。。。這個好像已經上升到系統分析級別了。。。該角色關注范圍比構架師跟廣。

你好，算我一個把。軟件構架師我是我職業生涯的的一個中期目標。現在雖然經驗項目經驗不多，不過我自以為對事務系統的整體多少有點把握。現在，正準備總結一下自己在這方面的一些觀點，并準備花較常時間學習研究一下軟件集成的設計與構架。剛申請blog 現在上還沒有啥東西。。。http://www.aygfsteel.com/wfeng007