@ My Space

@ My space

在JDK1.4.2中加入了對NIO的支持，掌握其中的Selector個人認為是能實現好NIO的關鍵。

Selector是用來獲取注冊在其中的channel的相關事件的發生，也就是accept，read和write。selector中有3個key set。

key set：包含代表所有在其中注冊的channel，可以通過selector.keys()得到。
selected-key set：包含所有被檢測到有關注的操作已經就緒的key，通過selector.selectedKeys得到。
cancelled-key set：包含所有已經被cancel，但是還沒有channel還沒有deregister的key，這個集合是不能直接被訪問的。

key通過調用channel的register方法被加入到key set中。被取消的key在select的時候會被從相應的key set中移除。

key set自身是不可以直接進行修改的。 無論是通過調用channel的close方法還是調用key的cancel方法，key都會被放置到canceled-key set中。取消的key會將其channel在下一次select時將注冊撤銷，同時將key從所有的key set中移除。

key在執行select操作時被加入到selected-key set中。在selected-key set中的key可以通過調用iterator的remove方法，將其從selected-key set中移除，不能通過其他的辦法將其從selected-key set中移除。

通過selector的3個方法select（阻塞選擇，直到有關心的事件發生時退出阻塞），selectNow（不阻塞選擇），select(long)（指定超時選擇，超時到達或者有關心事件發生時退出阻塞），來獲取關心事件的發生。其執行步驟分為以下3步：

1、將存在于canceled-key set中的key從所有的key set中移除，撤銷注冊的channel，清空canceled-key set。
2、地層操作系統檢查是否有關心的事件發生，當有關心的事件發生時，首先檢查channel的key是否已經存在于selected-key set中，如果不存在，則將其加入到selected-key set中去，同時修改key的ready-operation set來表明當前ready的操作，而以前存在于ready-operation set中的信息會被刪除。如果對應的key已經存在于selected-key set中，這直接修改其ready-operation set來表明當前ready的操作，刪除原來ready-operation set中的信息。
3、如果在第二步中有加入到canceled-key set中的key，在這一步會執行第一步的操作。

selector自身是線程安全的，而他的key set卻不是。在一次選擇發生的過程中，對于key的關心事件的修改要等到下一次select的時候才會生效。 另外，key和其代表的channel有可能在任何時候被cancel和close。因此存在于key set中的key并不代表其key是有效的，也不代表其channel是open的。如果key有可能被其他的線程取消或關閉channel，程序必須小 心的同步檢查這些條件。

阻塞了的select可以通過調用selector的wakeup方法來喚醒。

在JavaScript中，可以通過window.location來獲取url地址。但是window.location是一個對象，沒有辦法直接從里面獲取出我們需要的參數。通常的做法就是使用一個隱藏的<input>,通過將window.location負值給input。其目的就是為了將location轉換成String。寫的過程中總是覺得太復雜了，后來發現使用document.URL就可以解決這個問題。

今天在幫朋友寫一個簡單的產品發布網站，由于使用的空間是靜態的，沒有辦法只能在javascript上下功夫了。首先想到的便是RIA,上網google了一下，發現這樣的東西還真不少，可謂是十八般武藝各顯靈通?？戳丝次拿鞯腷indows，感覺真的非常的好。可是選擇它對于我要做的東西，可以說是過于復雜了。（http://www.bindows.net 有興趣的朋友可以去看看）。
搜索了半天最后還是決定，采用javascript讀取服務器端xml文件的辦法來實現。嘗試了一下感覺還不錯，確定就是對使用的瀏覽器有依賴。
先寫了一個商品的xml文件：

 

使用javascript來讀入xml實在是相當的簡單，只需要兩句話就可以搞定：

 

指定要載入的xml文件名就可以完成對xml的讀入。

 

得到xml對象后就可以適用對象提供的相應方法和屬性來獲取xml中定義的數據信息。
xmlObj.hasChildNodes來判斷是否含有子項；
xmlObj.childNodes.lenght 得到包含的子項的數量
子項可以用數字來作為索引，以product.xml為例。如果我們要獲取第二條商品時，可以用xmlObj.childNodes(1)來獲得，xmlObj.childNodes(1).childNodes(0)得到的是description
xmlObj.childNodes(1).childNodes(0).text 得到description的值
xmlObj.childNodes(1).getAttribute("name") 得到第二條商品的名字

下載了一個Action Script Viewer 4.0對原來的swf文件進行反編譯，雖然有的movie clip會出現一點問題，但是總的來說效果還是不錯的，而且操作相當的簡單。

1）使用ASV打開要進行反編譯的SWF文件；
2）File-->export rebuild data。這時將swf文件分拆成單個的swf文件；
3）打開flash，創建一個空的fla文件；
4）File-->Import...-->Import to Library   將前面導出的swf文件導入，如果swf文件太多flash會報錯，可以通過分批導入文件來繞過這個錯誤；
5）將新建的swf文件保存為rebuild.fla，并且3）導出的文件在同一目錄；
6）運行3）產生的一個rebuild.jsfl文件，一切搞定。

中午收到老姐來的電話，電話里她是一遍一遍又一遍的在我耳邊嘮叨，說，“不管你怎么忙，有多少東西要寫，一定要按時睡覺”。還列出了一堆要按時睡覺的理由。其實誰不知道應該要按時睡覺，可是作為寫程序的程序員來說，要真想做到這一點實在是難，難，難呀！

要按時睡覺的理由：

從人的排毒期入手：晚間11：00－－1：00，肝的排毒期（必須在睡覺中進行）
從人的睡眠最佳時段入手：1：00－－4：00，人的睡眠是質量最高的

不知道各位有誰是有正常的生活習慣的，能不能說一說你是怎么做到的。。。

    做項目，無論是遺留產品的再生產，還是對遺留產品的再利用，都不可避免的會出現一大堆的異構現象。解決異構通信問題是這類項目的主要問題。以前看見這種情況第一個解決方案就是Socket通信。說實在的自己實現Socket通信，定制通信協議，或者是實現已有的通信協議都是很頭痛的事情。本人有不堪回首的歷史經歷。

    最近同樣在項目中需要去解決一個異構問題，由于時間的緊迫，以及先天的運行環境（兩個部分是運行在同一臺機器上的）。考慮到了使用JNI，結果表明JNI是完全可以勝任目前的角色的。以前沒有了解過JNI，總是以為它這不好那不好，用了用，表現還不錯，而且實現起來非常之簡單。

    整個實現過程可以分為五步來完成：

1）寫一個聲明了native的Java文件：

2) 使用javah產生對應的CPP頭文件：
命令：javah -classpath <path> -jni example.TestJNI -d <out_dir>
生成的頭文件example_TestJNI.h如下：

/**//* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/**//* Header for class example_TestJNI */

#ifndef _Included_example_TestJNI
#define _Included_example_TestJNI
#ifdef __cplusplus
extern "C" {
#endif
/**//*
 * Class:     example_TestJNI
 * Method:    getNameForCPP
 * Signature: ()Ljava/lang/String;
 */
JNIEXPORT jstring JNICALL Java_example_TestJNI_getNameForCPP
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif

3）實現對應的CPP代碼：

#include "example_TestJNI.h"
#include <string>

JNIEXPORT jstring JNICALL Java_example_TestJNI_getNameForCPP
  (JNIEnv * env, jobject)
{
    //TODO 可以在此調用其他的代碼
    std::string strName = "Tower";
    return env->NewStringUTF(strName.c_str());
}

4) 編譯CPP代碼
命令：g++ -o libtest.so -shared -I<include_path> -I<java_home>/include -I<java_home>/include/linux example_TestJNI.cpp

5）執行

package example;

public class Test {
    public static void main(String[] args) {
        TestJNI test = new TestJNI();
        System.out.println("Hello " + test.getNameForCPP());
    }
}

export LD_EXPORT_PATH=<so_path>
java -cp <path> -Djava.library.path=<so_path> example.Test
輸出：Hello Tower

做了這么久的軟件，從來就沒有好好的學習過設計模式。寫代碼，做設計的時候都是稀里糊涂。做出來的設計，都會不同程度的讓自己感覺到不安。這可能就是《設計模式精解》書中所說那種直覺吧。

引用：

留意你的知覺

出自本能的直覺能對設計質量做出令人驚訝的預測。所謂“出自本能的直覺”，是指當你看到某些不喜歡的東西時，你胃部的感覺。我知道這聽起來并不科學（而且它的確不科學），但我的經驗總是向我證明：當我從直覺上不喜歡一個設計時，一個更好的設計一定就躺在角落里。

Facade模式：關鍵特征

意圖：希望簡化現有系統的使用方法。你需要定義自己的接口。
問題：只需要使用一個復雜系統的一個子集。或者，需要用一種特殊的方式與系統交互。
解決方案：Facade向客戶展現使用現有系統的一個新的接口。
參與者與協作者：向客戶展現一個定制的接口，讓客戶更容易地使用現有系統。
效果：Facade模式簡化了對所需子系統的使用。但是，由于Facade并不完整，因此某些功能對于客戶可能是可用的。
現實：1）定義一個（或一組）新的類來提供所需要的接口。
             2）讓新的類使用現有的系統。

Facade模式使用于以下情況：

• 不需要使用一個復雜系統的所有功能，并且可以創建一個新的類來包容訪問原有系統的接口的一個子集（通常它就是）比原始系統AP簡單得多。
• 希望包裝或隱藏原有系統。
• 希望使用原有系統的功能，并且希望增加一些新的功能。
• “編寫一個新的類”的代價小于“讓所有人學會使用原有系統”或“在未來維護整個系統”所需的代價
  

 

    一個項目通常分為表示層、業務邏輯層和持久層，這是最為常見的三層結構。在組織團隊進行項目開發的時候，選擇如何分工對版本控制有很大的影響。團隊在做開發的時候一般有兩種模式：按層開發和按功能開發。

按層開發（本人贊同的模式）

    在這種開發模式下，每個開發人員的目錄結構相對固定和獨立。對于CVS這類按文件夾來控制權限的版本控制服務器來說，比較容易實現對開發人員權限的劃分，不易出現文件不同步而導致的版本混亂。

    另外，這種開發模式下，更能集中開發人員的注意力，不需要了解太多與本層無關的其他技術。將精神全部集中在如何實現本層的功能上，更有利于寫出功能強大，運行穩定的代碼。例如：開發業務邏輯層的開發人員，他不可避免的會寫很多邏輯上基本上一致的代碼，在寫代碼的過程中，就能從中找出一些相對的共性，將公共的代碼進行抽象，從而避免了出現大量的重復代碼。由于工作范圍相對較小，能有更多的時間去學習相關方面的最新技術和解決方案，并應用到程序中，能使程序在實現方式上較為先進、優越。

    老天是公平的，萬物有其好的一面也必然有其不好的一面，這種開發模式也不能例外。對于需求不明確，無法定義相對固定的對外接口時，這中按層開發的模式就有其無法避免的一個問題。各層開發人員需要在開發的過程中，反覆的修改接口，以便適應于變化了的需求。這必然就導致邏輯處理部分代碼要做相應的修改。

按功能開發（本人持保留態度）

    這種開發模式下，開發人員的目錄結構基本是項目的完整目錄接口，他們需要到各層去編寫對應他們所開發的模塊的所有代碼。對于CVS這類版本控制服務器來說，基本上是無法做到對開發人員權限的界定。很容易造成版本控制混亂，導致文件版本不同步，是在開發過程中使用了公共文件的開發人員不能保證同步。例如：一個文件為多個開發人員所共同維護，開發人員各自都需要在其中添加自己功能所需要部分的代碼。這樣很容易出現多個人同時修改一個文件的情況，導致文件不同步而造成的版本混亂。

    另外，這種開發模式對開發人員的技術要求相對較高，它要求開發人員掌握各層中所需要的技術。從界面顯示到數據持久化，甚至到網絡通信都需要一個開發人員去實現。在功能實現架構不是很確定的情況下，程序代碼中將會出現大量的重復代碼，因為每個人都有自己的實現機制，而邏輯處理相同或相近的情況在同一層中出現頻率又比較高。導致程序的整體結構不統一，盡管層次結構相同。使得程序日后維護極度困難，大大的提高了維護成本。由于開發人員牽涉使用的技術過多，也很難保證程序實現方式的先進性和優越性。

Hibernate的繼承映射包含了三種不同的策略：

1. 每簇類使用一個表；
2. 每個子類一個表；
3. 每個具體內一個表（有限制）。
   

假設我們有四個類Animal，Dog，Cat，其代碼如下：
文件名：Animal.java

文件名：Dog.java

文件名：Cat.java

• 每簇類使用一個表

       使用每簇類使用一個表的策略時，有一個限制就時子類不能有NOT NULL，映射文件為：
       文件名：Animal.hbm.xml

• 每個子類一個表

       使用每個子類一個表的策略時，可以使用一個映射文件實現，也可以分成多個映射文件來實現。每個子類一個映射文件的情況：
       文件名：Animal.hbm.xml

       每個子類一個表的策略實際上一種one-to-one的映射。

• 每個具體內一個表（有限制）

       使用每個具體內一個表（有限制）策略時，每一個子類的映射文件將要包含所有父類中的屬性，映射文件：
       文件名：Dog.hbm.xml

    網上一大堆關于PO，POJO，DTO，VO等等對象的討論，通常都是各持己見，公說公有理，婆說婆有理，討論到最后也沒有什么定論。今天看到一個應用的代碼，發現其講PO直接做為VO（view object）在表示層使用。只從代碼上講，這樣做確實省去了跟多操作。不用重復的做對象的賦值、構造。但是會過頭來看，這樣無疑增加了代碼的耦合性。做一個簡單的假設，如果對持久層的PO進行了修改，相應的使用PO做為對應的VO（value object）業務邏輯層和使用PO最為VO（view object）的表示層都必須做相應的修改，如此的應用給代碼的維護帶來了很大的負擔，可謂是一動則百動。
    在J2EE應用開發中，是不應該出現這中PO共享使用的方式的。實體對象不應該被跨層使用，各層維護自己的實體對象。這點看書我想大家都知道，而在實際應用中很多人都選擇不遵循這一規則。（在使用hibernate時有所不同，引用：“不過由于Hibernate的強大功能，例如動態生成PO，PO的狀態管理可以脫離Session，使得在應用了Hibernate的J2EE框架中，PO完全可以充當VO，因此我們下面把PO和VO合并，統稱為PO?！?/FONT>引文：結合struts和hibernate談J2EE架構的數據表示。）出現這總現象，我想原因只有一個就是貪圖了一時的省事，在一次性應用開發中，相對的業務對象改動可能性相當的少，很多時候在做項目的時候并不會出現預料不到的改變，沒有必要去管理一大堆各式各樣的實體對象，這樣就自然的導致了PO在各層中共享使用。可是就我目前接觸到的項目基本上沒有需求是如此明確的，通常需求都是在不斷的改變，甚至有時到了最后發版的時候，一些客戶都會提出修改需求的要求。另外就是自做需求的情況就更是如此了，這種項目的需求是不斷的在變化的。為了保證項目的適應性和可擴展性，就必須保證各層之間的相對獨立，盡可能降低耦合度。

posted @ 2005-03-01 12:40 非飛 閱讀(2463) | 評論 (2) | 編輯 收藏