希望大家能夠踴躍發(fā)言啊。

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

我在濟南

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

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

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

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

總結(jié)的不錯！我也來湊個熱鬧吧，發(fā)發(fā)自己的觀點。

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

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

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

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

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

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

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

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

謝謝JonneyQuest指正!

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

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

你也去了?

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

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

如果有需要可能某些領(lǐng)導(dǎo)再面試，暈啊。
很多東西都無從說起，也沒法準(zhǔn)備。

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

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");
}
}

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

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

6. 也可以使用空的final 聲明，但是如果要是使用的話就必須在這個類的構(gòu)造函數(shù)當(dāng)中初始化它。這一點要記住：final的初始化有兩種，一是直接在聲明的時候初始化，另一種是在構(gòu)造函數(shù)當(dāng)中初始化。

一個不錯的總結(jié)，使我受益非淺。

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

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

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

java當(dāng)中的值傳遞不會改變本函數(shù)聲明的參數(shù)值，而在被調(diào)用函數(shù)當(dāng)中參數(shù)的改變不會影響到本函數(shù)的參數(shù)值。

而被調(diào)用函數(shù)當(dāng)中的是一個本函數(shù)參數(shù)值聲明的值的一個考貝。