Hiendt's Weblog

AJAX (Asynchronous JavaScript and XML) đã rất phổ biến, mặc dù công nghệ tồn tại trước khi cái tên ra đời, và ngày càng trở nên thông dụng. Tuy nhiên, không phải lúc nào dùng Ajax cũng hiệu quả. Cũng giống như Flash, DHTML và tất cả những công nghệ khác, có những trường hợp nên dùng, một số thì không nên.



Tôi lấy một ví dụ, bạn viết một trang tin tức. Ta có phần của các bài viết mới, tôi lấy ví dụ ta cần view 10 mẩu tin mới nhất. Để nó phía bên phải, và phần nội dung ở giữa.
Có 2 các để làm nó, một là khi bạn click lên một mẫu tin, refresh nguyên trang để view mẩu tin đó, một cách khác là dùng AJAX và đặt nội dung tin vào một thẻ div mà không cần refresh nguyên trang.
Dùng Ajax, người dùng sẽ cảm thấy rất tự nhiên, và tốc độ sẽ cải thiện đáng kể nếu trang có nhiều banners quảng cáo hay các thành phần khác. Tuy nhiên, khi mẫu tin được tạo thông qua một function được viết bằng JavaScript, nghĩa là search engine sẽ không nhận biết sự tồn tại của nó, và trang đó cũng không có một URL nhất định để đánh dấu.

Mặt khác, như ta đã biết hệ thống đánh giá bài viết. Lấy một ví dụ là từ 1 đến 10 sao. Trong trường hợp này chỉ là một ứng dụng nhỏ trong hệ thống, người dùng sẽ đánh giá, lúc này thì việc refreshing trang để lấy kết quả rating mới trở thành một lãng phí lớn. Trong trường hợp này, AJAX là một cách làm hữu hiệu. Bạn có thể click vào sao để đánh giá, sau đó dữ liệu được chuyển lên server, tính toán và gởi kết quả trả về lên web mà không cần refreshing trang.

Một ví dụ khác mà tôi đã từng gặp là hệ thống quảng cáo dùng AJAX để lưu lại mỗi khi người dùng clicks. Trong ứng dụng này, một banner được hiển thị và nếu người dùng clicked thì một AJAX request được gởi lên server, làm một số việc như thêm mẩu tin click và database, sau đó trở lại client để thực hiện việc chuyển trang. Có vể đó là một hướng đi hoàn hảo. Nhưng không phải vậy, chẳng việc gì bạn phải làm một đống các công việc như lưu click, lấy một URL, và chuyển trang bằng những đoạn javascript. Nó có giúp cái URL mà ta chuyển đến load nhanh hơn không? Trả lời: không. Nó có làm người dùng cảm thấy thoải mái hơn không? Trả lời: không. Và trong trường hợp này thì việc gọi một action là đủ để server sử lý và chuyển trang.

Bài viết này, tôi mong các bạn hãy nghĩ về tính hiệu quả khi sử dụng công nghệ. Dùng nó một cách khôn ngoan thì ứng dụng của bạn sẽ tốt hơn, đừng vì những lời đồn thổi mà vướng phải những lỗi lầm tai hại.

Đọc tiếp >>

Từ Framework đã quá thông dụng. Nhờ nó mà số dòng code của chúng ta giảm đi thấy rỏ. Và các ứng dụng ngày nay, còn có thêm một yêu cầu về frameworks dùng. Tuy nhiên, có một điều mà hầu như ai cũng biết: mặt trái của nó.



Tôi đã dùng JSF ngay từ khi bắt đầu đến với Java WEB. Một components base framework, giúp ta tối ưu hoá việc sử dụng MVC trong web. Tôi đã hầu như không gặp bất kỳ một trở ngại nào trong các ứng dụng thuộc loại cổ điển (các bài quản lý như: thư viện, sinh viên, nhân viên, thư viện, ...).

Nhưng khi dùng Ajax thì thật sự nó là một gánh nặng. Muốn làm một component Ajax cho JSF quả là rất khó khăn - dĩ nhiên là không phải không làm được. Bạn cần có một kiến thức rỏ ràng về vòng đời các thành phần, biết cách vượt qua một số giai đoạn, và một thành phần không thể không biết là PhaseListener.

Có một số hãng phát triển cho mình một số Ajax for JSF frameworks như IceSoft với icefaces, Jboss với Richfaces, và Oracle với Netadvantage. Tuy nhiên, việc dùng frameworks nào cần có một bước phân tích tỉ mỉ về tất cả các vấn đề cần phải dùng frameworks. Đó là chưa kể đến vấn đề về lỗi kỹ thuật của nó, và thường thì ta phải chờ fix, đó là một ảnh hưởng rất lớn đến dự án.

Ở tầng business thì ta không thể phủ nhận những tính năng của Spring. Tuy nhiên, mặt tối của nó đã dẫn đến một bài viết về một cuộc phỏng vấn điển hình mà Giovani Salvador nhắc đến trong bài Java Architectural Knowledge for Job Interviews. Are we prepared? Nó cũng làm tôi nhớ đến vấn đề mà Robert Nocera đưa ra là gọi Stored Procedures từ JDBCTemplate của Spring.

Và cuối cùng: “Một giải pháp hoàn hảo là giải pháp không dùng Frameworks”.

Đọc tiếp >>

Người ta cũng nói vui với nhau rằng: làm việc quá giờ trong IT là một nền “văn hoá”. Nhưng cá nhân tôi nghĩ rằng đó là kết quả của sự lớn lên của hệ thống IT, lớn lên của nhiệm vụ được mong đợi và tính cạnh tranh khốc liệt trong ngành. Nó cũng là một thực tế đáng buồn trong IT, và khi thay đổi “nền văn hoá” sẽ không làm thay đổi được nó.

Có những cách làm hay

Trường đại học Carnegie Mellon thiết lập một mẫu giáo dục để thu hút nhiều người phụ nữ hơn. Chẳng hạn, dùng môn kỹ năng lập trình là điều kiện để sắp lớp. Bù lại, họ tạo ra những lớp lập trình tăng tốc cho newbies, để bằng với những sinh viên với đã có kinh nghiệm trước. Chương trình được coi là một thành công và một kiểu mẫu cho những trường đại học khác.

Nhưng có thiết thực?

Chương trình Carnegie cũng có cùng lỗi về sự giữ thăng bằng giới với những sáng kiến: Nó tìm kiếm thúc đẩy tỷ lệ phụ nữ bằng việc tập trung vào phụ nữ, mà không biết rằng trong sâu thẳm họ không quan tâm đến IT như những người sẽ là đối thủ trong trường học và trong công việc. Những người ít hứng thú hơn này có khả năng thất bại hay rời bỏ công việc khi đối diện với thử thách so với những người hứng thú và luôn thúc đẩy bản thân vươn lên, bất chấp giới.

Câu hỏi đặt ra: Với tất cả những công cụ lập trình miễn phí hiện nay, thông tin và những ý tưởng đang có, người nào làm nó trước 18 tuổi mà không cần học lập trình?
Câu trả lời: Đó là người có niềm đam mê đặc biệt đến lập trình.
Có hàng triệu câu hỏi được đặt ra chỉ để hiểu ngành IT và sự không cân bằng giới, bí quyết để học thành công IT, so sánh giữa teens có đam mê trong lập trình với teens không có niềm đam mê như vậy.
Tôi Thật sự không biết rằng tại sao nhiều những cậu bé hơn những cô gái chọn học IT, chọn và ở lại với IT để bắt đầu sự nghiệp - và Tôi thú nhận rằng Tôi không có giải pháp hay đề xuất gì. Nhưng Tôi chắc chắn rằng khuôn mẫu hóa, giới tính và những nhân tố khác luôn phải tồn tại. Tôi cũng tin điều đó gây sức ép cho những cô gái- hay những chàng trai cho rằng điều đó quan trọng- khi bước vào sự nghiệp mà không có sự giúp đỡ của bất cứ ai. Qua những suy nghĩ không đúng- như kiểu mẫu và rập khuôn- và chẳng giúp gì được. Điều cần thiết là họ cần có một tình yêu với thiết bị, những hệ thống và thao tác giải quyết vấn đề phức tạp, hay họ chẳng hề nghĩ đến việc chọn theo IT.

Trong khi trong mọi lĩnh vực, đúng là chúng tôi cần hỗ trợ để loại bỏ sự phân biệt giới, tiền lương và các chế độ không công bằng. Nhưng không phải là áp đặt cho những cô gái và đẩy họ vào trong một sự nghiệp mà họ không hứng thú.

Kết luận

Có quá nhiều phụ nữ trong IT phải không? Tất nhiên không phải। Nhưng Tôi thật sự lo ngại rằng có thể quá nhiều phụ nữ vào IT bởi sự “dỗ dành” để trong một sự nghiệp mà không hề có một niềm đam mê hay yêu thích, chỉ vì lý do “cân bằng giới”.

Tham khảo từ: http://itmanagement.earthweb.com/career/article.php/3645346

Đọc tiếp >>

Theo hãng nghiêng cứu Gartner, tỉ lệ phần trăm nữ làm việc trong ngành IT là thấp và có xu hướng giảm, từ 42 % trong năm 1996 xuống cỏn 32.4% trong năm 2004 trên toàn thế giới. Trong môt số quốc gia, trong đó có Mỹ, con số là dưới 30 %.

Nhưng những điều đó chỉ là một phần nhỏ của câu chuyện: thường có rất ít nữ chọn theo ngành IT so với nam trong các trường đại học. Và trong số đó, phần lớn khi ra trường làm việc lại chọn một chuyên ngành khác. Trong khi hàng năm, số lượng nữ chọn ngành IT nhiều hơn nam đi ra khỏi ngành. Về vị trí quản lý trong ngành IT, phụ nữ rất ít. Các vị trí cao hơn nữa thì càng hiếm.
Lý do của sự mất cân bằng trên có thể do một số lý do sau như: hầu hết không ủng hộ nữ theo ngành IT, thiếu người kiểu mẫu, tính chất của ngành IT là quá “nam tính,” và có sự phân biệt giới trong làm việc.
Hàng triệu Đô La được dùng cho các tổ chức xã hội và trường đại học để hiểu đâu là lý do của sự mất cân bằng trong ngành IT, nhưng kết quả bước đầu của chương trình này là thất bại nhiều hơn thành công.

Thiếu người kiểu mẩu

Rebecca George, người điều hành diễn đàn phụ nữ IT, than thở việc thiếu những người đi đầu, và dẫn chứng: "Nếu bạn hỏi trong một lớp của những học sinh ở lứa tuổi khoảng 11 rằng họ biết bao nhiêu người lập trình viên(LTV) nữ, thì sẽ không có một cánh tay nào dơ tay cả. Nếu là trường hợp của bác sĩ, luật sư, giáo viên thì có rất nhiểu."
Lý do này thật ra là không hợp lý. Vì phần lớn trẻ em không biết cả những LTV nam. Bác sĩ và giáo viên, là những người mà trẻ em hay tiếp xúc, và thường để lại ấn tượng cho các em. Quan trọng hơn, người ta thường chọn IT không phải vì họ muốn như ai đó, mà họ yêu hệ thống máy tính, mạng và giải quyết những vấn đề rắc rối liên quan.
Một điều tệ nhất là những người kiểu mẩu truyền cảm hứng cho ai đó chọn ngành IT và muốn được giống như họ. IT là nghề có tính cạnh tranh cao, và đầy những thử thách. Một người luôn muốn theo ngành IT vì họ muốn trở thành một ai đó, hơn là yêu thích công việc, thì chắc chắn sẽ thất bại.

Không hợp thời

Để thu hút nữ chọn IT, theo George, "bạn cần bắt đầu với trẻ em 11-tuổi và thuyết phục chúng rằng ngành IT thế giới là rất “thời thượng”, và chúng hoàn toàn có thể là một phần của nó."
Một người chọn công việc IT làm một niềm đam mê, không phải vì tác phong của một người đang làm nó. Có nhiều hình ảnh về nghề nghiệp có sự thu hút đặc biệt như: diễn viên, người mẫu, nhà bình luận công nghệ – nhưng IT không phải là chúng.
Đừng nên nói với một cô gái rằng IT là một nghề “mốt” và “hợp thời”, mà chúng ta cần thuyết phục chúng rằng: mốt và thời trang là trống rỗng và không có gì “hay ho”, và rằng nghề IT rất thú vị và đầy thử thách. Bọn trẻ sẽ bác bỏ lý do này và chuyển sang cống hiến cho ngành IT.

Phân biết giới tính trong làm việc

Sylvia Ann Hewlett, một nhà kinh tế học tại trung tâm Work-Life Policy tại New York và người sáng lập và giám đốc trung tâm Work-Life Policy, thực hiện một cuộc nghiêng cứu tại Harvard Business Review. Cho thấy rằng trong 41% "technical staff" (bao gồm IT, khoa học và một số ngành kỹ thuật) có nữ, có hơn một nửa rời phòng ở tuổi 40. Và kết luận đây là một lý do chính dẫn đến kết luận về sự phân biệt giới và “tăng ca" là bình thường đối với bất kỳ ai trong ngành.
Trong nhiều ngành nghể truyền thống (bác sĩ, luật sư, kế toán, kinh doanh, tiếp thị, vv.) ta thấy sự gia tằng số phụ nữ, điều này đã làm cho giới tính ngày càng cân bằng, đánh đổ phân biệt giới.
Phụ nữ có thể tồn tại và vượt qua rào cảng giới trong cả ngành IT và tất cả các ngành khác bởi vì họ luôn khao khát được làm việc. Và họ hoàn toàn có khả năng đối diện và đánh đổ sự phân biệt giới để làm việc. Vì vậy sự sụt giảm của nữ trong ngành IT không thể giải thích bằng lý do phân biệt giới.

* Vậy đâu là giải pháp cho vấn đề trên? Hãy cùng tôi tìm hiểu trong bài viết sau.

Đọc tiếp >>

Dojo hỗ trợ JSON-RPC, là tính năng mở rộng của JSON dùng để triệu gọi phương thức từ xa. JSON-RPC có thể dùng như một phương tiện cho các ứng dụng cần giao tiếp với servers. Ví dụ sau sẽ chỉ ra cách tương tác với Java trên server và gọi một phương thức Java từ JavaScript dùng Dojo RPC services. Nó cũng cho thấy việc sử dụng JSON-RPC dễ dàng hơn khi dùng Java.

Đầu tiên, ta tạo một servlet và viết phương thức POST sẽ đọc nội dung của request:

public class JsonRPC extends HttpServlet {
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) 
                throws ServletException, IOException {
         String content = streamToString(req.getInputStream());

Ta dùng json.org’s Java library để phân tích và lấy ra các thuộc tính từ JSON object. Một JSON-RPC object gồm có 3 thuộc tính được định nghĩa để gọi: method, params, và id. Như sau:

JSONObject rpcObject = new JSONObject(content);
        String methodName = rpcObject.getString("method");
        String id = rpcObject.getString("id");
        JSONArray paramsArray = rpcObject.getJSONArray("params");
        Object[] params = new Object[paramsArray.length()];
        for (int i = 0 ; i < paramsArray.length(); i++) {
                params[i] = paramsArray.get(i);
        }

Ta có thể dùng những thuộc tính này để chạy một phương thức trên một object. Nếu ta đã có tạo sẵn một object dùng như một target cho RPC, ta có thể gọi phương thức và thi hành nó:

for (Method method : target.getClass().getMethods()) {
        // we could use getMethod(methodName, paramTypes) here but
        // we would need to create a list of parameters types
        if (method.getName().equals(methodName)) {
                Object result = method.invoke(target, params);
                ...

Sau khi trả kết quả lại cho client. Response object cũng có 3 thuộc tính: id, result, và error. Ta sẽ dùng JSON library để dựng lại object này:

response.put("id",id); // id from the request
        response.put("result",result); // result of the invocation
        response.put("error",JSONObject.NULL); // no error
        // send the response to the client
        resp.getOutputStream().print(response.toString());

Đó là tất cả những gì cần để xây dựng class để gọi JSON-RPC. Cũng có thể dùng try/catch để kiểm soát lỗi:

try {
        ...
        Object result = method.invoke(target, params);
        ...
} catch (Throwable e) {
        response.put("id",id); // id from the request
        response.put("result",JSONObject.NULL);
        response.put("error",e.getMessage());
}

Tôi sẽ tạo một class rất đơn giản để gọi JSON-RPC:

public class Echo {
        public String sayHi(String from) {
                return "Hi " + from;
        }
}

Và hiện thực:

target = new Echo();

Tiếp theo là khai báo một servlet trong file web.xml:

<servlet>
        <servlet-name>JsonRpc</servlet-name>
        <servlet-class>com.sitepen.JsonRPC</servlet-class>
</servlet>
<servlet-mapping>
        <servlet-name>JsonRpc</servlet-name>
        <url-pattern>/jsonrpc/</url-pattern>
</servlet-mapping>

Gọi phương thức với Dojo

Trên client side, chúng ta có thể dùng simple method description (SMD) object để khai báo JSON-RPC và Dojo sẽ tạo phương thức thích hợp.

dojo.require("dojox.rpc.Service");
dojo.require("dojox.rpc.JsonRPC");

echoService = new dojox.rpc.Service({
        envelope:"JSON-RPC-1.0",
        transport:"POST",
        target:"/jsonrpc/echo",
        services:{
                sayHi:{
                        parameters:[{type:"string"}] // this is optional
                }
        }
});

Giờ thì echo đã có phương thức sayHi thi hành tương ứng với phương thức trên Echo class. Chúng ta có thể gọi sayHi chỉ với một phương thức trên JavaScript. Tham số sẽ bao gồm trong JSON-RPC và dùng để gọi phương thức trên server. Ví dụ:

var deferred = echoService.sayHi("Kris");

Thi hành sayHi với đối số “Kris”. Giá trị trả về là Deferred object, và bạn có thể dùng bình thường, hay dùng callback:

deferred.addCallback(function(result) {
    alert(result); // executed when the RPC is finished
});

Khi RPC response được trả về, callback function sẽ trả kết quả trên alert. Và “Hi Kris” hiện ra.

Multiple Target Objects

Chúng ta đã thực hiện xong phần triệu gọi RPC cho một object. Ta cũng có thể thực hiện cho nhiều objects. Một trong những điều kiện để có thể dùng multiple objects là tạo nhiều URL paths cho các target objects:

static Map rpcTargets = new HashMap();
public static void registerRpcTarget(String path, Object target) {
        rpcTargets.put(path,target);
}

Sau đó là tìm đến target objects bằng URL path:

String targetPath = req.getPathInfo();
        Object target = rpcTargets.get(targetPath);

Thêm một target objects là vần đề đơn giản nhất. Cho echo object, ta có thể khai báo như sau:

registerRpcTarget("/echo",new Echo());

Còn nếu bạn đã tạo một object mới, khai báo theo cấu trúc:

registerRpcTarget("/myObject",new MyClass());

Và thêm vào client side một service object khác từ SMD:

myObject = new dojox.rpc.Service({
        envelope:"JSON-RPC-1.0",
        transport:"POST",
        target:"/jsonrpc/myObject",
        services:{
                foo:{
                        parameters:[{type:"string"}] // this is optional
                }
        }
});

Bạn có thể download đầy đủ source tại đây. Chúc thành công!

Đọc tiếp >>

Bài viết này, chúng ta cùng tìm hiểu ưu và nhược điểm của Dependency Injection (DI - “tiêm ” phụ thuộc) với một số cách khác nhau dùng Abstract Factory design pattern. Đặt trong ngữ cảnh của một số vấn đề như: Tạo stateful objects với tham số, điều khiển kiểm tra exceptions khi tạo object, và gắn động các objects. Mà các IoC frameworks, như Spring IoC container, PicoContainer và Guice, không đưa ra giải pháp tốt nhất cho các trường hợp này.

Abstract Factory Design Pattern cho Dependency Injection

GoF* Abstract Factory design pattern được tóm gọn theo 2 bước:
Một factory interface thay thế cho một class abstract factory (Optional),
Mọi factory method chịu trách nhiệm tạo một object và tiêm phụ thuộc vào nó.
Xét ví dụ đơn giản sau:

ComponentA phụ thuộc vào ComponentB. Để có thể unit-testing class ComponentAImpl, hiện thực của interface ComponentB phải tiêm vào ComponentAImpl. Đoạn code sau minh hoạ cách dùng Abstract Factory design pattern để tiêm phụ thuộc.

//Abstract Factory for Dependency Injection
//Factory interface
public interface Module1ServiceFactory {

ComponentA getComponentA();

ComponentB getComponentB();
}

//Concrete factory
public class Module1ServiceFactoryImpl implements Module1ServiceFactory {

private ComponentA componentA;
private ComponentB componentB;
private Module1Servicefactory instance;

private Module1ServicefactoryImpl() {
}

public static synchronized Module1ServiceFactory getInstance() {
   if (null == instance) {
       instance = new Module1ServicefactoryImpl();
       componentA = new ComponentAImpl();
       componentB = new ComponentBImpl();
       componentA.setComponentB(componentB);
   }
   return instance;
}

public ComponentA getComponentA() {
   return componentA;
}

public ComponentB getComponentB() {
   return componentB;
}
}

//Client
public class Client {

public static void main(String[] args) {
   Module1ServiceFactory m1sf =
           Module1ServicefactoryImpl.getInstance();
   ComponentA componentA = m1sf.getComponentA();
   componentA.operationA1();
}
}

Lazy-instantiation

Lazy-instantiation có thể thực hiện bàng cách thay đổi phương thức để có thể xem như objects đã được tạo và chỉ lấy ra khi cần. Để làm điều này, getComponentA() có thể chỉnh lại như sau:

public synchronized ComponentA getComponentA() { if (null == componentA) { componentA = new ComponentAImpl(); } return componentA; }

Dĩ nhiên Module1ServiceFactoryImpl.getInstance() phải được sửa lại không tạo objects.
Ta có thể thêm parameter cho Module1ServiceFactoryImpl .getInstance() để cho biết nó có cần tạo objects hay không.

Non-Singleton Scope

Đoạn code trên sẽ tạo singleton objects. Nếu một object mới chỉ cần khi gọi phương thức getComponentA() và getComponentB(), thì ta sửa lại như sau:

//Concrete factory
public class Module1ServiceFactoryImpl {
   private Module1ServiceFactory instance;

   private Module1ServiceFactoryImpl() {}

   public static synchronized Module1ServiceFactory getInstance() {
           if (null == instance) {
                   instance = new Module1ServiceFactoryImpl();
           }

return instance;
   }

   public ComponentA getComponentA() {
           ComponentA componentA = new ComponentAImpl();
           ComponentB componentB = getComponentB();
           componentA.setComponentB(componentB);
           return componentA;
   }


   public ComponentB getComponentB() {
           return new ComponentBImpl();
   }
}

Ta có thể tiêm một singleton object vào một non-singleton object. Ví dụ, nếu ComponentB là một singleton, và ComponentA là một non-singleton, ta có thể làm như sau:

//Concrete factory
public class Module1ServiceFactoryImpl {
   private Module1ServiceFactory instance;
   private ComponentB componentB;

   private Module1ServicefactoryImpl() {}

   public static synchronized Module1ServiceFactory getInstance() {
           if (null == instance) {
                   instance = new Module1ServiceFactoryImpl();
                   componentB = new ComponentBImpl();
           }

return instance;
   }

   public ComponentA getComponentA() {
           ComponentA componentA = new ComponentAImpl();
           componentA.setComponentB(componentB);
           return componentA;
   }

   public ComponentB getComponentB() {
           return componentB;
   }
}

Ngược lại ta cũng có thể tiêm một non-singleton object cho một singleton, tuy nhiên trường hợp này rất ít gặp.

Tạo Local Stateful Objects với tham số cho Singletons

Đây là vấn đề đặt trưng cho tất cả các IoC frameworks. Được minh hoạ bằng phương thức cho ComponentA singleton:

public void operationA2() {
           String s = aPrivateMethod();
           int i = anotherMethod();
           ComponentC componentC = new ComponentCImpl(s, i);
           //do something else.
   }

Ở đây, ComponentAImpl dùng ComponentC. Hiển nhiên là chúng ta cần tiêm cho nó một hiện thực của ComponentC là ComponentCImpl. Tuy nhiên, chúng ta không thể tạo biến componentC khi nó là một stateful object với trạng thái chỉ dùng được trên client và sẽ không thể dùng trong clients khác thông qua threads. Vậy, nó không thể tiêm dùng setter hay constructor.
Có 2 giải pháp để giải quyết vấn đề này dùng Abstract Factory pattern. In both schemes, chúng ta cần thay đổi Module1ServiceFactory và thêm một tham số cho factory method:

ComponentC getComponentC(String s, int i);

Và hiện thực phương thức này trong Module1ServiceFactoryImpl:

public ComponentC getComponentC(String s, int i) {
           return new ComponentCImpl(s, i);
   }

Giải pháp thứ nhất là tiêm factory object vào class có local stateful objects cần:

private Module1ServiceFactory factory;
   public void setModule1ServiceFactory(Module1ServiceFactory factory) {
           this.factory = factory;
   }

ComponentAImpl.operationA2() trở thành:

public void operationA2() {
           String s = aPrivateMethod();
           int i = anotherMethod();
           ComponentC componentC = factory.getComponentC(s, i);
           //do something else.
   }

Bất lợi của cách này là ComponentAImpl phụ thuộc vào Module1ServiceFactory và chúng ta cần cung cấp một mock hiện thực Module1ServiceFactory để unit-test ComponentAImpl. Mặc dù có nhược điểm như vậy, nhưng tiêm factory object vào một class dùng trong việc tạo local stateful objects là đơn giản nhất. Và được dùng nhiều nhất trong J2EE technology. Ví dụ, trong JPA (Java Persistence API), một entity manager factory có thể tiêm vào code, và một application-managed entity manager được tạo từ entity manager factory.
Cách thứ 2 để tạo local stateful objects là chuyển phương thức sang abstract class, có thể dùng trong unit-tested, và có objects phụ thuộc cụ thể trong subclass.

public abstract class AbstractComponentA implements ComponentA {
public void operationA2() {
           String s = aPrivateMethod();
           int i = anotherMethod();
           ComponentC componentC = getComponentC(s, i);
           //do something else.
   }

   public abstract ComponentC getComponentC(String s, int i) ;

}

public class ComponentAImpl extends AbstractComponentA {
   public ComponentC getComponentC(String s, int i) {
           return new ComponentCimpl(s, i);
   }

}

Cách này được dùng nhiều trong Method Injection của Springframework chỉ hỗ trợ trường hợp không cần tham số khi tạo stateful objects. Unit-testing code không cần hiện thực mock factory. Tuy nhiên, đó là một giải pháp nguy hiểm. Giả sử chúng ta có 10 local stateful objects trong, chúng ta cần 10 abstract methods cho mục đích dùng unit-testing. Đúng là có thể dùng unit-testing và dùng rất đơn giản – at the expense of cluttered application code.
Springframework đưa ra phương thức có thể giải quyết vấn đề này dùng Java reflection. Nhưng nó là một cách rất phức tạp và không phù hợp cho một application bình thường.

Kiểm tra Exceptions Thrown khi tạo Object

Đây là vấn đề mà một IoC container thường làm không tốt. Nếu kiểm tra exceptions được tung ra trong quá trình tạo object, ứng dụng có thể muốn bắt và thu lại. Lấy ví dụ một web service client, nếu web service chưa được tạo khi client gọi, client có thể bắt exception mà nó tung ra, hiện messages phù hợp và đề nghị thực hiện lại. Trường hợp này khó cho IoC containers để tung ra lổi đã được khai báo trong ứng dụng. Factories có thể dể dàng điều khiển trạng thái – chúng ta có thể đơn giản khai báo exceptions cần kiểm tra và tung lổi trong factory methods và cho phép application code điều khiển và thu lại ngay tại đó.

Gắn linh động

Là trường hợp có nhiều hiện thực khác nhau của cùng một interface cần tiêm vào một object khác nhau. Một ví dụ hay là Strategy design pattern. Một tham số có thể dùng để cho biết class cụ thể nào cần được tiêm. Trường hợp này khó hiện thực theo kiểu tiêm phụ thuộc trong file XML hỗ trỡ trong IoC containers, chỉ đơn giản cung cấp một cách để lắp các objects theo cách tĩnh. Lập trình IoC containers có thể cho phép giải quyết cấn đề phụ thuộc động. Tuy nhiên, tiêm phụ thuộc bằng tay với Abstract Factory cung cấp một cách đơn giản nhất và và là một giải pháp đơn giản nhất trong trường hợp này, như ta thấy trong ví dụ sau:

//Concrete factory
public class Module1ServiceFactoryImpl {
   ...

   public ComponentA getComponentA(int strategy) {
           ComponentA componentA = new ComponentAImpl();
           ComponentB componentB = getComponentB(strategy);
           componentA.setComponentB(componentB);
           return componentA;
   }


   public ComponentB getComponentB(int strategy) {
           switch(strategy) {
                   case STRATEGYA:
                           return new StrategyA();
                   case STRATEGYB:
                           return new StrategyB();
                   default:
                           return null;
                   }
   }
}

Trong ví dụ này, cả StrategyA và StrategyB đều là hiện thực của interface ComponentB.

Tổng kết

Các trường hợp đã được đưa ra cho vấn đề tiêm phụ thuộc với Abstract Factory design pattern bao gồm tạo local stateful objects từ tham số động, điều khiển kiểm tra exceptions trong quá trình tạo object, và gắn linh động. Bên cạnh đó, vấn đề là một cách tốt nhất để so sánh với các IoC containers từ dùng Java code và gắn cứng (XML). Bất lợi ở chổ developers cần viết nhiều code hơn để bắt đầu. Một hạn chế khác là hiện thực của factory code thay đổi đáng kể nếu chúng ta đổi giựã lazy-initialization và eager-initialization hay từ singletons đến non-singletons. Tuy nhiên, nó có thể chứng tỏ rằng it is rare that we need to make these kinds of changes.
Vấn đề chính là cho phép unit-testing là lập trình dùng interfaces để classes không dựa vào classes cụ thể trong ứng dụng. Để mock objects có thể tiêm vào một class khi test và thi hành tất cả sự phụ thuộc.
Phụ thuộc đã được giải quyết, theo một cách nào đó trong ứng dụng. Một ý tưởng thường thấy phía sau tất cả IoC containers và các giải pháp cho DI là phụ thuộc được giải quyết theo cách dể hình dung – XML configuration files (Spring IoC), đặc biệt Java classes (Google Guice), hay factory classes cụ thể. Trong trường hợp này, chúng ta tránh sự lan rộng của phụ thuộc thông qua code ứng dụng và một ít class cụ thể có thể dễ dàng. Mock objects có thể dùng để unit-testing.
Và cuối cùng, với IoC containers, chúng ta loại trừ phụ thuộc vào classes cụ thể và có thể tạo unit-testing, theo cách mà họ cung cấp – thông qua các thirty-party APIs hay cấu hình trên file XML. Khi không có một chuẩn cho IoC containers và mổi framework cung cấp các tính năng và chức năng khác nhau chung quanh vấn đề tiêm phụ thuộc, thì ta khó mà thay thế một IoC framework để dùng một cái khác.

*GoF: Gang of Four. Người ta thường gọi quyển sách Design Patterns: Elements of Reusable Object-Oriented Software với cái tên này vì có 4 tác giả viết nó.

Dịch từ TheServerSide

Đọc tiếp >>

Làm thế nào để biết được thế giới này đang có những gì, và cần gì?

Làm sao để lựa chọn một công nghệ web cho dự án mà mình đang tiến hành?

Dùng media player nào? Flex hay Silverlight?

Dùng ngôn ngữ nào? Java, .Net hay PHP?

Và còn rất nhiều câu hỏi mà để tìm ra câu trả lời thì cần có một khoảng thời gian gắn bó, hay chỉ đơn giản là tìm kiếm trên một số websites hữu ích. Bạn chọn cách nào?

Với tôi thì vấn đề ngôn ngữ là dễ dàng, vì tôi chỉ chọn Java। Nhưng dùng frameworks nào? JSP, Servlet, Struts, JSF, Spring MVC... thì cũng khá là đau đầu.

Các blogs sau sẽ cung cấp một số kiến thức bổ ích về thế giới Internet.

1. Smashing Magazine

Smashing Magazine là một trong những nơi để tìm một mẫu thiết kế hay ít nhất là ý tưởng. Mỗi bài viết là một bìa học về thiết kế web và phát triển, và là một blog không thể thiết đối với một web designer.

2. Ajaxian

Có ai đó nói rằng: “nếu bạn biết Javascript, thì bạn đã biết 80% về Ajax”. Thì Ajaxian phần lớn các bài viết nói về Javascript, và các thư viện Javascript như Dojo hay JQuery. Cường độ post bài là 5 đến 10 mỗi ngày, thì đây là một trang đáng xem đối với các Web 2.0 Developer.

3. ReadWriteWeb

Mọi thứ diễn ra trong thế giới internet, bạn đều có thể tìm thấy trên ReadWriteWeb. Nếu bạn là một nhà kinh doanh trên internet hay xây dựng websites, thì đây là blog sẽ đem đến cho bạn một kiến thức bổ ích cho công việc. Được xây dựng một cách bài bản, với số lượng bài đều đặn, blog này đang có một thứ hạng cao với PC World’s Top 100 và Technorati’s Top 20.

4. Adam Bien’s Blog

Bài viết là những nhận xét về kỹ thuật, vấn đề mắc phải, tutorial về JavaEE và mọi thứ liên quan đế Sun. Là một địa chỉ không thể thiếu đối với những Java EE Developer.

5. Flex Examples

Flex là một framework đang được dùng khá phổ biến trong Rich Internet Application – Nói đến các ứng dụng web có tính năng và đặc tính như một ứng dụng trên máy desktop- (RIA). Đây là một framework hay, nhưng cũng có nhiều thứ khó có thể làm theo ý mình. Flex Examples sẽ giúp bạn giải quyết các vướng mắc khi sử dụng bằng các tutorials nhằm giải quyết các vấn đề. Nếu bạn là một Flex developer, bạn không thể bỏ qua blog này.

6. Vitamin

Được viết theo kiểu “how-to” tutorials chung quanh các vấn đề về thiết kế và hiện thực websites. Mỗi tutorial được trình bày một cách rỏ ràng theo một ngôn từ dễ hiểu. Họ được nhận giải SXSW Award 2007 Best Education Resource - nơi tốt nhất để học tập.

7. Agile Ajax

AJAX đang đóng một vai trò lớn trong phát triển web. Agile Ajax viết về các tutorials và các đoạn code hữu ích cho Javascript developer. Bên cạnh tutorials, họ còn có các bình luận về sách.

8. Slashdot

Đây cũng là một trong những blog chuyên về các tin tức công nghệ rất được yêu thích. Bạn cũng có thể tìm thấy những comment rất thẳng thắn và thú vị ở đây.

9. TechCrunch

Với xứ mệnh tìm kiếm các thông tin và bình luận về các công ty và sản phẩm internet. Tìm ra xu hướng và các công ty hứa hẹn đem đến một nét mới cho internet. Người sáng lập ra blog này là luật sư Michael Arrington. Những mối quan hệ của Arrington đã mang tới cho blog những tin tức mới nhất trước khi phần còn lại của thế giới biết đến.

10. A List Apart

Những bài viết mà tôi mong chờ ở họ bao gồm web-standards, best practices, accessibility, và usability. Những bài viết của ALA có chất lượng rất tốt và họ chỉ post khoảng 2 bài một tháng, nhưng cũng đáng để chờ. Được viết bởi những người có uy tín trong ngành, trong đó có Eric Meyer và Jeffrey Zeldman.

Hi vọng các bạn có thể học được nhiều điều từ các websites trên. Và tất nhiên, sự thiếu nếu có thêm một site nào hay thì có thể chia sẽ trong comment

Đọc tiếp >>