Sơ đồ lớp này giải thích làm thế nào mỗi bản thể của Videotape có một bản thể của Movie tƣơng ứng. Nó chỉ ra làm thế nào các thuộc tính đƣợc xác định bởi kiểu của videotape đƣợc chia tách từ những thứ mà khác với mỗi videotape nhất định. Trong trƣờng hợp này, tiêu đề phim và giá cho thuê đƣợc chia tách với băng đĩa mà đƣợc cho thuê và ai hiện tại đang thuê nó.
Wars mà John đang thuê và một mà Sue đang thuê. Nó cũng chỉ ra rằng mỗi Videotape biết kiểu của nó bởi vì mối liên hệ của nó đối với một bản thể movie xác định.
Nếu một phim mới, chẳng hạn nhƣ Independence Day đƣợc thuê bởi Jack, hệ thống sẽ tạo một Movie mới và một Videotape mới mà trỏ đến Movie đó. Movie là Independence Day và băng là copy của Independence Day mà Jack đang thuê.
Videotape, Movie và mối quan hệ is-instance-of giữa chúng (a Videotape là một bản thể của một Movie) là một ví dụ của mẫu Type Object. Nó đƣợc sử dụng để tạo các bản thể của một tập các lớp khi số lƣợng các lớp là không biết. Nó cho phép một ứng dụng tạo các lớp mới tại lúc thực thi bởi vì các lớp là các bản thể thực sự của một lớp. Ứng dụng phải sau đó duy trì mối quan hệ giữa các bản thể thực và các lớp của chúng – nhƣ là các thực thể
Vấn đề chính của mẫu Type Object là hai lớp con cụ thể, một lớp mà các thực thể của chúng biểu diễn các bản thể ứng dụng và một lớp mà các bản thể của nó biểu diễn kiểu của các bản thể ứng dụng. Mỗi bản thể ứng dụng có một con trỏ tới kiểu tƣơng ứng của nó.
Sử dụng mẫu Type Object khi:
Các bản thể của một lớp cần đƣợc nhóm cùng nhau dựa theo các thuộc tính hay cách cƣ xử thông dụng của chúng.
Một lớp cần một lớp con cho mỗi nhóm để thực thi các cách cƣ xử/ thuộc tính thông dụng của nhóm đó.
Một lớp yêu cầu một số lƣợng lớn các lớp con hay sự đa dạng tổng thể của các lớp con có thể đƣợc yêu cầu mà k đƣợc biết.
Bạn muốn có thể tạo các nhóm mới tại lúc thực thi mà không đoán trƣớc đƣợc trong quá trình thiết kế.
Bạn muốn có thể thay đổi một lớp con của đối tƣợng sau khi nó đƣợc khởi tạo mà không phải biến đổi nó thành một lớp mới.
Bạn muốn có thể xếp các nhóm một cách đệ quy cốt để một nhóm bản thân nó là một hạng mục trong một nhóm khác.
Hình 4.12. Sơ đồ lớp mẫu Type Object
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