春天里，百花香...
2008年7月26日
#
我習慣連代碼和文章一起貼，現在空間用完了,重新注冊了一個（ http://m.tkk7.com/heyang ），歡迎大家訪問。
摘要: 我們可以使用DOM來解析來自服務器端的XML反饋，但返回結果比較復雜時我們必須在XML文檔中一個節點一個節點的向下鉆探，而使用XPath（專門用于定位匹配模式的一個或多個節點的小語言）只要一行代碼就能遍歷多個節點。與使用DOM相比，使用XSLT和XPath編碼所投入的精力要小得多，隨著應用規模的增長，后者的優勢會越來越顯著。
閱讀全文
摘要: 側邊欄靜態樹狀菜單在WebApp中很常見，本文涉及了靜態樹狀菜單的制作和顯示控制。比較簡單。
閱讀全文
摘要: 如果WebApp的側面菜單項較多時我們可以采用SlideBar的方式將部分菜單顯示，大部隱藏，類似Visio中做得那樣。本文討論了Slidebar的做法和顯示控制，比較簡單。
閱讀全文
摘要: 工字型布局中都有一個側邊菜單欄目用以導航，它們存在的一個普遍問題是：用戶無法迅速的找到自己所處頁面在整個網站中的位置。
當菜單項較多時這會演變成一個大問題，當用戶需要刻意尋找網頁標志來確定自己所處位置時，這已經說明網站給了客戶一種迷宮的感覺，有流失客戶的潛在可能性。很多網站采用了球拍式菜單來凸顯當前所在頁面，本文探討了這種球拍式菜單的實現方式。
閱讀全文
摘要: SQL注入攻擊的基本原理，是從客戶端合法接口提交特殊的非法代碼，讓其注入到服務器端執行業務的SQL中去，進而改變SQL語句的原有邏輯和影響服務器端正常業務的處理。SQL注入攻擊是Web應用中一個重要的安全問題，雖然Java具備較高的安全性，但如果開發人員不注意，也有可能留下安全隱患，本文將對此展開一些粗淺的探討，歡迎批評指正。
閱讀全文
摘要: 將網頁鏈接做成按鈕形狀是側邊菜單欄和頂端菜單欄常采用的形態，本文總結了四種常用鏈接按鈕形態的CSS制法。
閱讀全文
//*****************************************************
// 《飛翔》 話劇《切格瓦拉》插曲 詞 黃繼蘇 曲 張廣天
//*****************************************************
陸地淹沒了，
你就在海上飛翔。
海洋干涸了，
你就在天上飛翔。
天雷滾動了，
你就在火里飛翔。
火焰熄滅了，
你就在苦難中飛翔。
過去倒下了，
你就在未來飛翔。
未來退卻了，
你就在現在飛翔。
現在遲疑了，
你就在心中飛翔。
心靈敗壞了，
你就在創造中飛翔。
飛翔，飛翔，
永遠的飛翔。
飛翔，飛翔，
不朽的飛翔！
//*****************************************************
// 隨遇而安方為福 曾國藩
//*****************************************************
人生世間，自有知識以來，即有憂患如意事。小兒叫號，皆其意有不平。自幼至少至壯至老，如意之事常少，不如意之事常多。雖大富貴之人，天下所仰慕以為神仙，而其不如意處各自有之，與貧賤人無異，特所憂慮之事異爾。故謂之缺陷世界，以人生世間無足心滿意者。能達此理而順受之，則可稍安。
//*****************************************************
// 治學之道 《中華處世絕學》 一三九頁
//*****************************************************
治學之道，最緊要的是立下堅卓不俗的大志，立志是事業的大門，一個人追求的目標越高，他的學問長進就越快。
當然，僅有高大的志向是遠遠不夠的。治學，還要有“只問耕耘，不問收獲”的務實精神，避免奢談，踏實認真。要明白學問的取得，不是一朝一夕的事情，必須勤學好問，持之以很。學問好比金字塔，基礎越深越搏越好，這樣才能在廣播的基礎上求得高精尖。做學問，必須重視讀書的方法，不要貪多，而要專注于一書，力求吃透。同時，治學須避免門戶之見，博采眾長，兼收并蓄，為我所用，才能學貫中西，博古通今。而依賴于不俗的才學，一個人才可能為國立功，為己立德，為人立言，受到后人的敬仰。
//*****************************************************
// 子曰
//*****************************************************
君子博學而日參省乎己 則知明而行無過矣.
子曰：賜也，汝以予為多學而識之者與？對曰：然，非與？曰：解也！予一以貫之。
//*****************************************************
// 尼采：在世紀的轉折點上 周國平著
//*****************************************************
大自然的星空，群星燦爛。哪最早閃現的，未必是最亮的星宿。有的星宿孤獨的燃燒著，熄滅了，很久很久以后，它的光才到達我們的眼睛。
歷史和文化的星空何嘗不是如此呢？
誰終將聲震人間，必長久深自緘默；誰終將點燃閃電，必長久如云漂泊。
一個精神貧乏，缺乏獨特個性的人，當然不會遭受精神上危機的折磨。
許多人的所謂成熟，不過是被習俗磨去了棱角，變得世故而實際了。那不是成熟，而是精神的早衰和個性的夭亡。真正的成熟，應當是獨特個性的形成，真實自我的發現，精神上的結果和豐收。
當一個人要靠作品來批準自己的一生，他在根基上就變得極為苛求了。
書籍，知識，他人的思想都只能拿來為我所用，而不應當成為目的本身。
偉大的思想，與美麗的女子有相同的趣味，絕不肯讓萎靡的弱者來占有自己。
人只以勇敢和毅力所許可的限度接近真理。強者必須認識并肯定現實，正如弱者必須害怕和逃避現實一樣。
一個人倘若有健全旺盛的內在生命力，他是不會屈服于悲觀主義的，悲觀主義是生命力衰退的表現，屈服于悲觀主義有如屈服于霍亂，表明肌體已經患病。
一個人健康，他就向往人生的快樂；一個人羸弱，他就念念不忘死亡，就悲觀厭世。一個要在世間有所建樹的人最忌悲觀主義“看破紅塵--這是巨大的疲勞和一切創造者的末日。”
沒有痛苦，人只能有卑微的幸福。偉大的幸福正是戰勝巨大痛苦所產生的生命的崇高感。痛苦磨練了意志，激發了生機，解放了心靈。
熱愛人生的人縱然比別人感受到更多更多強烈的痛苦，同時也感受到更多更強烈的生命之歡樂。與痛苦相對抗，是人生最有趣味的事。
假如你在偉大的事業中失敗了，你自己因此便是失敗了么？假如你們自己是失敗了，人類因此便是失敗了么？假如人類也是失敗了，好吧，別在意！
堅強而沉重，或者堅強而陰郁，仍然不符合酒神精神。人生的偉大肯定者應該兼有堅硬的骨頭和輕捷的足，和歌者，武士與自由精神為一體。他應當學會“神圣的舞蹈”，學會歡笑。
//*****************************************************
// 自悟
//*****************************************************
唯有才華具有穿透心靈和穿越時空的力量。
//*****************************************************
// 其它摘錄
//*****************************************************
可以缺錢、可以缺吃、缺化，卻不可以缺德、確信用、缺操守！公司可以缺資金、缺設備，確不可以確倫理、缺道德、缺人才！
世事復雜，干什么事都不是那么簡單。要想在一生中有所作為，干一番事業，思想上必須有這樣的準備：別怕麻煩，肯于吃苦，受些窩囊氣也能挺得住。否則，遇到麻煩事，意外事，不順心事就急躁，想逃避，不肯吃苦，不能耐心處理麻煩事；或者遇見不公就會生怒氣，發牢騷而不再努力，這樣的人事業難成。
平時外表懶散而身懷絕技的高手只存在于古龍的武俠小說里，平時不認真，關鍵時刻肯定掉鏈子。
你可以靠謊言暫時領先，可不能靠它領先一輩子。
生活是一面鏡子，他照出了你的現實，別人對你不好，一定是自己的原因，決不是別人。
只有掙到錢、這才是男人成功的絕佳體現。有時候想，錢的確比文憑、文章等一切虛無的東西更實在，更能證明一個人。
問題是帶人走出困境的最好的向導 危機是教人進行創造的最好的老師 看到問題就是看到出路 碰到危機就是碰到機會。對于勇視現實 不滿現狀 只求進取 冷靜觀察 深入分析 甚至敢于自繪敗狀 自覺接受挑戰的人來說 問題就是希望 危機就是專輯。 或者簡單地說，只有在危機中不能驚覺新轉機的人，有真正的危機.
摘要: 模擬Blogjava制作的一個用CSS控制樣式的表格，比較簡單。
閱讀全文
摘要: 工字型布局是Web中應用比較廣泛的布局，它將整個頁面分成頁頭，側面導航欄，內容欄和頁腳欄四部分，頁頭一般包括logo，網站標題等；側面導航欄是導航菜單,根據客戶的喜好可以放在左邊也可以放在右邊；內容是正文部分，左右也可以根據用戶的喜好放置；頁腳包括版權信息，聯系我們等。根據content欄的寬度是否會隨著瀏覽器的寬度改變可以將工字型布局分為固定兩欄方式和可變兩欄方式，本文討論了這兩種方式的制法。
閱讀全文
摘要: 除了Div，Table，Form外，我們最常用的Html元素之一就是無序列表ul，使用它通常可以實現以下形式：
1.實現文本數據列表，這是無序列表的原始意圖。
2.嵌套使用無序列表，以實現樹狀結構。
3.修改無序列表的樣式，將它作為菜單使用。相對于用表格制作的菜單項，它修改起來比較方便，樣式也很容易設置。
第三點就是本文的主要議題。
閱讀全文
摘要: 一次將數據庫設計三范式應用于表設計的實踐過程，比較淺顯。
閱讀全文
摘要: 表單是Web應用中一個重要的組成部分,用戶向服務器端提交數據主要依靠表單進行. 好的表單能幫助用戶順利的完成數據的填寫, 不好的表單會讓用戶對填寫過程充滿困惑和挫折感.這些都會影響客戶的心理,進而會影響客戶對整個網站的感覺.
我覺得,前臺的表單設計和后臺的業務組件都很重要,和程序設計一樣,表單的設計也要遵照一定的原則和規范.
設計一個良好的表單,程序員需要綜合運用HTML,CSS,JavaScript等方面的知識,下面就是本人的一些關于表單設計的粗淺想法,斗膽拿出來和大家一起探討探討.
閱讀全文
摘要: 本文就分頁的理由，分頁的方式和MySql，Oracle中兩種不同的分頁技術進行了一些闡述，比較淺顯。
閱讀全文
摘要: 此文是“Web頁面表單域驗證方式的改進”的續篇。
示例頁面:登錄頁面
<%@ page contentType="text/html; charset=UTF-8"%>
<%@ taglib uri="/WEB-INF/tld/struts-html.tld" prefix="html"...
閱讀全文
摘要: 在基于Model2的應用中，控制層的類總會包含對業務層諸類的調用，業務層諸類不可避免的要產生各種異常，如果統一到控制層進行處理的話會導致代碼變得龐大臃腫還有不少重復，這種的例子在Web應用中的Servlet和Action諸類中并不少見。
如果我們使用模板方法模式（Template Method Pattern）將業務處理和異常處理分開，能有效簡化控制層諸類的代碼，借用這種模式，我們可以把固定的異常處理代碼放在基類中，而讓子類來實現具體的業務，如果執行業務過程中出現異常如數據庫無法連接，用戶找不到等異常后，直接將異常拋出讓基類來處理，這樣做成功的把業務處理和異常處理分開到了子類和基類兩種類中，涉及具體業務處理的子類代碼得到了很大的簡化，更方便閱讀，修改和管理。
有點疑惑的是，現在還不確定這樣做會有什么消極印象，如安全性或結構方面的，大家要是覺得有問題請不吝賜教。
閱讀全文
摘要: 一般來說涉及數據庫的應用中，表的主鍵有兩種生成方案，一種是專門定義一個主鍵表，在其中放置一個自增長的字段為其它表提供主鍵；另一種是使用Oracle的sequence。這兩種方案都有一定麻煩，Spring為此專門提供了一個ID增長器以簡化具體步驟，下文就是它的相關使用方法的，使用的數據庫是MySql5.
歸納
使用Spring的自增長ID生成器完成以下三步即可：
1）配置自增長id生成器，它需要一個數據源的支持。
2）根據配置將自增長id生成器注入DAO各類中。
3）使用nextStringValue，nextIntValue,nextLongValue方法得到ID。
閱讀全文
注意：本文說到的log4j版本為1.2.15，使用的配置文件是屬性文件（properties），如果這些與您的環境不符則請快速離開，以免耽誤你的寶貴時間。
一.log4j在桌面程序中的配置
這個相對簡單了，它的步驟就這樣兩步：
1）將log4j-1.2.15.jar引入到工程的lib目錄中.
2）確保配置文件log4j.properties在程序的代碼目錄(如src目錄,cfg目錄)中,它編譯后應該位于類路徑classes中.
log4j.properties示例（可以拷貝使用）：
- log4j.rootLogger=debug, stdout, R
-
- log4j.appender.stdout=org.apache.log4j.ConsoleAppender
- log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
-
- # Pattern to output the caller's file name and line number.
- log4j.appender.stdout.layout.ConversionPattern=%d %5p [%t] (%F:%L) - %m%n
-
- log4j.appender.R=org.apache.log4j.RollingFileAppender
- log4j.appender.R.File=輸出log文件.log
-
- log4j.appender.R.MaxFileSize=1000KB
- # Keep one backup file
- log4j.appender.R.MaxBackupIndex=1
-
- log4j.appender.R.layout=org.apache.log4j.PatternLayout
- log4j.appender.R.layout.ConversionPattern=%d %5p [%t] (%F:%L) - %m%n
要對這個文件進行修改的話，基本上改兩個地方就行了。
一個是輸出文件名稱，一個是輸出等級設置。
1) 輸出文件名稱:
log4j.appender.R.File=輸出log文件.log
2) 輸出等級:
log4j.rootLogger=debug, stdout, R
Debug說明只要是logger.debug以上的都記錄
配置到這里，就結束了。下面請看如何在程序中使用log4j。
二.log4j的使用
1) 首先，那個類要用到log4j記錄日志，就應該為類添加一個靜態的成員變量loogger，示例如下：
- public class Main{
- private static Logger logger = Logger.getLogger(Main.class);
-
- public static void main(String[] args){
- logger.info("成員管理程序啟動");
- new MemberMngCtrl();
- }
- }
2) 其次，你就可以使用logger.debug ,logger.info, logger.warn, logger.error, logger.fatal等函數(記錄等級依次提高)來記錄日志內容了，確實是很簡單方便的。
三.log4j在Web工程中的配置
與桌面程序一樣的是，properties文件也需要能被編譯到classes（WEB-INF/classes/）中，建議將屬性文件放在特定的目錄下并設置為源碼目錄，另外放在WEB-INF\src下也不錯。
這一步比前面稍多的是需要配置一個初始化log4j的initServlet，就是在一開始就啟動的Servlet，代碼如下：
- public class Log4jInit extends HttpServlet {
- private static final long serialVersionUID = -4499302208753939187L;
- static Logger logger = Logger.getLogger(Log4jInit.class);
-
- public void init(ServletConfig config) throws ServletException {
- String prefix = config.getServletContext().getRealPath("/");
- String file = config.getInitParameter("log4j");
- String filePath = prefix + file;
- Properties props = new Properties();
-
- try {
- FileInputStream istream = new FileInputStream(filePath);
- props.load(istream);
- istream.close();
-
- String logFile = prefix + props.getProperty("log4j.appender.R.File");
- props.setProperty("log4j.appender.R.File",logFile);
-
-
- PropertyConfigurator.configure(props);
- } catch (IOException e) {
- System.out.println("Could not read configuration file [" + filePath + "].");
- System.out.println("Ignoring configuration file [" + filePath + "].");
- return;
- }
- }
- }
然后，在Web.xml中配置一下，讓它在一開始啟動就可以了。
-
- <servlet>
- <servlet-name>log4j-init</servlet-name>
- <servlet-class>
- com.sitinspring.action.Log4jInit
- </servlet-class>
- <init-param>
- <param-name>log4j</param-name>
- <param-value>WEB-INF/classes/log4j.properties</param-value>
- </init-param>
- <load-on-startup>1</load-on-startup>
- </servlet>
全文完。
一般來說， 在創建一個應用程序之前，首先要決定這個應用程序的體系結構。應用程序體系結構（Application Architecture）由應用程序開發者設計，它指定了在各種各樣的終端系統上，應用程序是如何組織在一起的。為了降低設計難度，大部分程序都以層（稱為layer或level）的方式組織在一起，每一層都建立在它的下層基礎上，使用下層提供的服務，下層對上層隱藏了許多服務實現的細節。這種方法幾乎應用于整個計算機科學領域，也可以稱為信息隱藏，數據類型抽象，數據封裝，面向對象編程等。
分層即是對類進行一些規劃，以流程中的類的用途和所處環節劃分，把程序中將要用到的各個類分別歸納到各個包（目錄）中。分層是對系統進行細分的第一步,它旨在將系統按具體功能和用途分解為相對獨立的各個部分.如果說細分是將把難以解決的大問題分解成了各個容易解決的小問題的話，分層則是把解決同類小問題的類歸納到一起，這樣程序的結構更加清晰，程序的可讀性和可維護性越好，也更容易得到重用。
從大的尺度來講，一個程序可粗略的分成三個層次：
界面層（UI layer），這是用戶能直接感受到的，包含顯示和控制兩部分；
業務層（Business layer），其中包含了業務邏輯和業務處理；
持久層(Persistence layer)，它用來將數據存儲和將數據從持久層提取出來。
界面層（UI layer）中，包含兩個層次：視圖層View和控制層Controller.
視圖層View是用戶查看數據，輸入和向用戶輸出結果的一層，這一層是用戶唯一能夠感受軟件功能的窗口，它或者由Swing組件搭建（桌面系統或C/S系統中），或者由JSP搭建（B/S系統），它負責讓用戶輸入數據和將控制層返回的數據顯示給客戶。其中返回的數據一般是領域對象的變體或者直接就是領域對象或其集合。在Web程序中jsp基本就屬于這一層的。
控制層Controller是用來將界面和業務層聯系在一起的，在系統的各層次中，應該和View層打交道一般只有Controller層， Controller層是View層和系統其它層次進行交互的中介者， View層越過中介者直接調用其它層次的行為應該盡量避免。
一般來說，為了減少耦合，提高程序的可維護性，我們一般采用MVC架構模式將業務層，視圖層和控制層分開。
業務層（Business layer）中包含領域層 Domain，服務層 Service和實用工具層Util。
業務層是整個系統的關鍵部分,它主要由領域模型和業務邏輯組成,領域模型定義系統內相互作用的各個實體,業務邏輯則定義了領域模型所能執行的不同操作, 領域層的各個類代表了領域模型,而服務層的各個類代表了業務邏輯. 領域層和服務層是起點,其它各層都從這里起步.
領域層 Domain：領域對象是對現實世界業務處理對象的抽象和歸納，領域層中的類基本上都是實體（Entity）類，如員工管理系統中的Employee，學籍管理系統中的Student，借貸管理系統中的Contract等，系統的業務處理中用到那些實體對象，領域層中一般就應該有和這個實體對象相對應的實體類。這些類在剛開始設計時可能只有一些屬性和對應的getter/setter方法，以后會不斷的加入新的內容（主要是方法），如果有必要的話，可以為這些領域對象設計一些上層的抽象類或者接口，借助于泛型，反射，控制反轉等高級技能能在一定程度上簡化程序的編寫過程。此外，領域層是程序的核心內容,因為其他層次都在很大程度上依賴Domain層的設計，如果這一層設計不夠完善會使以后的工作步履蹣跚.
服務層Service:這一層就是為領域對象提供服務用的,領域對象一般不直接和表現層,持久層直接打交道而是通過服務層進行代理.服務層是UI層到持久層的中間通道，它處于上通界面下通持久層的中間環節，這個特性是使的這一層決定了軟件功能的多少。
一般來說，UI層向服務層傳入的是用戶輸入的一些參數，服務層進行驗證，重組后向下層DAO傳輸；而服務層從Dao層收到的是領域對象或其集合，而它向UI層返回的是領域對象或者其集合的變體或者直接是領域對象或者其集合本身。Service諸類的實例在桌面程序和CS程序中一般作為Model的一個私有成員，而在Web程序中常常要用到時再創建出來。除領域層外,其余各層是在圍繞它而設計.
實用工具層Util:這一層相對簡單，它包含了各種工具類,類中包含的主要是靜態函數和靜態成員變量,這些類對共通的函數,變量進行了歸納,它旨在消除重復代碼,降低主體代碼的復雜程度.一般此層中類的復用程度很高.值得通過項目積累.
持久層(Persistence layer)是直接與持久介質打交道的層次,持久介質可以是常見的關系型數據庫,文件甚至Web Service,它一般包含兩個部分。
數據存儲對象層（DAO層）,sql語句一般寫在這層中, 然后由它調用;DAO層是最低的一層,與持久介質直接打交道,它包含具體文件的位置,數據庫連接等；
另一個部分就是持久介質，通常是關系型數據庫。
Dao層中各個類一般作為Service的私有成員，供Service調用。
下圖是各層間的位置關系圖：
如何從需求中分析出諸個層次中的類呢，我們在大尺度上可以按照下面的步驟進行：
Domain the first:首先從業務流和業務規則中歸納總結出領域對象.
Service the second:為領域對象設計服務類。
Persistence the third:持久層的負責領域對象持久化到持久介質以及逆過程,它的設計在領域層和服務層之后,比較典型的持久層設計有數據庫表的設計和ER圖(實體關系圖)的繪制.
View the last:最后設計表現層,表現層受領域層和服務層制約, 容易變化且易于修改,通常放在最后實現.
具體步驟如下
1.理解，分析，鉆研需求,徹底了解你的客戶想要什么，需要你做些什么.
2.將大系統分解成一個個子系統,細分出各個層次,搞清楚各層的任務。
3.分析業務邏輯,歸納出業務流.
4.從業務流和業務規則中總結出領域對象.
5.為領域層實現服務層.
6.以Domain層和Service層為核心設計表現層和持久層,直到形成完整的程序.
7.加入實用層消除重復代碼，梳理結構和簡化流程,.
8.限制跨層的調用.
軟件開發過程中，唯一不變的就是變化。這是一句老生常談，也就是說軟件開發中永恒的主題就是變化。當你把代碼都寫好了，測試也完成了，準備交付的時候客戶忽然要求你在指定時間做出變化，這種情況在外包行業中很常見；而對一些銀行金融項目，邊調研邊開發邊測試屢見不鮮；對于一些Web項目，從來就只有永遠的Beta版，改來改去的事更是家常便飯。對此，程序員一定要求清晰的認識，抱怨只能是嘴上痛快，不解決實際問題。真要解決實際問題，非要動一番腦筋不可，如果合理使用了設計模式，反射或是Spring的IoC，便能變修改噩夢為一次有趣的智慧之旅。
首先我們看原始要求：客戶要求將一批雇員名單存入到CSV和XML兩種文件中去，以后還有可能增加別的文件格式，比如PDF，XLS等，雖然這是下一期的內容，但這一期應該考慮到變化，客戶要求擴展性一定要好。
沒問題，有了設計模式響應變化不難。這時我們可以用到模板方法模式：
定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。
先請看骨架抽象類：
- public abstract class FileMaker {
-
-
-
- private List<Employee> employees;
-
-
-
-
-
-
-
- public final void makeFile(List<Employee> employees,String fileName){
- setEmployees(employees);
- makeFile(fileName);
- }
-
-
-
-
-
- protected abstract void makeFile(String fileName);
-
- public final void setEmployees(List<Employee> employees) {
- this.employees = employees;
- }
-
- public List<Employee> getEmployees() {
- return employees;
- }
- }
很好，固定的函數和步驟都在抽象基類中寫定了，再看兩個具體實現類，它們要實現的就是makeFile函數而已。
- public class CSVFileMaker extends FileMaker{
- protected void makeFile(String fileName){
- try {
- BufferedWriter out = new BufferedWriter(new FileWriter(fileName));
-
- for(Employee emp:getEmployees()){
- String line="";
- line+=emp.getName()+",";
- line+=(emp.isMale()?"男":"女")+",";
- line+=emp.getAge()+",";
-
- out.write(line+"\r\n");
- }
-
- out.close();
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }
- public class XMLFileMaker extends FileMaker{
- protected void makeFile(String fileName){
- try {
- Document document = DocumentHelper.createDocument();
- Element root = document.addElement("employees");
-
- for(Employee emp:getEmployees()){
- Element empElm=root.addElement("employee");
-
- Element nameElm=empElm.addElement("name");
- nameElm.setText(emp.getName());
-
- Element sexElm=empElm.addElement("sex");
- sexElm.setText(emp.isMale()?"男":"女");
-
- Element ageElm=empElm.addElement("age");
- ageElm.setText(String.valueOf(emp.getAge()));
- }
-
- OutputFormat format = OutputFormat.createPrettyPrint();
- format.setEncoding("GBK");
- XMLWriter writer = new XMLWriter(new FileWriter(fileName),format);
-
- writer.write(document);
- writer.close();
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }
這樣昨完以后感覺很好，因為我們成功的把變化和不變分離開來，不變的部分放在了抽象基類中，而容易變化的部分放在了兩個具體的子類中，這樣如果再增加一種新文件格式，從抽象基類再擴展出一個子類即可。很好，這樣就不怕變化了。客戶對此也沒有異議。
調用示例如下：
- List<Employee> emps=new ArrayList<Employee>();
- emps.add(new Employee("Andy",true,21));
- emps.add(new Employee("Bill",false,23));
- emps.add(new Employee("Cindy",true,25));
- emps.add(new Employee("Douglas",false,28));
-
- FileMaker fileMaker=new CSVFileMaker();
- fileMaker.makeFile(emps, "1.csv");
-
- fileMaker=new XMLFileMaker();
- fileMaker.makeFile(emps, "2.xml");
客戶看到了我們的調用的例子，覺得應該更靈活一些，他說存成各種不同的文件是通過點擊按鈕來實現的，如果每個按鈕的事件處理函數都要生成具體子類豈不是太死板了嗎？這樣做每個文件下載按鈕的事件處理代碼不是都不一樣？
有點道理，如今理解到這一層的客戶實在是不多見了。不過很容易滿足他的需求，我們可以引入反射的方法：
- public static void main(String[] args) {
- List<Employee> emps=new ArrayList<Employee>();
- emps.add(new Employee("Andy",true,21));
- emps.add(new Employee("Bill",false,23));
- emps.add(new Employee("Cindy",true,25));
- emps.add(new Employee("Douglas",false,28));
-
- callByReflect("csv",emps,"1.csv");
- callByReflect("xml",emps,"2.xml");
- }
-
- public static void callByReflect(String type,List<Employee> emps,String fileName){
- try{
- Class cls=Class.forName("com.heyang."+type.toUpperCase()+"FileMaker");
- FileMaker fileMaker=(FileMaker)cls.newInstance();
- fileMaker.makeFile(emps, fileName);
- }
- catch(Exception ex){
- ex.printStackTrace();
- }
- }
因為按鈕上的文字和類名是有關的，如下載CSV的按鈕上就有CSV的文字，這可以通過正則表達式取道，再組合一下不就是類名了嗎？csv到com.heyang.CSVFileMaker,xml到com.heyang.XMLFileMaker，其實變化就是三個字母而已。如果增加按鈕，取出按鈕中的三個字母再調用callByReflect函數即可，這個過程簡直可以固化。
客戶看到反射方法以后很是滿意，沒有意見了。待客戶走后，項目經理把你拉到一邊，說：
“你剛才的方法不錯，確實很強，但看得懂反射并能靈活掌握的人水平要夠一年經驗才行，維護的活讓一年經驗的人去干太可惜了，最好改改，最好達到讓新手也能掌握并修改的程度。”。
沒辦法，領導總有領導的考慮，他這么說也很合理，成本問題我可以不考慮，但如果把程序搞得復雜貌似NB，能讓一些學藝不精的人產生云山霧罩的感覺，有時還能被人尊稱一聲“大俠”，但誰也不比誰傻多少，這聲大俠不是白叫的，但是出了問題或是有了變化別人還是要找你，到頭來還是給自己添亂，這些都是義務勞動，何苦來呢？還是應該改得容易些，讓大家都能修改，我可不愿意半夜三更被人叫起來問問題。
用Spring的IoC就可以解決問題，寫一個新類并配置到XML文件中對新手來說問題不大，這下可以讓領導放心了，自己就更放心了。
IoC方案代碼如下：
- public class Main {
- public static void main(String[] args) {
- List<Employee> emps=new ArrayList<Employee>();
- emps.add(new Employee("Andy",true,21));
- emps.add(new Employee("Bill",false,23));
- emps.add(new Employee("Cindy",true,25));
- emps.add(new Employee("Douglas",false,28));
-
- callByIoc("csv",emps,"1.csv");
- callByIoc("xml",emps,"2.xml");
- }
-
- public static void callByIoc(String type,List<Employee> emps,String fileName){
- try{
- ApplicationContext ctx = new FileSystemXmlApplicationContext("bean.xml");
- FileMaker fileMaker=(FileMaker)ctx.getBean(type);
- fileMaker.makeFile(emps, fileName);
- }
- catch(Exception ex){
- ex.printStackTrace();
- }
- }
- }
Bean。xml文件內容很簡單吧：
- <?xml version="1.0" encoding="UTF-8"?>
- <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
- <beans>
- <bean id="csv" class="com.heyang.CSVFileMaker"/>
- <bean id="xml" class="com.heyang.XMLFileMaker"/>
- </beans>
好了。到這里問題就徹底結束了，終于滿足了客戶和上級的要求，可以回家睡個好覺了，不用擔心別人打攪了。
態度改變一切，變化來了人總是要多做一些，心理當然是不愿意的，但抱怨或是消極抵制都不是解決問題之道；如果把它看做一個挑戰的契機，凡事多思考一些，不但能解決問題，自己也會有所提高，這就是積極的態度帶來的好處。
摘要: 在工程中經常有發送郵件的任務,如果使用JavaMail來發送郵件，用到的代碼較多，過程和細節也相對復雜，而使用Spring的MailSender能相對簡單方便些，這樣使程序員能更快捷的完成郵件發送任務。下面請看示例代碼：
注意在執行代碼前，請確認已經將activation.jar，commons-logging-1.0.4.jar，mail.jar和spring.jar載入工程。...
閱讀全文
在Web開發中，文本郵件發送的任務比較常見，我們可以利用它進行一些客戶通知和異常通知，文本郵件發送一般用到JavaMail API，下面是一個我有時用到的郵件發送實用工具類，把其中一些參數修改一下就能為你所用。
注意：在執行代碼前，請把mail.jar和activation.jar載入工程。
代碼如下：
- package com.heyang;
-
- import java.util.Date;
- import java.util.Properties;
-
- import javax.mail.Address;
- import javax.mail.Message;
- import javax.mail.Session;
- import javax.mail.Transport;
- import javax.mail.internet.InternetAddress;
- import javax.mail.internet.MimeMessage;
-
-
-
-
-
-
- public final class MailUtil {
-
- private static final String SenderEmailAddr = "XXXXXXX@163.com";
-
-
- private static final String SMTPUserName = "XXXX";
-
-
- private static final String SMTPPassword = "XXXXXXX";
-
-
- private static final String SMTPServerName = "smtp.163.com";
-
-
- private static final String TransportType = "smtp";
-
-
- private static Properties props;
-
-
-
-
-
- private MailUtil() {
-
- }
-
-
-
-
- static {
- MailUtil.props = new Properties();
-
-
- MailUtil.props.put("mail.smtp.host", MailUtil.SMTPServerName);
-
- MailUtil.props.put("mail.smtp.auth", "true");
- }
-
-
-
-
-
-
-
- public static void sendMail(String emailAddr, String mailTitle,
- String mailConcept) {
-
- Session s = Session.getInstance(MailUtil.props, null);
-
-
- s.setDebug(false);
-
-
- Message message = new MimeMessage(s);
- try {
-
- Address from = new InternetAddress(MailUtil.SenderEmailAddr);
- message.setFrom(from);
-
-
- Address to = new InternetAddress(emailAddr);
- message.setRecipient(Message.RecipientType.TO, to);
-
-
- message.setSubject(mailTitle);
-
- message.setText(mailConcept);
-
- message.setSentDate(new Date());
-
- message.saveChanges();
-
- Transport transport = s.getTransport(MailUtil.TransportType);
-
- transport.connect(MailUtil.SMTPServerName, MailUtil.SMTPUserName,
- MailUtil.SMTPPassword);
-
-
- transport.sendMessage(message, message.getAllRecipients());
- transport.close();
-
- System.out.println("發送郵件,郵件地址:" + emailAddr + " 標題:" + mailTitle
- + " 內容:" + mailConcept + "成功!");
- } catch (Exception e) {
- System.out.println(e.getMessage());
- System.out.println("發送郵件,郵件地址:" + emailAddr + " 標題:" + mailTitle
- + " 內容:" + mailConcept + "失敗! 原因是" + e.getMessage());
- }
- }
-
-
-
-
-
- public static void main(String[] args){
- MailUtil.sendMail("XXXXXX@gmail.com", "title", "concept");
- }
- }
在面向對象編程中，我們一般采用從頂向下的編程方式，即先設計類的層次，如View,Controller,Service,Dao,Domain,Util等，再完善各層中的類。在這個過程中，我發現按功能和形態來分，系統中類可分為以下幾個類別:
1.實體類(Entity Classes):這種類一般是現實世界事物在代碼世界中的抽象表示,和現實事物有著一一對應關系.存儲到持久介質中時一般對應著一條記錄.如MIS系統中常見的雇員類Employee,論壇系統中常見的Topic等.由于這些類可以直接從現實事物中歸納抽象得來,寫出它們的框架代碼一般相對方便容易,但要真正理順實體類之間的關系需要投入不少精力,這些類一般處于Domain層中.
2.通道類(Plumbing Classes):這種類一般用于充當傳輸實體類的通道,在編程中,經常需要從持久層取出一個或多個實體類的對象或是將實體類的對象存儲到持久層中,這種任務一般由通道類來完成.它們一般由Service或是Dao層中的類來承擔.這些類一般不保存狀態,對外界來說,它們的對外接口(Public Interface)一般比具體的實現重要,在數量較多時,也經常抽象出一些上層的抽象類或是接口出來以方便調用.
3.輔助類(Assistant Classes):這些類一般起輔助任務,一般可以把共通的處理和變量放在其中供其他層次類調用,這樣做一能避免散彈式修改,二能減少重復代碼,三能提高代碼復用度.輔助類一般放在Util包中.
4.框架類(Framework Classes):這些類一般由固定的框架提供,程序員不能改變.在類的層次上它一般處于界面和業務層之間,即控制層的位置,jsp/servlet中的Servlet,Struts1,2中的Action都是這樣的類,它承擔了接受用戶輸入,并展示業務處理的結果的任務.
一個技術人員要生存，要發展，要成一番事業，必須遵循一定固定的法則，若逆天而行而不自覺，輕則徒勞無功，白費精力；重則無法立足，庸碌一生。因此把握住自己的發展之道是技術人首要的大事，只有走在正確的道路上，前進才有意義。
一個技術人員，首先要固本培元，什么是技術人的根本呢？無論語言，框架和技術如何發展，數據結構和算法都是其核心內容，所謂萬變不離其宗，有了良好的數據結構和算法的根基，接受并掌握一個新興事物不過旬月時間，若沒有而盲目跟隨，事倍而功半矣。另外面向對象的精髓也要把握,從根本上來講,任何現代框架其核心思想還是沒有超越面向對象的范疇,都是面向對象的繼承和發展,理解掌握了面向對象的思想,就把握住了框架根本性的東西,學習掌握起來就更容易把握其本質.
其次，技術人員必須把握主流技術方向才不至于迷失自己。若在支流中迷失自己恐有空執屠龍之技無用武之地之憂，古代也許還能自娛自樂，現代社會這樣做溫飽都無法解決，房子，車子，孩子更是白扯；只有置身主流，才能繼續奮斗下去。當前的主流技術方向，無非SSH（Struts1/2,Spring,Hibernate）而已,徹底弄清楚它們,才有安身立命之本.君不見諸多招聘廣告,均寫SSH乎.這三項其實也不好掌握，尤其Hibernate，掌握不精深也不行，有些大俠也曾陰溝里翻過船。
其三,技術人員要樂于善于總結提高,對于已經掌握的內容,要及時歸納總結到紙面上,這樣做一能梳理脈絡，讓自己掌握得更全面細致；二能查漏補缺，發現以前忽視或是未接觸過的領域；三能求其友聲,放在博客上供大家分析閱讀討論，彌補自己的不足.有此三益,于己于人都是一件大好事，何樂而不為呢?
其四,技術人員要展示自己的能力和價值,應該具備自己的產品，它可以用來鞏固和展現自己的實力,在產品的研發過程中,技術人員能把自己的知識智慧實用化,可避免走入象牙塔之患;外界也能通過產品來了解發掘自己.這也是一件于己于人都有利的事情.
其五,技術人員應該具備完整的思想體系，有自己獨到的見解并能有所突破創新. 人云亦云無異于鸚鵡學舌,有何能哉? 要想上一個層次,必須鯉魚躍龍門. Gosing和Kaven兩人可作為最好的榜樣。
最后,廣博的知識不可少.拘泥于一處難免死鉆牛角尖,很多情況下換一種思維頓時有撥云見日之感,如有閑暇,技術人員應該跳出圈子,廣采能用之材為我所用.
摘要: 稱球問題經常是面試中的常客，這里我用做了一個稱球的程序，主要的方法就是遞歸和掃描，貼出來請大家指正。
閱讀全文
摘要: /** *//**
* 二叉樹節點類
* @author HEYANG
* @since 2008-7-26 下午02:59:06
*/
class Node<T extends Comparable> {
...
閱讀全文
sitinspring(http://m.tkk7.com)原創,轉載請注明出處.