Mẫu Type Object pattern có 2 lớp cụ thể, một biểu diễn các đối tƣợng và lớp còn lại biểu diễn kiểu của chúng. Mỗi đối tƣợng có một con trỏ tới kiểu tƣơng ứng của nó.
Hình 4.13. Sơ đồ lớp, đối tượng mẫu Type Object
TypeClass (Movie)
Là một lớp của đối tƣợng kiểu (TypeObject)
Có một thực thể riêng rẽ cho mỗi kiểu của đối tƣợng
TypeObject (Star Wars, The Terminator, Independence Day) Là một bản thể của TypeClass
Biểu diễn một kiểu của đối tƣợng. Thiết lập tất cả các thuộc tính của một đối tƣợng mà tƣơng tự cho tất cả các đối tƣợng của cùng kiểu.
Class (Videotape)
Là lớp của đối tƣợng
Biểu diễn các thực thể của của TypeClass Object (John’s Star Wars, Sue’s Star Wars) Là một bản thể của lớp
Biểu diễn một hạng mục duy nhất mà có một ngữ cảnh duy nhất. Thiết lập tất cả các thuộc tính của các hạng mục đó mà có thể phân biệt giữa các hạng mục của cùng kiểu.
Có một TypeObject kết hợp mà mô tả kiểu của nó. Ủy thác các thuộc tính đƣợc định nghĩa bởi kiểu của nó cho TypeObject của nó.
TypeClass và Class là các lớp. TypeObject và Object là các bản thể của lớp tƣơng ứng. Vì với bất kỳ bản thể nào, một TypeObject hay Object biết lớp của nó là gì. Thêm vào đó, một Object có một con trỏ tới TypeObject của nó cốt để nó biết TypeObject của nó là gì. Object đó sử dụng TypeObject của nó để xác định các cƣ xử kiểu của nó. Khi Object đó nhận yêu cầu mà xác định kiểu nhƣng không xác định thực thể, nó ủy thác các yêu cầu đó cho TypeObject của nó. Một TypeObject cũng có thể có
một Object có một con trỏ tới TypeObject của nó, John’s videotape và Sue’s videotape có các con trỏ tới Movie tƣơng ứng, mà trong trƣờng hợp này là Star War cho cả hai viedeotape. Đó là làm thế nào các videotape biết rằng chúng chứa StarWar và không phải một số movie khác.
Sự cộng tác:
Một Object nhận 2 loại yêu cầu: chúng đƣợc xác định bởi bản thể của nó và đƣợc xác định bởi kiểu của nó. Nó xử lý các yêu cầu bản thể bản thân nó và ủy thác các yêu cầu kiểu cho TypeObject của nó.
Một số client có thể muốn tƣơng tác trực tiếp với TypeObject. Chẳng hạn, thay vì lặp lại thông qua tất cả các Videotape mà cửa hàng có trong kho, ngƣời thuê có thể muốn xem qua tất cả các Movie mà cửa hàng đề xuất.
Nếu cần thiết, TypeObject có thể có một tập các con trỏ tới các Object của nó. Theo cách này, hệ thống có thể dễ dàng tìm đƣợc một Object mà phù hợp với mô tả của TypeObject. Điều này sẽ tƣơng tự với tất cả các tin nhắn của các bản thể mà các lớp Smalltalk thực thi. Cho ví dụ, khi một ngƣời thuê tìm một Movie lôi cuốn, anh ta có thể sau đó muốn biết videotape nào mà cửa hàng có mà phù hợp với mô tả.
Các thuận lợi của Type Object pattern:
Việc tạo ra lớp thực thi. Mẫu cho phép các lớp mới đƣợc tạo ra tại lúc thực thi. Các lớp này không thực sự là các lớp, chúng là các bản thể đƣợc gọi là TypeObject mà đƣợc tạo ra bởi TypeClass chỉ giống nhƣ bất kỳ bản thể nào đƣợc tạo ra bởi lớp của nó.
Tránh sự bùng nổ các lớp con. Hệ thống có thể cần nhiều lớp con để biểu diễn các kiểu khác nhau của các Object. Thay vì số lƣợng lớn các lớp con, hệ thống có thể sử dụng một TypeClass và một lƣợng lớn các TypeObject.
Ẩn sự tách biệt của thực thể và kiểu. Một client của Object không cần quan tâm sự tách biệt giữa Object và TypeObject. Client tạo yêu cầu của Object, và Object lần lƣợt quyết định yêu cầu nào về phía TypeObject. Client mà quan tâm tới các TypeObject có thể cộng tác trực tiếp với chúng mà không phải đi qua các Object.
Thay đổi kiểu động. Mẫu cho phép Object thay đổi một cách động TypeObject của nó mà có ảnh hƣởng của sự thay đổi lớp của nó. Điều này đơn giản hơn việc biến đổi một đối tƣợng thành một lớp mới.
Việc phân chia lớp con một cách độc lập. TypeClass và Class có thể đƣợc tạo lớp con một cách độc lập.
Các đối tƣợng đa kiểu. Mẫu cho phép một Object có đa TypeObject, ở đó mỗi cái xác định một số phần của kiểu của Object. Object phải sau đó quyết định cách cƣ xử kiểu nào để ủy thác cho TypeObject nào.
Các bất lợi của Type Object pattern:
Việc thiết kế phức tạp. Mẫu đại diện một đối tƣợng logic trong 2 lớp. Mối quan hệ của chúng, một thứ và kiểu của nó, sẽ khó để hiểu. Điều này gây bối rối cho những ngƣời làm mô hình cũng nhƣ ngƣời lập trình. Khó để nhận ra hay giải thích mối quan hệ giữa một TypeObject và một Object. Điều này sẽ gây khó hăn cho việc đơn giản hóa và khả năng bảo trì. Nói theo cách ngắn gọn, sử dụng sự thừa kế, nó sẽ dễ dàng hơn.
Sự thực thi phức tạp. Mẫu loại bỏ sự thực thi khác nhau ra khỏi các lớp con và đƣa vào trạng thái của các bản thể TypeClass. Trong khi mỗi lớp con có thể thực thi một phƣơng thức khác nhau, bây giờ TypeClass có thể chỉ thực thi phƣơng thức một cách và mỗi trạng thái TypeObject phải tạo bản thể cƣ xử khác nhau.
Việc quản lý tham chiếu. Mỗi Object phải giữ một tham chiếu tới TypeObject của nó. Chỉ khi một object biết lớp của nó là gì, một Object biết TypeObject của nó là gì. Nhƣng khi hệ thống đối tƣợng hay ngôn ngữ thiết lập tự động và bảo trì mối quan hệ lớp – thực thể, ứng dụng phải tự nó thiết lập và duy trì mối quan hệ TypeObject-Object.
Có một số vấn đề mà bạn phải luôn luôn chú tâm khi thực thi mẫu Type Object:
Object tham chiếu TypeObject: mỗi Object có một tham chiếu tới TypeObject của nó và ủy thác một số trách nhiệm của nó cho TypeObject. Một Object và TypeObject phải đƣợc xác định khi Object đƣợc tạo ra.
Các cƣ xử Object và TypeObject: một cƣ xử Object có thể hoặc đƣợc thực thi trong lớp của nó hoặc có thể đƣợc ủy thác cho TypeObject của nó. TypeObject thực thi cách cƣ xử thông dụng đổi với kiểu trong khi Object thực thi cách cƣ xử mà khác nhau cho mỗi bản thể của một kiểu. Khi Object ủy thác cách cƣ xử cho TypeObject của nó, nó có thể chuyển tiếp một tham chiếu tới bản thân nó cốt để TypeObject có thể truy cập dữ liệu của nó hay cách cƣ xử. Object đó có thể quyết định thực hiện các phép toán mở rộng trƣớc và sau khi chuyển tiếp yêu cầu, tƣơng tự nhƣ cách một Decorator có thể mở rộng các yêu cầu nó chuyển tiếp tới Component của nó.
chuyển tiếp tới TypeObject. Object đó không thừa kế thông điệp của TypeObject. Mỗi khi bạn thêm các cƣ xử vào TypeClass, bạn cũng phải thêm một phƣơng thức ủy thác cho Class trƣớc khi cách cƣ xử là sẵn sàng cho các Object.
Hay sử dụng Type Object Pattern trong các mẫu mô hình dữ liệu và thảo luận nó nhƣ là một nguyên lý mô hình. Ông đã sử dụng nó để định nghĩa các kiểu cho các hoạt động, sản phẩm,... và các phần của Material Safety Data Sheet.
Mẫu Power Type của Odell chính là Type Object Pattern. Ông giảit thích nó bằng một ví dụ của loài cây và cây. Một loài cây mô tả một kiểu của cây. Một cây thuộc một loài tƣơng ứng mà mô tả kiểu của cây đó.
Mẫu Type Object tƣơng tự mẫu Strategy và State. Cả 3 mẫu đều chia một đối tƣợng thành các phần và đối tƣợng thực ủy nhiệm cho đối tƣợng mới hoặc Type Object, Strategy hoặc State. Strategy và State thƣờng cƣ xử một cách tinh khiết trong khi Type Object thƣờng giữ rất nhiều trạng thái đƣợc chia sẻ. Stategy thay đổi thƣờng xuyên trong khi Type Object hiếm khi thay đổi. Một Strategy thƣờng có một trách nhiệm chính, trong khi Type Object thƣờng có nhiều trách nhiệm. Vì vậy các mẫu trên không hoàn toàn giống nhau mặc dù sơ đồ đối tƣợng của chúng là tƣơng tự.
Một Object có thể tƣơng tự Decorator với Type Object. Một đối tƣợng và đối tƣợng kiểu của nó có các giao diện tƣơng tự và đối tƣợng đó lựa chọn các thông điệp để chuyển tiếp tới đối tƣợng kiểu của nó. Dẫu sao Decorator không cƣ xử nhƣ là một thực thể của Component.
Type Object có thể xem tƣơng tự nhƣ Flyweight đối với các đối tƣợng của nó. Hai đối tƣợng sử dụng cùng Type Object có thể nghĩ rằng chúng có cùng bản copy của chúng. Nhƣng thay vào đó là chia sẻ cùng đối tƣợng. Nhƣng quan trọng là không đối tƣợng nào thay đổi trạng thái bên trong của Type Object.
4.2. Mẫu thiết kế Ajax
4.2.1. Tổng quan về Ajax
Thế hệ Web 2.0 vừa mới bắt đầu và có lẽ sẽ phải trải qua một chặng đƣờng dài phía trƣớc để có thể làm thay đổi những gì vốn đã trở nên quen thuộc trong giai đoạn hiện nay. Đóng vai trò then chốt trong giai đoạn thứ hai của web là tổ hợp công nghệ AJAX. Những thành công vang dội và sự hấp dẫn kì lạ của Gmail, Google Suggest và Google Maps đã khiến cho Ajax đƣợc chú ý một cách đặc biệt. Dù hiện nay nó chƣa thực sự đƣợc sẵn sàng đón nhận, nhiều ngƣời cho rằng các ứng dụng AJAX sẽ phát triển một cách nhanh chóng.
Thuật ngữ AJAX đƣợc xuất hiện vào ngày 18/2/2005 trong bài báo AJAX: A New Approach to Web Applications của Jesse James Garrett thuộc công ty Adapativeath. Ngay sau đó thuật ngữ AJAX đã nhanh chóng trở lên phổ biến trong
cộng đồng phát triển Web và trở thành trung tâm trong mọi câu chuyện liên quan đến thế hệ Web 2.0.
4.2.2. AJAX là gì
AJAX là viết tắt của cụm từ Asynchronous JavaScript and XML (JavaScript và XML không đồng bộ) [5], là kỹ thuật cho phép tăng tốc độ của các ứng dụng web bằng cách chia nhỏ dữ liệu và chỉ hiển thị những gì cần thiết, thay vì tải đi tải lại toàn bộ trang web. Kỹ thuật kết hợp hai tính năng mạnh của JavaScript đƣợc các nhà phát trển đánh giá rất cao:
Gửi yêu cầu đến máy chủ mà không cần nạp lại trang.
Phân tách và làm việc với XML.
AJAX không phải một công nghệ đơn lẻ mà là sự kết hợp một nhóm công nghệ: CSS , DOM, XMLHttpRequest, JavaScript. Trong đó
Trình bày trang web theo tiêu chuẩn XHTML và CSS;
Biểu diễn động và tƣơng tác bằng DOM (Document Object Model);
Trao đổi và xử lý dữ liệu bằng XML và XSLT;
Truy cập dữ liệu không đồng bộ bằng MLHttpRequest;
Liên kết các công nghệ trên với nhau bằng JavaScript.
4.2.3. AJAX hoạt động như thế nào
Trong ứng dụng web truyền thống, khi cần thay đổi dữ liệu trên trang web, ngƣời dùng tạo ra một yêu cầu HTTP tới server. Server thực hiện một số thao tác xử lý nhƣ lấy dữ liệu, tính toán, thẩm định tính hợp lệ thông tin, sau đó gửi lại một trang web hoàn chỉnh tới client yêu cầu. Tuy nhiên, kỹ thuật này có hạn chế là: khi server đang thực hiện công việc xử lý của mình thì client phải chờ đến khi server xử lý xong thì mới có thể tiếp tục thực hiện các công việc khác.
Để khắc phục hạn chế nêu trên, ngƣời ta đƣa ra một kỹ thuật trung gian, cơ chế Ajax, giữa client và server. Khi đó, các yêu cầu gửi và nhận do AJAX Engine thực hiện. Mọi thao tác ngƣời dùng sẽ gửi lệnh JavaScript tới bộ xử lý Ajax, thay vì tạo ra một truy vấn HTTP tới máy chủ. Nếu cần thông tin từ server, nhƣ tải về bổ sung mã giao diện hay dữ liệu mới cập nhật, AJAX sẽ truyền yêu cầu tới server một cách không đồng bộ, thông thƣờng sử dụng XML, mà không làm gián đoạn sự tƣơng tác của ngƣời dùng với ứng dụng web. Thay vì trả dữ liệu dƣới dạng HTML và CSS trực tiếp cho
Hình 4.14. Ứng dụng web truyền thống (trái) và ứng dụng AJAX
Nhƣ vậy, việc sử dụng cơ chế kỹ thuật Ajax đã làm giảm quá trình “đi lại” của thông tin và thời gian phản ứng. Thay vì tải lại toàn bộ một trang web, nó chỉ nạp những thông tin đƣợc thay đổi, còn các phần khác đƣợc giữ nguyên. Vì thế, ngƣời dùng không gặp hiện tƣợng cửa sổ trắng và biểu tƣợng đồng hồ cát - dấu hiệu khi server đang thực hiện nhiệm vụ.
Hình 4.15. Tương tác đồng bộ trong ứng dụng web truyền thống (trên) và dị bộ trong ứng dụng AJAX.
4.2.4. Các ứng dụng AJAX phổ biến
Hãng Google đã đầu tƣ nhiều vào việc phát triển ứng dụng AJAX. Các ứng dụng của họ gần đây, từ Orkut, Gmail đến phiên bản thử nghiệm Google Groups, đều ứng dụng công nghệ AJAX. Google Suggest hiển thị các thuật ngữ gợi ý gần nhƣ ngay lập tức khi ngƣời sử dụng chƣa gõ xong từ khóa. Với Google Maps, ngƣời dùng có thể xê dịch, kéo thả bản đồ nhƣ trên môi trƣờng desktop.
Yahoo dự định sẽ ra mắt bản Yahoo Mail Beta 1 sử dụng AJAX trên toàn thế giới. Hãng cũng đang xây dựng một công cụ Ajax có thể nhanh chóng cập nhật thông tin về sân bay, chuyến bay, thời gian... phục vụ khách hàng.
Microsoft cũng đang triển khai chƣơng trình Windows Live Mail và Windows Live Messenger hỗ trợ AJAX.
Những ứng dụng trên cho thấy AJAX không phải là một công nghệ quá xa xôi mà đang hiện diện ngay trong thế giới thực, từ mô hình đơn giản nhƣ Google Suggest đến phức tạp nhƣ Google Maps.
4.2.5. Tổng quan về mẫu thiết kế Ajax
Ajax chứa đựng rất nhiều hứa hẹn trong việc thiết kế các ứng dụng web. Hiện tại nó đã đƣợc sử dụng trong nhiều ứng dụng tiêu biểu. Khi Ajax bắt đầu, các mẫu thiết kế đã đƣợc ứng dụng rộng rãi. Mẫu thiết kế giúp cho quá trình phát triển phần mềm trở lên hiệu quả hơn bởi nó đẩy nhanh quá trình lập trình thông thƣờng và loại bỏ nhu cầu viết các mã dƣ thừa qua các dự án. Ajax design pattern đang nổi lên với việc sử dụng ngày càng phổ biến trong việc phát triển các ứng dụng web. Ajax design patters giúp cho ta cách thực hành tốt nhất mà cải tiến một cách nhanh chóng các dự án phát triển ứng dụng web. Nó chỉ cho ngƣời dùng biết làm thế nào để áp dụng các nguyên lý thiết kế một cách hiệu quả trong các ứng dụng web sử dụng công nghệ Ajax.
Có thể đáng ngạc nhiên là đã có nhiều mẫu thiết kế Ajax khi mà thuật ngữ Ajax chỉ mới xuất hiện. Dù sao, các ý tƣởng đó không phải là mới, đã có nhiều phần liên quan Ajax trên web trƣớc khi thuật ngữ đó hình thành để mô tả chúng. Đã có hàng trăm các site mới hiện tại sử dụng Ajax cung với các công cụ mạnh nhƣ RSS, Technorati, Google và Wikis để xác định chúng ngay khi chúng sẵn sàng.
Hiện tại đã xây dựng đƣợc hơn 60 mẫu Ajax đƣợc phân làm 4 nhóm [9]: Foundational Technology, Programming, Functionality and Usability, và Development.
đặc trƣng. Các mẫu này đƣợc xem nhƣ “nguyên tử” trong ngôn ngữ mẫu, theo ý nghĩa là tất cả các mẫu sau đó đƣợc xây dựng trên các kỹ thuật nền tảng này. Để giữ cho các mẫu Ajax đƣợc xúc tích, bạn sẽ chỉ bắt gặp các công nghệ mà thêm những thứ vào việc phát triển web thông thƣờng.
Các mẫu Programming: gồm 23 mẫu. Giải thích làm thế nào các thành phần đƣợc kết hợp theo góc độ bảo trì và thực thi. Chúng là những đặc trƣng về kiến trúc và mã mà thỏa mãn các nguyên lý thiết kế phần mềm. Chúng bao gồm cả những thứ khác nhƣ là việc thiết kế các dịch vụ web, quản lý luồng thông tin giữa trình duyệt và server, định vị DOM khi một phản hồi đến và tối ƣu hóa thực thi.
Các mẫu Functionality and Usability: gồm 28 mẫu, hƣớng dẫn giao diện ngƣời dùng và các khái niệm về khả năng sử dụng. Chúng là những thứ quan trọng với ngƣời dùng, bao gồm widgets và các kỹ thuật tƣơng tác, cấu trúc và duy trì những thứ trên trang web, hiệu ứng trực quan và các chức năng mà Ajax có khả năng.