希望大家能夠踴躍發言啊。

<html:link action="abc"/>
也是可以的.
不過如果有action就不必加abc.do這樣的后綴了,只須abc即可.
但是page就必須加上.do

我在濟南

你在哪個城市？
我后來沒有去NEC因為檔案的事情沒有去。

但是后來我認為不去NEC還是對的。
他們大部分還是做軟件外包。

不是的，計算機專業的東西很少。
邏輯思維的東西大部分都是。

其實在interface當中定義的數據成員都是static final的，因此我們可以直接使用，且不能被修改

總結的不錯！我也來湊個熱鬧吧，發發自己的觀點。

Robbin總結的三點模型，我1、2用過，所味的第3點還無福消受啊

一、關于第一種模型我在一個實際項目中做過這樣的設計，給我的感覺不是很好，主要有以下幾點：
《1》要寫太多的貧血類，其實可以做一個工具來自動生成，也不錯。
《2》業務邏輯感覺不能很好的得到體現，這樣增加了BussImp類的復雜度， 且許多操作是不應該由BussImp來承擔， 但也有個好處那就是設計相對的容易些
《3》這不是OO的正統設計，這是受Boost的影響
二、至于第二種模型是我一直都在用的，這種模型對設計人員的要求相對的要高，為什么？那是因為對 ItemClass 要比以前更難以把握，其實設計就是歸類，但就是這個歸類就不那么的簡單，且每個人都有自己的歸類方法，很難形成統一。

在上面三種模型之外，還有很多這三種模型的變種，例如partech的模型就是把第二種模型中的DAO和Manager三個類合并為一個類后形成的模型；例如frain....(id很長記不住)的模型就是把第三種模型的三個類完全合并為一個單類后形成的模型；例如Archie是把第三種模型的Item又分出來一些純數據類(可能是，不確定)形成的一個模型。

但是不管怎么變，基本模型歸納起來就是上面的三種模型，下面分別簡單評價一下：

第一種模型絕大多數人都反對，因此反對理由我也不多講了。但遺憾的是，我觀察到的實際情形是，很多使用Hibernate的公司最后都是這種模型，這里面有很大的原因是很多公司的技術水平沒有達到這種層次，所以導致了這種貧血模型的出現。從這一點來說，Martin Fowler的批評聲音不是太響了，而是太弱了，還需要再繼續吶喊。

第二種模型就是Martin Fowler一直主張的模型，實際上也是我一直在實際項目中采用這種模型。我沒有看過Martin的POEAA，之所以能夠自己摸索到這種模型，也是因為從02年我已經開始思考這個問題并且尋求解決方案了，但是當時沒有看到Hibernate，那時候做的一個小型項目我已經按照這種模型來做了，但是由于沒有O/R Mapping的支持，寫到后來又不得不全部改成貧血的domain object，項目做完以后再繼續找，隨后就發現了Hibernate。當然，現在很多人一開始就是用Hibernate做項目，沒有經歷過我經歷的那個階段。

不過我覺得這種模型仍然不夠完美，因為你還是需要一個業務邏輯層來封裝所有的domain logic，這顯得非常羅嗦，并且業務邏輯對象的接口也不夠穩定。如果不考慮業務邏輯對象的重用性的話(業務邏輯對象的可重用性也不可能好)，很多人干脆就去掉了xxxManager這一層，在Web層的Action代碼直接調用xxxDao，同時容器事務管理配置到Action這一層上來。Hibernate的caveatemptor就是這樣架構的一個典型應用。

第三種模型是我很反對的一種模型，這種模型下面，Domain Object和DAO形成了雙向依賴關系，無法脫離框架測試，并且業務邏輯層的服務也和持久層對象的狀態耦合到了一起，會造成程序的高度的復雜性，很差的靈活性和糟糕的可維護性。也許將來技術進步導致的O/R Mapping管理下的domain object發展到足夠的動態持久透明化的話，這種模型才會成為一個理想的選擇。就像O/R Mapping的流行使得第二種模型成為了可能(O/R Mapping流行以前，我們只能用第一種模型，第二種模型那時候是不現實的)。

謝謝JonneyQuest指正!

感覺還可以,昨天去面試了.

問及我什么時候提出檔案的問題,我感覺到可能性會有的.
我應聘的是JAVA開發程序員的職位

你也去了?

今天上午的時候接到了NEC的電話面試通知。

現在倒是害怕起來了。我的英語很濫啊。
看了他們的流程，是要先技術面試，再人事部門面試

如果有需要可能某些領導再面試，暈啊。
很多東西都無從說起，也沒法準備。

但愿明天就像我的筆試一樣好運吧。

public class INClass{
void innerClass(final String str){
class IClass{
IClass(){
System.out.println(str);
}
}
IClass ic=new IClass();
}
public static void main(String[] args){
INClass inc=new INClass();
inc.innerClass("Hello");
}
}

這是一個方法當中使用了內部類的例子,那么內部類要使用方法當中的變量時必須把該方法的變量聲明為final,否則不會通過.

5.如果一個數據即是final,又是static那就表明這個數據有一塊無法改變的存儲空間。

6. 也可以使用空的final 聲明，但是如果要是使用的話就必須在這個類的構造函數當中初始化它。這一點要記?。篺inal的初始化有兩種，一是直接在聲明的時候初始化，另一種是在構造函數當中初始化。

一個不錯的總結，使我受益非淺。

這里要注意的一點：就是前提是test在未編譯前

謝謝樓上的指點，如果有機會我們可以交流

第一次來你的窩。
不過真的恭喜你，用自己怕雙手換回自己的幸福

java當中的值傳遞不會改變本函數聲明的參數值，而在被調用函數當中參數的改變不會影響到本函數的參數值。

而被調用函數當中的是一個本函數參數值聲明的值的一個考貝。