RIA Architecture

VẤN ĐỀ GIAO TIẾP TRONG KIẾN TRÚC MODULE

2009-10-09T20:37:00.000-07:00

Đây là bài viết gốc chưa được chỉnh sửa so với bài trên PC World 06/2009.

Giới thiệu về lập trình theo kiến trúc module (Modular programming)

Lập trình theo kiến trúc module là kĩ thuật chia nhỏ phần mềm thành những phần tách biệt nhau gọi là module. Các module được kết nối với nhau bằng một cấu trúc đơn giản và có thể được phát triển một cách độc lập.

Để bảo đảm tính toàn vẹn của cấu trúc, kiến trúc module cần được duy trì và thực hiện xuyên suốt khi tạo kiến trúc hệ thống, thiết kế, coding. Một số ngôn ngữ hỗ trợ lập trình theo cơ chế module còn cho phép biên dịch các module một cách độc lập và có thể gắn kết vào hệ thống vào thời điểm runtime như Flex, Ruby… Một số ngôn ngữ khác thì hỗ trợ cơ chế như thư viện liên kết động (như dll) để biên dịch các module thành các thư viện độc lập và có thể gắn kết động vào hệ thống. Kiến trúc module cũng dễ dàng áp dụng đối với các ngôn ngữ lập trình web.

Figure 1 : Phân rã phân mềm thành các module được nối kết với nhau

Tại sao lại nghiên cứu và sử dụng kiến trúc module

Về mặt khái niệm, kĩ thuật module cho phép chia nhỏ bài toán (hay yêu cầu) của phần mềm thành các phần hầu như không trùng lắp và do đó hỗ trợ làm việc song song trên các module và đặc biệt là dễ bảo trì hơn (maintainability). Kiến trúc module cũng là chìa khóa để đạt tới các khả năng tái sử dụng các thành phần của hệ thống (reusability) và khả năng mở rộng tốt hơn (extendibility).

Những ví dụ dễ thấy của kiến trúc module là các môi trường như Eclipse, Visual Studio. Chúng được tạo ra như những nền tảng cơ bản trong đó việc support các ngôn ngữ như Java, C#… được tổ chức như các plugin và có thể dễ dàng gắn vào nền tảng. Chúng ta cũng có thể thấy công cụ Visual Studio đi kèm các bộ SQL Professional để hỗ trợ các project của SQL server dưới tên khác là SQL Server Business Intelligence Development Studio. Việc tổ chức như thế thậm chí còn cho phép các nhà phát triển thứ 3 dễ dàng phát triển các tính năng mở rộng, như bổ sung hỗ trợ PHP vào Visual Studio qua plugin VS.Php.

Các ứng dụng web như các CMS Joomla, Drupal cũng được xây dựng trên nền tảng module và do đó dễ dàng cho cộng đồng cùng phát triển và dễ mở rộng.

Figure 2: Joomla framework from joomla.org

Kiến trúc module có thể mở rộng để áp dụng ở mức hệ thống và các module có thể là các ứng dùng hay service chạy song song và tương tác với nhau thông qua một kiểu giao tiếp nào đó như Messaging, RPC, Socket, file…

Về mặt ý tưởng, kiến trúc module có thể xem là nền tảng cơ bản của rất nhiều kiến trúc tiên tiến khác nhu MVC, Multi-tier, SOA... Hơn nữa, kiến trúc module có thể tái áp dụng vào các module của chính nó hay các thành phần con của các kiến trúc trên như các service bên trong các hệ thống SOA.

Interface – công cụ giao tiếp của các module

Các module được gắn kết với nhau trong chương trình thông qua các “interface”. Một interface của module mô tả những thành phần được cung cấp và cần được cung cấp của module. Các thành phần này này được các module khác thấy và sử dụng.

Lưu ý là khái niệm interface ở đây khác biệt với khái niệm “interface” của các ngôn ngữ như Java, C#. Các interface của các module thường được thiết kế theo tiêu chí sao cho các quan hệ phụ thuộc giữa các module là nhỏ nhất có thể.

Để hoàn thiện khái niệm interface, David Parnas – người đi tiên phong về lĩnh vực kiến trúc phần mềm – đã đưa ra khái niệm Information-hidding. Khái niệm này đã được dùng như nền tảng cơ bản cho những nghiên cứu sau này.

Information-hiding (Parnas)

Information hiding là khái niệm đóng gói và ẩn đi những thiết kế của chương trình mà chúng hầu như sẽ thay đổi.

Trong kiến trúc module, theo nguyên lý Information-hiding, do những phần có khả năng thay đổi bên trong của module đã được ẩn đi nên những phần còn lại dùng để giao tiếp giữa các module sẽ không bị ảnh hưởng khi thay đổi thiết kế. Kết quả là những module có thể thay đổi một cách độc lập mà không ảnh hưởng lẫn nhau. Ví dụ, khi chúng ta muốn xây dựng một ứng dụng mà hỗ trợ nhiều cách lưu trữ dữ liệu khác nhau, thậm chí có thể mở rộng bổ sung trong tương lai thì cách tốt nhất là ẩn đi những xử ly lưu trữ cụ thể và chỉ dùng một giao diện chung đơn giản cho chúng. Như vậy theo Parmas, interface của module nên được thiết kế chỉ bao gồm những phần hầu như không thay đổi, những thành phần này được gọi là thành phần “công khai”. Còn những chi tiết ẩn dấu bên trong bởi interface thường được gọi là các thành phần “bí mật” hoặc “riêng tư”.

Figure 3 : Một module giống như một tảng băng có bề nổi là interface của chính nó

Trong .Net framework, những thành phần bí mật được sử dụng nội bộ bên trong các lớp thư viện của framework được khai báo bằng từ khóa “Internal”. Các thành phần “internal” của .Net không thể truy cập trực tiếp từ bên ngoài assembly của chúng cho dù chúng ta biết rõ mô tả của chúng. Tuy nhiên, trong một số trường hợp chúng ta muốn sử dụng một số tính năng cấp thấp hoặc sửa lỗi của framework nên buộc phải truy cập vào các thành phần này, một kĩ thuật thường dùng là Reflection.

Trong các mẫu lập trình (pattern), có một mẫu được tổ chức theo tư tưởng trên và được dùng rất phổ biến, đó là Façade pattern.

Façade pattern

Façade pattern là một mẫu thiết kế lập trình thường được dùng trong lập trình hướng đối tượng. Một façade là một object cung cấp một giao diện đơn giản ra bên ngoài cho một phần code lớn hơn như là các lớp thư viện bên trong. Một façade có thể:

o Làm cho một thư viện phần mềm dễ dàng hiểu và dễ sử dụng hơn vì façade cung cấp phương tiện đơn giản hơn để truy cập những tác vụ thông thường (thay vì thao tác qua nhiều lớp thư việc phức tạp).

o Giảm sự phụ thuộc giữa code bên ngoài và code thực thi bên trong thư viện, vì thế cho phép phát triển hệ thống một cách mềm dẻo hơn.

o Được dùng như một cách để gói gọn một tập hợp API có sẵn được tổ chức không tốt bằng một tập API đơn giản hơn nhiều để phục vụ cho một vài tác vụ nhất định.

Figure 4 : Một ví dụ về Facade pattern

Façade pattern thường kết hợp với Singleton pattern để tố chức lớp façade theo dạng singleton. Ngoài ra, Façade pattern đặc biệt phù hợp trong mô hình 3-tier qua cách định nghĩa các giao tiếp đơn giản để tương tác giữa các tier, nhờ đó ẩn đi các xử lý phức tạp nội bộ bên trong. Nó còn được áp dụng rất phổ biến trong .NET Framework theo mô hình thiết kế component-oriented. Một trong những façade thường được sử dụng trong .NET 2.0 là “System.Web.Mail.SmtpMail”. Lớp này cung cấp cho người dùng một giao tiếp đơn giản để gửi mail thông qua giao thức Smtp mà không phải quan tâm đến các thao tác xử lý phức tạp bên trong.

Tuy nhiên, việc sử dụng các lớp façade trong một thư viện cần được xem xét cẩn thận. Vì các façade, bản thân chúng, cung cấp một giao tiếp ở mức cao cho những chi tiết bên trong nên nếu không được thiết kế tốt, chúng sẽ hạn chế những tính năng của thư viện khi người dùng không thể truy cập đến những chi tiết ở mức thấp bị ẩn đi.

Inversion of control

Inversion of Control, hay IoC, là một nguyên lý thuộc lĩnh vực thiết kế kiến trúc phần mềm trong đó mô tả luồng điều khiển của hệ thống bị đảo ngược so với kiến trúc cổ điển.

Theo mô hình lập trình cổ điển, lập trình viên viết các xử lý và thủ tục gọi đến các thủ tục trong thư viện có sẵn, các thủ tục này có thể gọi đến một thủ tục khác ở một thư viện khác nhưng nó không bao giờ gọi trở lại những xử lý do người lập trình đó viết (chúng ta tạm gọi là thủ tục của người dùng – user procedures). Nhưng đối với IoC, điều này lại xảy ra. Kết quả này có thể đạt được bằng cách thư viện hay một framework định nghĩa cơ chế chung cho một loại vấn đề còn xử lý cụ thể thì sẽ do thủ tục của người dùng giải quyết.

Một ví dụ dễ thấy của IoC là sự thay đổi của mô hình lập trình giao diện. Theo mô hình console cổ điển thì giao diện ứng dụng được điều khiển bởi code của ứng dụng. Ví dụ, để giải một bài toán c=a+b thì ta cần lần lượt yêu cầu người dùng nhập a, b rồi hiện kết quả c. Tuy nhiên, với các framework lập trình hỗ trợ giao diện đồ họa mới như .NET, vòng lặp xử lý chính được framework cung cấp và chương trình cần viết chỉ việc cung cấp các thủ tục xử lý sự kiện cho các control tương ứng với các giá trị trên. Luồng xử lý chính của ứng dụng như thế đã tách khỏi chương trình và đi vào framework.

IoC được sử dụng như một tính năng cơ bản trong các framework hỗ trợ lập trình mức cao (như Spring, Cairngorm, PureMVC…). Thay vì phải viết một chuỗi các xử lý và thủ tục được gọi một cách tuần tự, người sử dụng các framework này thường viết các xử lý để đáp ứng lại các event hoặc yêu cầu dữ liệu đặc trưng. Đây cũng là một hướng khác trong việc thiết kế phương tiện giao tiếp giữa các module so với kiểu cổ điển vì trong phương thức giao tiếp có sự tham gia điều phối của framework bên dưới. Dưới đây chúng ta sẽ khái quát ba trong số các khái niệm kế thừa từ IoC: data-binding, dependency injection và event-driven architecture.

Data-binding

Trở lại ví dụ chương trình giải bài toán c=a+b ở trên, nếu chúng ta sử dụng một công cụ bảng tính như Excel và gán công thức cho cellC là cellA + cellB thì khi giá trị cell A và B được cập nhật, giá trị cell C sẽ tự động được tính lại. Tính năng tự động đồng bộ dữ liệu khi có thay đổi như trên không phải là mới và xuất hiện nhiều trong các ngôn ngữ lập trình hiện nay với tên gọi là data-binding.

Theo kiểu lập trình thô sơ hơn mà chúng ta thường làm thì để đạt được khả năng trên, trong một ngôn ngữ lập trình như .NET, chúng ta sẽ bắt các sự kiện thay đổi của các control (cell A, cell B) và gọi lại thủ tục cập nhật cell C. Còn khi sử dụng kĩ thuật data-binding, một đối tượng quan sát (observer) được tạo ra để quan sát các thay đổi trên thuộc tính của đối tượng nguồn và tự động cập nhật thay đổi lên thuộc tính được đăng ký tương ứng của đối tượng đích. Để cài đặt cơ chế data-binding, Observer pattern thường được dùng để tạo đối tượng observer và thuộc tính của đối tượng đích thường được dùng ở dạng set property. Cơ chế kích hoạt của data-binding là cách sử dụng sự kiện (event). Khi có sự thay đổi trên thuộc tính đối tượng nguồn, một event sẽ được kích hoạt và gửi tới observer. Observer sau đó duyệt trong danh sách đăng ký của mình và kích hoạt lại biểu thức gán thuộc tính các đối tượng đích tương ứng.

Figure 5 : Một ví dụ về mô hình data-binding

Tính năng data-binding được hỗ trợ sẵn trong hầu hết các các framework lập trình hiện tại (như .NET, Flex…) và giúp lập trình viên giảm bớt rất nhiều thao tác xử lý so với cách xử lý thủ công. Hiện tại, data-binding ở các framework khác nhau cũng được hỗ trợ một số tính năng bổ sung khác nhau như khả năng binding 2 chiều, binding ngược từ đối tượng đích đến đối tượng nguồn… Nếu có dịp, chúng ta sẽ trao đổi thêm về tính năng này trong một bài viết khác.

Trở lại vấn đề ứng dụng trong kiến trúc module thì chúng ta thấy data-binding có ứng dụng như thế nào? Data-binding có khả năng rất to lớn trong việc thay đổi cách tương tác của các thành phần giao diện với các thành phần đảm nhận xử lý logic và dữ liệu. Trong các mô hình như 3-tier hay MVC, khi sử dụng data-binding, các module presentation hay view có thể gửi và nhận các thay đổi từ các module khác một cách tự động nhờ xử lý của framework bên dưới và do đó giảm bớt sự phụ thuộc giữa các module. Một framework được xem là chuẩn và được sử dụng rộng rãi trong các dự án lớn hiện nay là Cairngorm (xây dựng trên nền tảng Flex của Adobe theo mô hình MVC) cũng sử dụng data-binding như là phương tiện duy nhất để thao tác tới các các thành phần view.

Dependency injection

Được xem như một khái niệm điển hình kế thừa từ IoC, dependency injection thường được ứng dụng như một pattern mạnh mẽ trong việc hạn chế sự phụ thuộc giữa các object hay các module.

Trong một ứng dụng, giả sử B là một lớp dịch vụ được tổ chức ở mức trừu tượng – abstract, ví dụ như hỗ trợ lưu trữ ảnh, và có nhiều lớp cụ thể kế thừa từ nó như lưu trữ vào database, lưu trữ file jpg, png, … Thông thường, nếu một thành phần A (client) cần truy cập đến một dịch vụ cụ thể của B thì A thường hoặc phải nắm giữ tham chiếu trực tiếp đến đối tượng con cụ thể hoặc thông qua một đối tượng trung gian nào đó để lấy tham chiếu đến nó. Bằng cách sử dụng cách truy cập thông qua đối tượng trung gian, chúng ta có tăng tính tái sử dụng A trong nhiều trường hợp bằng cách kết hợp nó với nhiều dạng lưu trữ khác nhau. Tuy nhiên theo cách này thì A vẫn bị giới hạn là phải biết đến đối tượng trung gian cũng như cách truy cập một dịch vụ cụ thể của B từ nó. Nhưng đối với dependency injection, A đơn giản là chỉ cần cung cấp một thuộc tính dùng để chứa tham chiếu và một khi một đối tượng A cụ thể được tạo ra, một dịch vụ cụ thể của B cũng sẽ được tự động tạo ra và gắn vào tham chiếu này thông qua một cơ chế bên ngoài.

Dependency injection được ứng dụng rộng rãi trong các framework trên nền tảng Java và .NET như Spring, PicoContainer, Spring.NET, Castle MicroKernel/Windsor… hay trong Flex như Mate, Swiz… Các framework này hầu hết đều hỗ trợ cấu hình các liên kết thông qua file config nên càng tăng tính tiện dụng. Đi sâu chi tiết vào dependency injection nằm ngoài mục tiêu của bài viết này và sẽ được trình bày ở một bài viết khác, tuy nhiên, nếu bạn quan tâm đến dependency injection thì hãy chọn một framework hỗ trợ mô hình này ở ngôn ngữ mình yêu thích và học cách sử dụng nó để thấy ứng dụng to lớn của dependency injection.

Event-driven architecture

Event-driven architecture (EDA) là mẫu kiến trúc phần mềm (architecture software pattern) trong đó, về cơ bản, hệ thống được xây dựng xung quanh các thao tác như tạo, khám phá, tiêu thụ và đáp trả lại các sự kiện (event). Hiểu đơn giản hơn, EDA là một dạng kiến trúc phần mềm được xây dựng trên luồng các event, sử dụng event như là phương tiện giao tiếp giữa các thành phần hệ thống.

Một event trong EDA được hiểu là một “thay đổi trạng thái đáng chú ý” của một thành phần nào đó. Event có thể được phát sinh do người dùng, do các thiết bị phần cứng hoặc do chính phần mềm phát sinh trong một điều kiện nào đó. EDA được xem như một trong những kĩ thuật thiết kế hiệu quả nhất trong việc hạn chế đến mức nhỏ nhất quan hệ phụ thuộc giữa các thành phần hệ thống hay các module.

Một ví dụ đơn giản của EDA: một module quản lý việc đăng nhập của user cần chứng thực thông tin của user vừa nhập xong nên tự phát sinh và gửi đi một event gọi là LoginEvent chứa thông tin user. Event này sau đó được một module có khả năng thao tác với dữ liệu như WebServer, Database… bắt lấy, thực hiện việc kiểm chứng và sau đó trả lời kết quả thông qua LoginResultEvent để module đăng nhập bắt lấy. Theo cách xử lý này thì module đăng nhập không cần biết module nào và sẽ làm thế nào để thực hiện việc kiểm tra, nó chỉ cần biết gửi yêu cầu và nhận kết quả sau khi kiểm tra và tất cả những gì nó quan tâm chỉ là các event được định nghĩa ở mức hệ thống. Hơn nữa, event kết quả trong trường hợp trên có thể được quan tâm bởi nhiều module khác như module đảm nhận ghi log và do đó làm cho hệ thống càng mềm dẻo hơn.

Figure 6 : Một ví dụ đơn giản về EDA

EDA là mẫu kiến trúc được ứng dụng cực kì rộng rãi trong các hệ thống hiện đại và đặc biệt được dùng như phương tiện giao tiếp giữa các service trong các hệ thống Service-oriented architecture (SOA) kiểu mới. EDA còn được sử dụng rộng rãi trong các framework phổ biến như Cairngorm, PureMVC… Việc nghiên cứu sâu về EDA cũng như các mẫu kiến trúc khác sẽ được chúng ta bàn sâu hơn các bài viết khác.

Lời kết

Qua bài viết này hi vọng các bạn có thể tìm thấy nhiều kiến thức hữu ích về kiến trúc module, đặc biệt là các kĩ thuật trong việc tạo interface giao tiếp. Ngoài việc giới thiệu chung về khá nhiều kĩ thuật, bài viết còn chú trọng đến ứng dụng các kĩ thuật này trong kiến trúc module nên hi vọng có thể giúp cả những bạn đã từng nghiên cứu chúng có thể tìm thấy cách ứng dụng khác cho những kiến thức mình đã biết. Còn rất nhiều vấn đề không được nhắc tới trong bài viết nhưng phương pháp chia nhỏ hệ thống thành các module, các nguyên lý thiết kế… Những vấn đề này hi vọng chúng ta sẽ có dịp bàn tới trong các bài viết khác.

Tài liệu tham khảo

1. Bertrand Meyer, Object-Oriented software construction – Second edition.

2. David Parnas, On the Criteria to Be Used in Decomposing Systems Into Modules.

3. Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, Second Edition.

4. Martin Flower, Inversion of Control Containers and the Dependency Injection Pattern.

5. http://docs.joomla.org/Framework.

6. http://en.wikipedia.org/wiki/.

7. http://msdn.microsoft.com

ỨNG DỤNG KIẾN TRÚC MODEL-VIEW-PRESENTER TRONG .NET

2009-10-09T20:12:00.000-07:00

Đây là bài viết gốc trước khi được điều chỉnh để đăng trên PC World Vietnam.

Vấn đề của các hệ thống tương tác

Trong các nền tảng lập trình hiện đại như .NET, khi mà các công cụ và kĩ thuật hỗ trợ lập trình giao diện người dùng (UI) ngày càng trở nên mạnh mẽ và tiện dụng thì chúng ta thường có xu hướng đưa nhiều xử lý bên ngoài vào các lớp UI. Kết quả là các thành phần UI này chứa nhiều xử lý logic và dữ liệu mà lẽ ra nên tách rời thành những thành phần riêng. Việc tách rời xử lý và trình bày vì những lí do sau:

- Trong một hệ thống, UI là thành phần có nhiều khả năng thay đổi nhất nên việc tách rời các thành phần UI giúp có thể thay đổi các thành phần UI này một cách độc lập mà không ảnh hưởng đến các thành phần xử lý khác. Đặc biệt việc tách rời các thành phần dữ liệu khỏi UI còn cho phép trên cùng một thành phần dữ liệu này, ta có thể phát triển nhiều thành phần UI khác nhau cho các cách trình bày khác nhau.

- Các code xử lý đặt trong các thành phần UI còn gây khó khăn cho việc testing (unit-test). Việc test các thành phần UI thường hoặc phải chạy ứng dụng thủ công hoặc sử dụng các runner script để thực hiện việc tương tác tự động lên các thành phần UI, do đó sẽ tốn nhiều chi phí và thời gian hơn để kiểm tra các xử lý bên trong các thành phần này.

- Việc đưa nhiều xử lý vào các lớp UI còn dẫn đến khả năng là trùng lắp code xử lý. Những xử lý lẽ ra có thể dùng chung thì lại xuất hiện lặp lại ở nhiều thành phần UI có chức năng tương tự nhau. Việc tách các xử lý này ra ngoài ra còn tăng tính tái sử dụng code và dễ bảo trì hơn.

Các vấn đề trên là các vấn đề cơ bản được đặt ra cho các hệ thống tương tác (interactive system). Để giải quyết chúng, một số giải pháp được đề ra trong đó phổ biến nhất là mẫu kiến trúc MVC (Model-View-Controller). Trong bài viết này, chúng ta sẽ khảo sát mẫu kiến trúc MVC cổ điển và một mẫu kiến trúc thừa kế từ nó, hiện được ứng dụng rộng rãi trong môi trường .NET, đó là kiến trúc Model-View-Presenter.

Mẫu kiến trúc Model-View-Controller cổ điển

Tổng quan

Mẫu kiến trúc Model-View-Controller là phương pháp chia nhỏ các các thành phần dữ liệu (data), trình bày (output) và dữ liệu nhập từ người dùng (input) thành những thành phần riêng biệt.

Lịch sử

MVC được hình thành bởi các nghiên cứu của Trygve Reenskaug vào khoảng các năm 1978-1979. Sau đó nó được điều chỉnh và được cài đặt lần đầu tiên vào các lớp của thư viện Xerox PARC Smalltalk-80. MVC cổ điển hiện tại ít được sử dụng trong môi trường lập trình desktop như trước đây nhưng hiện tại nó vẫn được sử dụng cực kì rộng rãi như là kiến trúc cơ bản trong các môi trường lập trình web.

Cấu trúc

Các thành phần

Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic). Thành phần model thường được trình bày ở dạng Domain Model .

View là thành phần đảm nhận trình bày từ những dữ liệu của Model. View bao gồm những gì thể hiện trên màn hình như các control, form, widget,…

Controller là thành phần đảm nhận việc xử lý đáp trả lại các dữ liệu được đưa vào từ người dùng như các sự kiện chuột, bàn phím, các tương tác lên các control… Controller là cầu nối giữa người sử dụng và ứng dụng.

Phối hợp các thành phần

Trong kiến trúc MVC, mỗi bộ ba Model-View-Controller được thiết kế tương ứng cho các đối tượng mà người dùng có thể tương tác.

Model nắm giữ trạng thái, cấu trúc và các hành vi của dữ liệu được thể hiện và tương tác bởi người dùng. Model không phục thuộc và tương tác trực tiếp lên các thành phần khác. Thay vì vậy, khi có thay đổi, nó thông báo cho những thành phần như View tương ứng thông qua cơ chế là Observer pattern. Model còn cung cấp phương tiện để các thành phần khác tương tác lên nó.

View lấy các thông tin từ Model và trình bày đến người dùng. Trên cùng một model, có thể có nhiều View cùng đăng ký. Khi có một thay đổi từ Model, tất cả các View đều được thông báo thông qua observer mà nó đã đăng ký.

Mỗi View khi được tạo ra sẽ tạo ra một Controller đi kèm với nó. Trong khi các View đảm nhận kết xuất dữ liệu thì các Controller đảm nhận việc xử lý dữ liệu từ người dùng. Với mỗi sự kiện nhận được, Controller có thể xử lý và tương tác trực tiếp lên thành phần View và Model tương ứng để đáp trả. View và Controller là hai thành phần cấu thành nên giao diện người dùng của ứng dụng. Chúng lưu giữ liên kết trực tiếp đến Model. Trong khi Controller có thể thay đổi dữ liệu theo yêu cầu của người dùng thì View tương tác để lấy dữ liệu cập nhật vào chính nó từ Model.

Nhầm lẫn thường gặp

Một nhầm lẫn thường gặp trong quan hệ giữa các thành phần MVC là khi xem mục đích của Controller như là thành phần trung gian để tách rời View khỏi Model. Trong khi thực tế, kiến trúc MVC tách rời dữ liệu và xử lý trung tâm khỏi phần trình bày thông qua cơ chế là Observer Pattern chứ không phải Controller. Nhiệm vụ của Controller là cần nối giữa người dùng là ứng dụng, không phải giữa View và Model.

Vấn đề của MVC

Trong khi mục đích chính của MVC là tách rời trình bày và các xử lý bên trong. Việc phân rõ vai trò xử lý ouput (View) và input (Controller) là một hệ quả nhằm hoàn thiện cơ chế cho ý tưởng trên. Hiện nay trong nhiều môi trường lập trình hiện đại, nhiều control được cung cấp và hoàn thiện hơn (nhiều xử lý sự kiện cơ bản đã được hỗ trợ sẵn) so với trước đây nên việc khoáng tất cả các xử lý sự kiện cho một thành phần độc lập như Controller không còn là vấn đề quan trọng nữa.

Trong khi đó, những cơ chế như Observer Pattern cũng có vấn đề của riêng chúng. Trong khi được dùng như phương tiện hiệu quả để loại bỏ sự phụ thuộc của Model vào các thành phần khác, nó có một vấn đề lớn là tại một thời điểm, chúng ta khó có thể xác định điều gì sẽ xảy ra bằng cách đọc code và việc thực hiện các testing cũng khó khăn hơn. Hơn nữa, do Model chỉ liên kết gián tiếp đến View thông qua Observer Pattern, khi sự thay đổi trạng thái của Model cần đến một vài thao tác xử lý phức tạp để áp dụng lên giao diện thì với mô hình cổ điển sẽ gặp khó khăn.

Một vấn đề khác là chúng ta cần lưu trữ tình trạng hiện tại của UI (UI state), ví dụ trong danh sách sinh viên thì chúng ta cần biết sinh viên nào đang được chọn. Trong khi thành phần UI nắm giữ dữ liệu trình bày đang được chọn thì dữ liệu sinh viên thuộc về Model, như vậy dữ liệu về sinh viên được chọn sẽ được lưu trữ ở đâu khi cần truy xuất đến?

Vì những lí do trên, MVC sau này đã có những thay đổi và bổ sung nhất định (như khái niệm Application Model). Kiến trúc MVP chúng ta sẽ bàn dưới đây cũng dựa trên tư tưởng cơ bản của MVC nhưng với cách tiếp cận khác nhằm mục đích khắc phục các khuyết điểm đã có.

Mẫu kiến trúc Dolphin Smalltalk Model-View-Presenter

Tổng quan

Mẫu kiến trúc Dolphin Smalltalk Model-View-Presenter chia ứng dụng thành các phần dữ liệu (data), trình bày (presentation) và các xử lý logic thuộc phần trình bày (presentation logic) thành những thành phần riêng biệt.

Lịch sử

Phiên bản Dolphin Smalltalk Model-View-Presenter (gọi tắt là Dolphin MVP) là phiên bản của MVP được xây dựng dựa trên phiên bản Taligent MVP xuất hiện trước đó. Dolphin MVP được xây dựng về cơ bản bên ngoài tương tự như MVC cổ điển nhưng khác nhau ở vai trò của Controller và Presenter.

Cấu trúc

Các thành phần

Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic).

View là thành phần đảm nhận trình bày từ những dữ liệu của Model. View bao gồm những gì thể hiện trên màn hình như các control, form, widget,…

Presenter là thành phần đảm nhận các xử lý về trình bày mà nó cần đến sự tương tác trên dữ liệu.

Phối hợp các thành phần

Trong khi vai trò của Model không thay đổi so với MVC cổ điển. Thành phần View của Dolphin MVP cũng thực hiện việc trình bày từ nội dung của Model và gắn kết với Model thông qua Observer Pattern. Tuy nhiên, nó thực hiện bắt các sự kiện xảy ra ngay bên trong nó. Một vài trường hợp đơn giản như TextView, dữ liệu nhập được xử lý trực tiếp và cập nhật thay đổi trực tiếp vào Model còn hầu hết các trường hợp khác, việc xử lý được chuyển giao cho Presenter đảm trách khi cần thao tác đến Model.

Trong khi View đảm nhận trình bày thì Presenter đảm trách cách Model được thao tác và thay đổi như thế nào bởi giao diện người dùng. Presenter là nơi chứa các xử lý đặc trưng của ứng dụng (application logic so với business logic của Model). Một điểm đáng chú ý khác là Presenter có khả năng thao tác trực tiếp lên View mà nó gắn kết, điều này khác biệt với phiên bản Taligent MVP xuất hiện trước đó.

So sánh Dolphin MVP và MVC cổ điển

Điểm khác biệt cơ bản của Dolphin MVP và MVC cổ điển là sự khác nhau về vai trò của Presenter và Controller, nó cũng dẫn đến sự khác nhau về vai trò giữa hai thành phần View. Trong Dolphin MVP, sự hiện diện của Controller bị loại bỏ, thay vào đó, việc xử lý các dữ liệu input được View đảm nhận và được chuyển cho Presenter khi có yêu cầu tương tác đến Model.

Mẫu kiến trúc MVP của Martin Fowler

Tóm tắt

Martin Fowler là một trong những người đâu tiên đi sâu và nghiên cứu về các phiên bản của MVP. Vào năm 2006, Fowler tuyên bố sự kết thúc của các kiến trúc MVP cổ điển và tự chia MVP thành hai phiên bản mới là Passive View và Supervising Controller.

(Martin Fowler dùng thuật ngữ Controller thay vì Presenter trong mẫu của mình)

Trong mẫu Passive View, thành phần View được loại bỏ hoàn toàn các xử lý logic và tương tác đến Model. Thay vì vậy, nó chuyển giao các xử lý cho Controller đảm trách. Controller đảm nhận tương tác đến Model và cập nhật View khi có thay đổi từ Model. Controller là thành phần trung gian liên lạc giữa View và Model.

Trong mẫu Supervising Controller, View đầu tiên bắt lấy các sự kiện và sau đó chuyển giao cho controller xử lý. Để cập nhật thay đổi từ Model, View dùng data-binding và Observer pattern cho các xử lý đơn giản còn đối với các xử lý phức tạp sẽ nhờ đến Controller đảm nhận.

So với Supervising Controller chứa View đảm nhận xử lý sự kiện đơn giản thì với Passive View, thành phần View được tách rời hoàn toàn khỏi các xử lý, kể cả các xử lý cơ bản ở mức giao diện cũng được giao hoàn toàn cho Presenter xử lý. Điều này tạo thuận lợi hơn cho việc testing vì khi đó các thành phần Model và Presenter có thể được kiểm tra một cách độc lập mà không phụ thuộc vào giao diện. Phiên bản MVP của Microsoft đầu tiên được xây dựng dựa trên Passive View sau đó mẫu Supervising Controller cũng được hỗ trợ với một số điều chỉnh.

Phiên bản MVP của Microsoft

Lịch sử

Khởi đầu từ các framework Smart Client Software Factory and Web Client Software Factory dựa trên kiến trúc MVP được các nhóm nghiên cứu về pattern của Microsoft tạo ra từ năm 2006, Microsoft sau đó bắt đầu đưa MVP vào các tài liệu hướng dẫn và ví dụ về lập trình giao diện trong .NET framework. Mô tả dưới đây dựa trên phiên bản MVP được mô tả trong tạp chí MSDN vào năm 2006 (tham khảo 2) và có thể xem là kiến trúc cơ bản cho các framework trên. Ngoài ra, còn có một số framework MVP khác cũng được phát triển trên nền tảng .NET như MVC# hay NMVP.

Xin lưu ý là phiên bản cũ của Web Client Software Factory ban đầu được tổ chức dựa trên Passive View (cấu trúc bên dưới) nhưng với phiên bản hiện tại thì cấu trúc dựa trên Supervising Controller cũng được hỗ trợ.

Cấu trúc

Các thành phần

Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic).

View là thành phần đảm nhận trình bày từ những dữ liệu của Model và là tổng hợp của các form, control được sử dụng.

Presenter là thành phần đảm nhận các xử lý về trình bày cũng như tương tác đến dữ liệu bên dưới và có thể tương tác để thay đổi View trong quá trình xử lý.

Phối hợp các thành phần

Mẫu kiến trúc MVP của Microsoft tương tự như Passive View nhưng nó bổ sung thêm ràng buộc là các Presenter chỉ có thể truy cập đến View thông qua các interface IView. Điều này giúp Presenter không phụ thuộc đến cài đặt cụ thể của View và có thể dễ dàng test Presenter một cách độc lập. Điều này đạt được do sử dụng IView, chúng ta có thể dùng kĩ thuật “Mock” để thay thế các xử lý cụ thể của View khi test Presenter. Ngoài ra, mối quan hệ giữa Presenter và Model là quan hệ một chiều (chiều còn lại là gián tiếp). Hệ quả của các liên kết là chúng ta có một mô hình đa lớp (multi-layer) như cấu trúc ở trên theo ý nghĩa các thành phần ở một layer chỉ phụ thuộc và sử dụng các thành phần ở layer ngay bên dưới nó.

Theo mẫu Microsoft MVP, khi một View gắn liền với một interface IView. Khi View được tạo ra, nó tạo ra một đối tượng private Presenter và gắn nó vào đối tượng này thông qua IView. Khi một sự kiện xảy ra, View bắt lấy và sau đó kích hoạt một phương thức của Presenter mà sau đó, nó có thể tương tác với Model. Một số sự kiện như bắt đầu hiển thị và đóng của View cũng được gửi tới để Presenter kích hoạt một số phương thức tương ứng, điều này giúp cho một số công việc như khởi tạo và giải phóng dữ liệu cho View được dễ dàng hơn.

Model theo Microsoft MVP cũng thường được tổ chức bổ sung một lớp Service nằm bên trên để tương tác với Presenter, qua đó giảm bớt sự phụ thuộc đến các xử lý data nằm sâu bên dưới. Ngoài ra, để điều khiển việc liên lạc giữa các View hay các Presenter, một thành phần thường được bổ sung gọi là Application Controller. Trong một ứng dụng có thể có nhiều Application Controller để quản lý các nhóm MVP. Ngoài ra, thay vì sử dụng Presenter để tương tác với Model, một cách là giao tất cả các thao tác này cho Application Controller đảm trách.

Một ví dụ minh họa đơn giản

Để minh họa mẫu Microsoft MVP, chúng ta sẽ cùng khảo sát một ví dụ đơn giản: tạo một form hiển thị danh sách sinh viên cùng chức năng thêm mới trên danh sách sinh viên đó. Với mục tiêu là minh họa cách tổ chức và liên kết giữa các thành phần là chủ yếu, chúng ta không đi sâu vào cài đặt cụ thể (bạn có thể tham khảo source code đi kèm bài viết, source code được tổ chức ở dạng project của VS 2008).

Ứng dụng được tổ chức thành 5 project: View, Presenter, DataService, Model và DataTransferObject. Trong đó, View là application còn các project khác là library. Các project phụ thuộc lẫn nhau theo thứ tự project phía trước sử dụng trực tiếp project phía sau, ngoại trừ DataTransferObject chức các loại dữ liệu được dùng chung cho 3 project View, Preseneter và DataService. Model là project chứa các tương tác trực tiếp đến dữ liệu và không phụ thuộc vào bất cứ thành phần nào khác.

Giải thích các project:

- Model: chứa dữ liệu giả lập (StudentData.xml), schema (StudentDataSet.xsd) và lớp tiện ích được xây dựng bên trên (DataAccess.cs).

- DataTransferObject: chứa đối tượng dữ liệu được dùng chung cho các project ở mức cao hơn (Student.cs).

- DataService: được xây dựng bên trên Model, chuyển đổi dữ liệu từ Model sang DataTransferObject và xây dựng các tiện ích bên trên đối tượng transfer này (Service.cs).

- Presenter: chứa interface của View dùng cho Presenter truy cập (IViewForm) và lớp Presenter (StudentPresenter).

- View: chứa form view (ViewForm.cs) và Program.cs.

Trong bài viết khác, chúng ta sẽ tìm hiểu phương pháp TDD (Test-driven development) và ứng dụng nó để phát triển ứng dụng theo mẫu Microsoft MVP trong môi trường .NET.

Tài liệu tham khảo

1. Martin Fowler, GUI Architectures ,http://www.martinfowler.com/eaaDev/uiArchs.html

2. Jean-Paul Boodhoo , Design Patterns: Model-View-Presenter, http://msdn.microsoft.com/en-us/magazine/cc188690.aspx

3. Buschmann F., Meunier R., Rohnert H. & Sommerlad P. & Stal M. (1996). Pattern-Oriented Software Architecture: A System of Patterns.

4. Martin Fowler , Patterns of Enterprise Application Architecture.

5. http://en.wikipedia.org/wiki/Model_View_Presenter

6. http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

7. Derek Greer, Interactive application architecture patterns, http://ctrl-shift-b.com/2007/08/interactive-application-architecture.html

8. Views Testability Guidance, http://msdn.microsoft.com/en-us/library/cc304742.aspx

9. Dolphin MVP paper, http://www.object-arts.com/papers/TwistingTheTriad.PDF

Mọi đóng góp và thắc mắc vui lòng gửi về địa chỉ dakurai@gmail.com.

New wild idea in OOP

2009-06-05T00:47:00.000-07:00

The beginning

A while ago, when designing a new framework, I have met some problems with the limit of current OO languages. Because it bases on the module architecture, I need a more flexible method to design and link the module to the main application. Currently, in .NET or Java, when we want to call a member from an unknown class type, we generally have to use Reflection. This method, itself, has many disadvantages. In C# 4.0 coming soon, a new feature called dynamic type is introduced. It has some advantages over Reflection. In fact, the dynamic type isn’t new concept and has occurred in many languages such as ActionScript, Python, Ruby… And it has potential to produce more error at runtime and has lower performance than static type. So may we need a new method?

In following sections, we will come through many situations which current concepts won’t provide good enough solutions. After that, I will introduce a new idea that may be worth to look. The languages are used in examples will be ActionScript and C# (these are my main development languages) but other OO languages could be similar.

The situations

Situation 1:

We want to use an object but specific type of it is unknown, or rather dynamic type. Such a object could be created by some technique such as Reflection (or getClassFromName in ActionScript) or simply from a method which get object from external lib, module, COM, Ruby, Python,…We can use the methods of it by using invoke or simply convert it to dynamic type (C# 4.0 or ActionScript 3.0). Examples:

Invoke (C#)

object calc = GetCalculator();
Type type = calc.GetType();
object result = type.InvokeMember("Add",
BindingFlags.InvokeMethod, null,
new object[] { 10, 20 });
int sum = Convert.ToInt32(result);

Dynamic type (C# 4.0)

dynamic calc = GetCalculator();
int result = calc.Add(10, 20);

Dynamic type (ActionScript 3.0)

Object calc = GetCalculator();
int result = calc.Add(10, 20);

==> What disadvantages of these :

Invoke technique in .NET is very powerful and it can even be used on non-public members. But it is a little complex to be used because it requires knowledge of reflection. And when you invoke a member, you have many exceptions to be aware of, because the name and arguments of member simply can’t be determined at compile- time. In many situations, you may need a simpler solution to call member of a specific type, so as, dynamic type in C# 4.0.
Dynamic type (C# 4.0 or ActionScript 3.0) is a simpler solution to this. But it still a big disadvantage: you can’t guarantee that what you give is valid and there isn’t a method to check a member fully before you actually work on it (you can still check name and maybe return type but checking arguments is a pain). So, you also need to catch exceptions if it happens. (Dynamic type is still a very useful when combined with other techniques such as data binding).
All these technique are considered slow when compared with static types.

Situation 2

We have 2 existing class CalculatorA and CalculatorB, it maybe come from different external libraries or modules. They share several methods such as Add, Subtract…which we want to use. Moreover, we want to support both of them and use them in the same code. Which class is used depends on situations. In general, if these classes both implement a specific interface or derive from a class which declares methods we need, it would be very easy. In contract, because they don’t , we have to use some techniques such as create a new wrapper which encapsulates both class or create wrappers which implement the same new interface for each class (or techniques in situations 1). These solutions need more work to do and maybe a little complex to use.

Situation 3

This one is similar to Situation 2, but there is a difference: we don’t only use some the members shared between classes but other members not shared too. For examples, CalculatorA and CalculatorB are both create on the same specification in the beginning but each class has add some different features which are valuable to be used. We can assume that CalcuatorA is provided by company A and CalculatorB is provided by company B or maybe they are the same class which came from different versions of the same library. In general, we need to check which class is currently provided and call appropriate code upon it. Because we don’t know exactly which version will be used, we may want to use some technique in Situation 1 such as Reflection to do it. What will happen if we can define two new interfaces to use with these classes in our project (for an easier life) or if you prefer another simple solution, a single interface which can be use with both classes (in this case, we may need a tool to check whether a member is supported or not) ?

Situation 4

This situation is very simple. We have a very large and complex class such as Graphics. It has many complex or annoying public members which I needn’t use. In fact, there are some interface can be used upon it but what we need is not included in one but several interfaces. So we can’t use it with a single and simple interface without creating another annoying wrapper?

Situation 5

This situation is similar. When we build an application, we find out an interesting library. We notice there are an interface X and several classes implementing it in this library. We want to use them and even want to create some new implementations of interface X. But, in fact, we don’t want to use and implement all members of X. So, we create a new interface X1 which includes subset members and implement X1. What can we do if we want to use both old and new classes with interface X1? We may have some solutions such as creating a wrapper which wraps X and implement X1, but we may prefer a simple and straightforward solution. The solution that I mention is the ability converting directly from old class to X1.

Situation 6

This situation extends Situation 5. When creating interface X1, we find out that it may be interesting if we add some new methods to X1. These extra methods may help in some situations but old classes implementing X are still useful. We want that if we use these classes and extra methods are missing, when we call them, something can be executed alternatively such as returning a predefined value, throwing a predefined exception, calling other methods of interface X1... This may be a little complex but very useful in many situations.

The new concept – View

In many OO languages, interface is an important concept. Interface concept derives from abstract class concept and provides a valuable benefit: supporting multiple inheritance. Because an interface only includes declarations of members, it can be used to separate declarations from the real implementations. We can use an interface to interact with an object without knowing its type of class, but rather only that it implements that interface. But there is a restriction, the word “implement” we use here means the class of the object must point out the interfaces implemented in its declaration. Personally, I think that it’s more natural if that class just needs implement all members which interface declares to meet the requirement. This restriction limit the usage of interface, the above situations are some examples of it. Even if we remove this restriction, the new interface won’t be good enough solutions for some situations (such as situation 6). So we may have to extend it a bit more.

I don’t want to mess with the interface concept so I create a new concept called “View”. A new “View” concept matches the interface concept basically but the new concept has some differences:

- A method (and its extended concepts such as property, index…) now can have a default behavior added to its declaration in view. A default behavior will be used when we use view on an object that didn’t implement that method. A default behavior can be: return a default value, throws a specific exception, call a sibling method or call a static method…

- In contract to interface concept, a class needn’t point out the views in its declaration to show that it will implement them. An object can be converted to a view even if its class didn’t implement all members of that view. In case a member isn’t implemented, its specific behavior will be executed instead when it’s called. If that missing member doesn’t have default behavior, the convert task will be fail.

- A view can inherits members from other views, base on interfaces and extract members from classed. It can add default behavior to members it got from them by using the fully qualified member name (Ex. IPaint.draw(), Point.move()…).

We can only call a member from a view if the view has declaration of it, so no more invalid member name or argument problems at runtime. If we convert a view holding a object to another type, all extra member won’t be considered.

More definition of View

After receiving some comments, I think that'll be more clearly to give more defifinition here.
So what is a view?

Meanwhile a class encapsulates an entire entity type (the state and behavior),a view encapsulates the signatures (or declarations) of some behaviors sharing between entities. Those behaviors are what we want to use on those entities and when a behavior is missing on an entity, we could use the standard reaction of behavior instead. In some respect, it's similar to mask. Using a view on an object is similar to apply a mask on it.

Comparison to Duck-typing

One of replies I received points out the similarity between my idea and a principle called duck-typing. You can read its definition here: http://en.wikipedia.org/wiki/Duck_typing.
After reading about duck-typing from wiki link, I notice the phrase "in computer programming, duck typing is a style of dynamic typing..". In fact, duck-typing is more raw and powerful because it allow you convert a class to any compatible class or interface. I think it and dynamic type are the same, though it could check the compatibility before using : "With Duck Typing, in order to prevent strange, hard to detect errors, the developer needs to be aware of each potential use of the method 'press', even when it's conceptually unrelated to what he or she is working on".
My idea is more restrict, may be derived from duck-typing interface, but the power is still remained fully. We use "view" when we need (instead of any compatible class or interface to be confused) and the compatibility is checked (fully) when converting. The view is similar to interface so it's more understandable when using than duck-typing: "In essence, the problem is that, 'if it walks like a duck and quacks like a duck', it could be a dragon doing a duck impersonation. You may not always want to let dragons into a pond, even if they can impersonate a duck". Human and monkey have some similar aspect but when you use monkey in place of human is something strange (hard to understand though it give you more power!).
A question: How is my idea any different? Could a dragon still impersonate a duck my suggestion? which means compromises type safety?
According to my idea, a view is a collection of behaviors's signatures, not a real entity type, those behaviors are what we want to use on an object if it has. In the "duck" example, we could define a view such as VDuckBehavior and use it to interact with some dragon if possible. Similarly, we may include some behaviors of human in a view (ex: viewX) that monkey also have (certainly they are not the same).
As you see, although they are similar, their principle are different (A similar situation we all know: abstract class, interface and multi-inheritance, do you agree?). Moreover, view have more features that may be useful, specially default behavior.
Duck-typing and dynamic type could make a design difficult to understand if they're used. I don't have a clear interface definition so comparing view with duck-typing interface may be not obvious. But at least, a view has more clear meaning (interface is derived from abstract class) so it can be add more features such extracting behaviors from class and default behavior. The view concept and class concept are independent to each other. Meanwhile the interfaces are needed to exist before creating class, the view is generally created after that. Comparing to duck-typing, view is easier to understand and has not violate OO principles.
If the future C# support duck-typing, basic programmer could have a hard time to understand it after learning about OOP and you could not add extra features from view concept (to make more complicated).

Example view for C#

We have following classes and interfaces:

namespace NewConcept.Examples
{
   interface ISimpleCalcuator
{
      int Add(int a, int b);
      int Subtract(int a, int b);
}
}

namespace NewConcept.Examples
{
   public class CalculatorA: ISimpleCalcuator
{
      public CalculatorA()
   {
   }

      #region ISimpleCalcuator Members

   public int Add(int a, int b)
   {
       return a + b;
   }

      public int Subtract(int a, int b)
   {
      return a - b;
   }

      #endregion

      public int Multiply(int a, int b)
   {
      return a * b;
   }
}
}

namespace NewConcept.Examples
{
   public class CalculatorB:ISimpleCalcuator
{
      public CalculatorB()
   {
   }

      #region ISimpleCalcuator Members

   public int Add(int a, int b)
   {
       return Math.Abs(a + b);
   }

   public int Subtract(int a, int b)
   {
      return Math.Abs(a - b);
   }
   #endregion

      public int Divide(int a, int b)
   {
      if (b == 0)
          return 0;
      else
          return (int)Math.Abs(a / b);
   }
}
}

We have two classes implementing the same interface ISimpleCalculator. Each class also has its own method which didn’t declare in the interface. We want to use all the methods if possible so we create a new view.

namespace NewConcept.Examples
{
   public view VCalculator bases on ISimpleCalculator
{
       int Divide(int a, int b) default return 0;
       int Multiple(int a, int b) default throw new Exception("not support");
}
}

The VCalculator view has declarations basing on ISimpleCalculator. It also add to more methods with default behavior. The first method will return 0 at default when the second will throws an exception. Then we may use it like this:

VCalculator viewA = new CalculatorA() as VCalculator;
if (viewA != null) //convert sucessfully
{
    int c = viewA.Add(2, 3);
    int d = viewA.Multiple(2, 3);
}
VCalculator viewB = new CalculatorB() as VCalculator;
if (viewB != null) //convert sucessfully
{
   int c = viewB.Add(2, 3);
   int d = viewB.Divide(2, 3);
}

The VCalculator can be converted from either CalculatorA or CalculatorB instances. After the conversion, the view can be used easily with some notices to methods which have default behavior.

Example view for ActionScript

We use the same classes as above but implemented in ActionScript. First is a simple interface two following classes implement it.

package Examples
{
public interface ISimpleCalculator
{
       function Add(a:int, b:int):int;
       function Subtract(a:int, b:int):int;
}
}

package Examples
{
   public class CalculatorA implements ISimpleCalculator
{
      public function CalculatorA()
   {

   }

      /* INTERFACE Examples.ISimpleCalculator */

      public function Add(a:int, b:int):int
   {
     return a + b;
   }

      public function Subtract(a:int, b:int):int
   {
        return a - b;
   }

      /* Extend */
      public function Multiply(a:int, b:int):int
   {
     return a * b;
   }
}
}

package Examples
{
public class CalculatorB implements ISimpleCalculator
{

     public function CalculatorB()
  {

  }

      /* INTERFACE Examples.ISimpleCalculator */

      public function Add(a:int, b:int):int
   {
          return Math.abs(a + b);
   }

   public function Subtract(a:int, b:int):int
   {
          return Math.abs(a - b);
   }

      /* Extend */
      public function Divide(a:int, b:int):int
   {
         if (b == 0)
           return 0;
      else
          return int(Math.Abs(a / b));
   }
}
}

Each class also has its own method which didn’t declare in the interface. We want to use all the methods if possible so we create a new view.

package Examples
{
   public view VCalculator bases on ISimpleCalculator
{
       function Divide(a:int, b:int):int default return 0;
       function Multiple(a:int, b:int):int default throw new Error("not support");
}
}

var viewA:VCalculator = new CalculatorA() as VCalculator;
if (viewA != null) //convert sucessfully
{
   var c:int = viewA.Add(2, 3);
   var d:int = viewA.Multiple(2, 3);
}
var viewB:VCalculator = new CalculatorB() as VCalculator;
if (viewB != null) //convert sucessfully
{
   var c:int = viewB.Add(2, 3);
   var d:int = viewB.Divide(2, 3);
}

The VCalculator can be converted from either CalculatorA or CalculatorB instances. After the conversion, the view can be used easily with some notices to methods which have default behavior.It’ could be more interesting if we get CalculatorA and Calculator B from external modules and use it easily with internal VCalculator.

Some more features

Here are some more features that could be added to new View.

- Checking a member is implemented or not. Example: we can use view.isImplemented(“memberName”).

- Force a method to execute standard behavior. Example: view.forceStandard(“memberName”).

How could the new view concept help us

First, the new View can provide new good solutions to many situations such as above ones. Now we have a method that could be safer, easier and have better performance to access an object with unknown class type. That would help plugin programming easier. If it’s supported, the new view would change the way we code a bit. Instead of using interface or dynamic type, we can use view as a better solution in some situations.

Everyone please give your thought about new ideas: Do you think it’ll be useful or not? Other situations you would love to use it? Do you want to extend it more?

A little wish

After reading to here, I wish that you would think that my idea is somewhat that’s interesting and worth to have a look. As I said, C# and ActionScript is my main development languages so it’s wonderful if these languages support it in the next versions. Other languages would be great, too.

BS. I added a poll so please take it if you come to here.

Quizzes by Quibblo.com