Trang 1 trên tổng số 3 123 Cuối cùngCuối cùng
Từ 1 tới 10 trên tổng số 24 kết quả

Đề tài: Nghiên cứu về Design Pattern trong lập trình và sản xuất phần mềm. (vesion 1)

  1. #1
    Ngày gia nhập
    07 2006
    Nơi ở
    Hanoi, Vietnam
    Bài viết
    2,750

    Mặc định Nghiên cứu về Design Pattern trong lập trình và sản xuất phần mềm. (vesion 1)

    Sau một thời gian Dr tìm hiểu và làm việc trong lĩnh vực deverlopment phần mềm, Dr thấy mình viết code tương đối tốt và sáng sủa với convention standards, và các chú thích rõ ràng. Cho đến khi Dr tiếp cận và tìm hiểu với Design pattern thì Dr thấy là code của mình viết thực sự là rất rối rắm, khó khăn trong việc bảo trì và phát triển. Một điểm nữa mà Dr nhận thấy là "Requirement always change", và điều gì sẽ xảy ra khi requirement thay đổi? Vì vậy nghiên cứu pattern sẽ thực sự khiến cho bạn trở thành một expert, cũng khiến cho bạn viết code thực sự nhanh chóng.

    Tuy nhiên pattern là một vấn đề tương đối khó khăn để có thể hiểu triển khai cũng như implementation tốt. Và nó có rất nhiều loại pattern, trong hiểu biết cơ bản của Dr thì có thể phân chia làm 2 nhóm: Nhóm pattern liên quan đến cả architectural và được gọi là architectural pattern, còn loại kia thì không.

    Do thời gian có hạn và Dr cũng khá bận rộn, nên Dr tạm thời lập đề tài này cùng với lời giới thiệu tại đây coi như là version 1, mong rằng các bạn nhiệt tình trao đổi, xây dựng và giới thiệu tới bạn bè, người thân của mình, để đề tài này được hữu ích hơn. Xin cảm ơn bạn đã quan tâm đọc nó.
    Email: admin[@]congdongcviet.com | CC to: info[@]congdongcviet.com
    Phone: 0972 89 7667 (Office: 04 6329 2380)
    Yahoo & Skype: dreaminess_world (Vui lòng chỉ rõ mục đích ngay khi liên hệ, cảm ơn!)

    Một người nào đó coi thường ý thức kỷ luật cũng có nghĩa là người đó đã coi thường tương lai số phận của chính bản thân người đó. Những người coi thường ý thức kỷ luật sẽ không bao giờ có được sự thành công trong sự nghiệp!

  2. #2
    Ngày gia nhập
    01 2007
    Nơi ở
    Somewhere I belong
    Bài viết
    168

    Hi Dr thực tớ thấy rất hứng thú với đề tài này, nó cực kỳ mới mẻ đối với "me" chưa bao giờ được nhắc tới. Me lập tức search trên google và đọc được vài tài liệu trên mạng khá hay.
    pattern hay còn gọi là design pattern đại loại có thể hiểu nó thế này.
    - Trong công nghệ phần mềm, một mẫu thiết kế là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm. Một mẫu thiết kế không phải là một thiết kế hoàn thiện để mà có thể được chuyển đổi trực tiếp thành mã; nó chỉ là một mô tả hay là sườn (template) mô tả cách giải quyết một vấn đề mà có thể được dùng trong nhiều tình huống khác nhau. Các mẫu thiết kế hướng đối tượng thường cho thấy mối quan hệ và sự tương tác giữa các lớp hay các đối tượng, mà không cần chỉ rõ các lớp hay đối tượng của từng ứng dụng cụ thể. Các giải thuật không được xem là các mẫu thiết kế, vì chúng giải quyết các vấn đề về tính toán hơn là các vấn đề về thiết kế.

    - Đây thực sự là 1 nghệ thuật, tiếp nhận nó về tư tưởng là chính, nó rất "khó nhai". Chi phí làm 1 chương trình với DP là rất lớn, vì vậy DP cũng ít áp dụng trong program bình thường. Chỉ những công ty lớn mới bỏ thời gian ra nghiên cứu trong những program quan trọng, còn những công ty nhỏ viết chương trình ra chạy được là ok rồi . Bù lại program viết bằng DP chỉ cần sửa rất ít là ra chương trình mới.

    - Nhiều người rất ghét DP, cho nó là thứ bỏ đi vì họ thấy không cần DP thì vẫn viết chương trình chạy tốt.

    - 1 ví dụ về program Design Pattern: Viết 1 chương trình chơi cờ sao cho chơi được nhiều loại cờ (cờ Vua, cờ Tướng, cờ Nhảy). Nếu bạn thiết kế tốt thì bạn chỉ cần viết kỹ 1 loại cờ (giả sử Cờ Vua) rồi viết thêm loại cờ mới (Cờ tướng) bạn chỉ cần định nghĩa lại: Kích thước bàn cờ, định nghĩa các loại quân của cờ tướng là program chạy ok. Còn phương pháp xứ lý khi chơi thì được tái sử dụng lại.
    - Design Patterns đưa ra các giải pháp chuẩn và các qui ước đặt tên cho các vấn đề chung trong thiết kế phần mềm.
    Mời các bạn bổ xung và trao đổi về vấn đề này nhá, nó rất thú vị và cũng cực kỳ là khó nhai đấy
    Đã được chỉnh sửa lần cuối bởi iamvtn : 23-07-2008 lúc 10:32 PM.

  3. #3
    Ngày gia nhập
    06 2007
    Nơi ở
    HCM
    Bài viết
    365

    Trích dẫn Nguyên bản được gửi bởi iamvtn Xem bài viết
    - Đây thực sự là 1 nghệ thuật, tiếp nhận nó về tư tưởng là chính, nó rất "khó nhai". Chi phí làm 1 chương trình với DP là rất lớn, vì vậy DP cũng ít áp dụng trong program bình thường. Chỉ những công ty lớn mới bỏ thời gian ra nghiên cứu trong những program quan trọng, còn những công ty nhỏ viết chương trình ra chạy được là ok rồi . Bù lại program viết bằng DP chỉ cần sửa rất ít là ra chương trình mới.
    Theo anh thì tác giả bài viết trên nhìn patern dưới góc độ vĩ mô rồi, rất nhầm lẫn nếu cho rằng DP cũng ít áp dụng trong program bình thường,chính vì anh cũng đọc bài viết chết tiệt này lên đã nghĩ không cần phải học DP trong một thời gian dài.
    Để hiểu thấu đáo hơn, chúng ta hãy tìm hiểu một thuật ngữ khác : Kiến trúc phần mềm là gì , và nó liên quan gì tới DP. Ở tầng cao nhất : nó mô tả hình dạng và cấu trúc toàn thể của phần mềm ,ở tầng tiếp kiến trúc liên quan tới mục đích sử dụng của phần mềm, và cuối cùng nó là kiến trúc của các module và các kết nối giữa chúng.Như vậy rõ ràng người viết bài trên đã nhìn DP dưới góc độ vĩ mô và thể hiện của nó là application framework ,ví dụ cụ thể: chẳng hạn công ty cũ của mình viết phần mềm kế toán cho nhiều loại doanh nghiệp , doanh nghiệp bán ga, quản lý thuốc,.... mặc dù nghiệp vụ kế toán thì na ná như nhau cũng chỉ có nhập hàng, xuất hàng, report số lượng tồn.. nhưng về chi tiết sẽ có sự khác biệt , rõ ràng với một công ty nhỏ thì mình nghĩ hơi đâu mà nghiên cứu để viết một bộ khung cho mọi loại hình doanh nghiệp vì mọi bug khách hàng report thì lôi source ra fix rồi update lại cho khách hàng đều rất nhanh chóng , nếu lỡ có sai sót, ví dụ thuật toán tồn kho ra kết quả không chính xác, hay hóa đơn đưa ra giá tiền sai lệch .. thì cùng lắm cười méo một tẹo , hẹn khách hàng sẽ fix nhanh chóng! Với các công ty lớn thì mọi chuyện không hề đơn giản như vậy, để đảm bảo kỹ thuật các project phải tuân thủ quy trình một cách ngặt nghèo, theo những quy trình này thì thời gian code /tổng thể chỉ chiếm có 10% , còn lại là test ,bảo trì ( chính khách hàng của FSOFT cũng bị kiện mà nếu thua sẽ phải bồi thường đến 8 triệu USD do sai sót trong lập trình làm sai lạc thông tin - thật may là project đã xong lên fsoft chỉ phải đứng ở vị trí liên đới ) ,do vậy để giảm thời gian phát triển phần mềm đặc biệt là kiểm thử bảo trì, những công ty lớn thường có hẳn một đội ngũ để thiết kế một model chung cho các loại hình kế toán.
    Còn xét ở góc độ nhỏ nhất , DP cũng được bắt nguồn từ các kỹ thuật lập trình hướng đối tượng ,tuân thủ các nguyên lý của kiến trúc phần mềm như
    - tăng độ kết dính, giảm độ ghép cặp
    - Nguyên lý đóng mở
    - nguyên lý nghịch đảo phụ thuộc
    ....
    ( tôi không đủ thời gian để viết chi tiết vì sẽ khá dài , các bạn có thể tìm theo các keyword trên để biết chi tiết hơn )

    Làm theo những nguyên lý này người ta sẽ thấy có nhiều cấu trúc được lặp lại ... ví dụ : kiến trúc 3 lớp mà nhiều bạn đã biết chính là 1 wellknow patern , hay patern MVC thực chất cũng là mô hình 3 lớp áp dụng cho tầng giao diện mà thôi.

    Kết thúc bài viết ( vì hơi khuya rồi ) tôi mình họa các bạn một ví dụ nhỏ về patern như sau :
    Bài toán : Viết một điều khiển scrollbar.cs cho phép đồng bộ tới dữ liệu hiển thị của DATAGRIDVIEW ( giá trị value hiện thời đồng bộ current row, Max = rowcount... ), thiết lập thông qua property DATASOURCE , ví dụ : scrollbar.DATASOURCE = this.datagridview1 .
    Rõ ràng nhiều bạn có thể chép miệng kêu dễ ẹt, nhưng nếu yêu câu của bài toán là :
    - Scrollbar này phải support nhiều loại GRID khác nhau : VSFLEXGRID, C1FLEXGRID, ....DATAGRID,DATAGRIDVIEW,LISTVIEW,ULTRA GRID..
    - Thêm mỗi loại lưới thì mã của Scrollbar.cs cũng không phải sửa !

    Bạn thấy đấy, nếu như ta không có tư duy abstract thì ta sẽ nghĩ : đơn giản thôi , tạo 1 loạt các grid object trong scrollbar class
    , cho thêm case of để xử lý !! nhưng việc này sẽ dẫn đến hệ quả: lớp scrollbar rất khó mở rộng, việc nhồi hàng đống code implement cho các loại lưới sẽ làm mã nguồn rối rắm, nặngh nề và rất khó bảo trì ( vì các loại lưới này đâu có giống nhau kể từ property đến event )!!
    Dựa trên nguyên lý chia để trị,biến tung độ thành hoành độ, thay vì chúng ta nhồi hết mã vào 1 class scrollbar thì chúng ta làm như sau :
    1. ĐỊnh nghĩa một Interface

    Code:
    # public interface IGridDataSource
    # {
    #     public enum PropertyLists
    #     {
    #         RowCountChanged,
    #         CurrentPostitonChanged,
    #         SourceChanged
    #     }
    #     object Object {
    #         get;
    #     }
    #     int RowCount {
    #         get;
    #     }
    #     int CurrentRow {
    #         get;
    #         set;
    #     }
    #     event PropertiesChangedEventHandler PropertiesChanged;
    #     delegate void PropertiesChangedEventHandler(PropertyLists Property);
    # }
    Implement code cho scrolbar.cs

    Code:
    # public class VScrollbar : UltraScrollBar
    # {
    #     private IGridDataSource _IGridDataSource;
    #     private void ResetInfo()
    #     {
    #         this.Enabled = false;
    #         if ((this.DataSource == null) || (this.DataSource.RowCount < 0)) {
    #             return;
    #         }
    #         if (this.DataSource.RowCount <= 0)
    #             return;
    #         this.Maximum = this.DataSource.RowCount - 1;
    #         this.Minimum = 0;
    #         this.SmallChange = 1;
    #         if (this.DataSource.CurrentRow < 0)
    #             return;
    #         this.Value = this.DataSource.CurrentRow;
    #         this.Enabled = true;
    #     }
    #     public IGridDataSource DataSource {
    #         get { return _IGridDataSource; }
    #         set {
    #             _IGridDataSource = value;
    #             this.ResetInfo();
    #         }
    #     }
    #     private void _IGridDataSource_PropertiesChanged(IGridDataSource.PropertyLists Property)
    #     {
    #         this.ResetInfo();
    #     }
    #    
    #     private void VScrollbar_ValueChanged(object sender, System.EventArgs e)
    #     {
    #         if (this.DesignMode)
    #             return;
    #         if (static_VScrollbar_ValueChanged_active == true)
    #             return;
    #         static_VScrollbar_ValueChanged_active = true;
    #         this.DataSource.CurrentRow = this.Value;
    #         static_VScrollbar_ValueChanged_active = false;
    #     }
    #     static bool static_VScrollbar_ValueChanged_active;
    #    
    # }
    Cuối cùng là implement code cho GRID nào cần tương tác với vscrollbar , ví dụ target là vsflexgrid ta tạo một control thừa kế từ vsflexgrid, rồi implement code cho interface IGridDataSource là oki ,phát triển bao nhiều loại lưới thì code của vscrollbar vẫn ko phải sửa ,đọc đến đây chắc bạn cũng hình dung ra kỹ thuật lập trình plugin là gì rồi !!! lớp scrollbar hoàn toàn không phụ thuộc vào bất cứ một GRID cụ thể nào mà nó chỉ phụ thuộc vào một interface IDATASOURCE , do vậy với bất cứ GRID loại mới nào có support và implement code cho interface này nó đều chạy OK!
    Đã được chỉnh sửa lần cuối bởi Haipt : 24-07-2008 lúc 01:09 AM.

  4. #4
    Ngày gia nhập
    11 2007
    Nơi ở
    Biết để làm gì?
    Bài viết
    827

    Em cũng có đọc qua về cái này và thấy quả thực quá khó. Có xem qua 1 bài,post lên cho mọi người tham khảo xem:
    Trích bài "Design Pattern - Thiết kế theo mô hình mẫu" - Phạm Đình Trường-
    Software Engineer, GrapeCity Inc
    Trong phát triển phần mềm hiện đại, kiến trúc tổng thể của dự án đóng một vai trò quan trọng, đặc biệt với bộ khung (framework) và mẫu thiết kế (design pattern). Bài viết này sẽ giúp các bạn hiểu được một cách tổng quan về pattern cũng như cách thức thiết kế một số pattern tiêu biểu.

    PATTERN là gì?

    Pattern mô tả một giải pháp chung đối với một vấn đề nào đó trong thiết kế thường được “lặp lại” trong nhiều dự án. Nói một cách khác, một pattern có thể được xem như một “khuôn mẫu” có sẵn áp dụng được cho nhiều tình huống khác nhau để giải quyết một vấn đề cụ thể. Trong bất kỳ hệ thống phần mềm hướng đối tượng nào chúng ta cũng có thể bắt gặp các vấn đề lặp lại.

    Đặc điểm chung:

    • Pattern được hiểu theo nghĩa tái sử dụng ý tưởng hơn là mã lệnh. Pattern cho phép các nhà thiết kế có thể cùng ngồi lại với nhau và cùng giải quyết một vấn đề nào đó mà không phải mất nhiều thời gian tranh cãi. Trong rất nhiều trường hợp, dự án phần mềm thất bại là do các nhà phát triển không có được sự hiểu biết chung trong các vấn đề về kiến trúc phần mềm. Ngoài ra, pattern cũng cung cấp những thuật ngữ và khái niệm chung trong thiết kế. Nói một cách đơn giản, khi đề cập đến một pattern nào đấy, bất kỳ ai biết pattern đó đều có thể nhanh chóng hình dung ra “bức tranh” của giải pháp. Và cuối cùng, nếu áp dụng pattern hiệu quả thì việc bảo trì phần mềm cũng được tiến hành thuận lợi hơn, nắm bắt kiến trúc hệ thống nhanh hơn.

    • Pattern hỗ trợ tái sử dụng kiến trúc và mô hình thiết kế phần mềm theo quy mô lớn. Cần phân biệt design pattern với framework. Framework hỗ trợ tái sử dụng mô hình thiết kế và mã nguồn ở mức chi tiết hơn. Trong khi đó, design pattern được vận dụng ở mức tổng quát hơn, giúp các nhà phát triển hình dung và ghi nhận các cấu trúc tĩnh và động cũng như quan hệ tương tác giữa các giải pháp trong quá trình thiết kế ứng dụng đối với một chuyên khu riêng biệt.

    • Pattern đa tương thích. Pattern không phụ thuộc vào ngôn ngữ lập trình, công nghệ hoặc các nền tảng lớn như J2EE của Sun hay Microsoft .NET Framework.

    Tiềm năng ứng dụng của pattern là rất lớn. Các thiết kế dựa trên pattern được sử dụng khá nhiều ở các phần mềm mã nguồn mở, trong nền tảng J2EE hoặc .NET... Trong các dạng ứng dụng này, có thể dễ dàng nhận ra một số tên lớp chứa các tiền tố hoặc hậu tố như Factory, Proxy, Adapter...

    PHÂN LOẠI PATTERN

    Pattern được phân loại ra làm 3 nhóm chính sau đây:

    • Nhóm cấu thành (Creational Pattern): Gồm Factory, Abstract Factory, Singleton, Prototype, Builder... Liên quan đến quá trình khởi tạo đối tượng cụ thể từ một định nghĩa trừu tượng (abstract class, interface).

    • Nhóm cấu trúc tĩnh (Structural Pattern): Gồm Proxy, Adapter, Wrapper, Bridge, Facade, Flyweight, Visitor... Liên quan đến vấn đề làm thế nào để các lớp và đối tượng kết hợp với nhau tạo thành các cấu trúc lớn hơn.

    • Nhóm tương tác động (Behavioral Pattern): Gồm Observer, State, Command, Iterator... Mô tả cách thức để các lớp hoặc đối tượng có thể giao tiếp với nhau.

    Dưới đây chúng ta sẽ tìm hiểu chi tiết một số pattern tiêu biểu nhất: Factory, Abstract Factory, Singleton, Proxy, Adapter và Wrapper. Chúng ta quy ước với nhau rằng “giao diện lớp” được hiểu như interface hoặc abstract class vì đây đơn thuần là các định nghĩa lớp.

    FACTORY PATTERN

    Định nghĩa

    Factory Pattern định nghĩa một lớp (interface, abstract, class) đóng vai trò như một “nhà xưởng” có nhiệm vụ khởi tạo đối tượng “cụ thể” khi ứng dụng chạy. Tại thời điểm thiết kế đối tượng này được định nghĩa trừu tượng.

    Đặc điểm

    Kiểm soát được các hoạt động trong suốt chu kỳ sống của đối tượng, như khởi tạo đối tượng, huỷ đối tượng... Đảm bảo cho các đối tượng được thực thi an toàn. Nắm được thông tin về những đối tượng nào được tạo ra và được khởi tạo ra sao. Nói cách khác, các đối tượng được quản lý tốt hơn và an toàn hơn với Factory Pattern.

    Đối tượng Factory thường được đặt tên theo những chuẩn khác nhau nhưng vẫn có thể dễ dàng nhận ra thiết kế Factory Pattern ẩn chứa trong đó. Ví dụ: BankFactory,...

    Tính chất đóng gói (encapsulation) thể hiện rõ trong Factory Pattern; các thông tin liên quan đến truy cập đối tượng được che giấu trong Factory. Thiết kế Factory luôn có một thủ tục khởi tạo đối tượng, ví dụ createObject().

    Factory Pattern tuân thủ nguyên tắc thiết kế DIP (Dependency Inversion Principle): không nên phụ thuộc vào những thứ quá cụ thể.

    Phân loại

    Factory Pattern được thiết kế theo một trong hai cách sau đây:

    Based-class Factory Pattern: Mẫu này sử dụng tính chất thừa kế để phân loại các đối tượng được tạo ra.

    Based-object Factory Pattern: Sử dụng mối quan hệ kết hợp để tham chiếu tới một đối tượng sẽ được tạo ra. Đối tượng được tạo ra sẽ trở thành một phần hay thuộc tính của lớp Factory. Chúng ta thường hay gặp loại này trong Abstract Factory Pattern được trình bày ở phần tiếp theo.

    ABSTRACT FACTORY PATTERN

    Định nghĩa

    Abstract Factory cung cấp một giao diện lớp có chức năng tạo ra một tập hợp các đối tượng liên quan hoặc phụ thuộc lẫn nhau mà không chỉ ra đó là những lớp cụ thể nào tại thời điểm thiết kế.

    Về bản chất, Abstract Factory Pattern chỉ khác Factory Pattern ở chỗ bản thân đối tượng Factory không được chỉ ra cụ thể tại thời điểm thiết kế, tức nó là một giao diện hoặc lớp trừu tượng (interface, abstract). Nếu như Factory Patttern phân loại đối tượng dựa trên tham số đầu vào thì đối với Abstract Factory Pattern, thủ tục createObject() còn phụ thuộc thêm vào các yếu tố phụ khác như môi trường hệ điều hành chẳng hạn. Ứng với mỗi yếu tố phụ thứ hai ta có một lớp Factory cụ thể.

    Thiết kế động với Abstract Factory
    Một trong những vấn đề gặp phải là khung giao diện Abstract Factory thường hay bị sửa đổi, thí dụ như bổ sung thủ tục chẳng hạn, khi đó các lớp cụ thể thực thi giao diện này sẽ phải được dịch và triển khai lại. Để giảm nhẹ vấn đề này người ta thường thiết kế giao diện Abstract Factory một cách linh động.

    SINGLETON PATTERN
    (Static Factory Pattern)

    Định nghĩa

    Singleton Pattern đảm bảo một lớp chỉ có một thực thể (instance) duy nhất được tạo ra và đồng thời cung cấp một truy cập toàn cục đến đối tượng được tạo ra.
    Chúng ta xét trường hợp có nhiều đối tượng có cùng chung một số tính chất nào đó được tạo ra ứng với mỗi một yêu cầu từ các đối tượng khách (client), lúc này độ phức tạp sẽ tăng lên và ứng dụng sẽ chiếm dụng nhiều vùng nhớ hơn. Singleton Pattern là một giải pháp đặc biệt của Factory Pattern ở chỗ đối tượng sinh ra là điểm truy cập toàn cục “duy nhất” đối với mọi chương trình gọi đến, hay nói một cách khác tất cả các đối tượng khách gọi đến đều chia sẻ đối tượng được tạo ra.

    Ứng dụng rõ rệt nhất của Singleton Pattern có thể thấy trong dịch vụ web khi triệu gọi các đối tượng từ xa, ở đó đối tượng nằm trên server hoặc sẽ phục vụ chung cho tất cả các ứng dụng khách (singleton) hoặc sẽ chỉ đáp ứng một ứng dụng khách riêng lẻ nào đó rồi tự bị phá huỷ sau đó (single call).

    Về các mẫu thiết kế tiêu biểu trong nhóm cấu thành: Factory, Abstract Factory và Singleton, các bạn có thể tham khảo thêm tài liệu về phương pháp xây dựng cụ thể cũng như mã nguồn chương trình viết bằng C#.NET tại địa chỉ:
    http://www.codeproject.com/gen/desig...assFactory.asp

    PROXY PATTERN

    Định nghĩa

    Proxy Pattern là mẫu thiết kế mà ở đó tất cả các truy cập trực tiếp một đối tượng nào đó sẽ được chuyển hướng vào một đối tượng trung gian (Proxy Class).
    Nếu như Factory Pattern giúp quản lý đối tượng tốt hơn thì Proxy Pattern lại có nhiệm vụ bảo vệ việc truy cập một đối tượng thông qua Proxy, hay còn gọi là truy cập gián tiếp. Proxy được ủy quyền về phía ứng dụng khách cho phép tương tác với đối tượng đích theo những cách khác nhau; như gửi yêu cầu một dịch vụ nào đó, theo dõi trạng thái và vòng đời đối tượng, xây dựng lớp vỏ bảo vệ đối tượng... Thí dụ chúng ta phát hiện ra một đối tượng trong một thư viện DLL có thể bị khai thác truy cập vào một số trường quan trọng, khi đó chúng ta không thể mở mã nguồn thư viện đã được dịch để vá lỗ hổng, giải pháp lúc này là xây dựng một proxy ngăn chặn truy cập các trường đó và cuối cùng biên dịch lại thành một DLL mới.

    Phân loại

    Độ phức tạp của giải pháp sử dụng Proxy Pattern phụ thuộc vào tình huống bài toán đưa ra, chúng ta sẽ lần lượt tìm hiểu nguyên tắc làm việc của các proxy dưới đây:
    Remote Proxy: Client truy cập qua remote proxy để tham chiếu tới một đối tượng được bảo vệ nằm bên ngoài ứng dụng (trên cùng máy hoặc máy khác) như dịch vụ Windows, dịch vụ web, ứng dụng ở xa... Mô hình này "che giấu" đối tượng được triệu gọi đang nằm ở rất xa đâu đó và client có vẻ như truy cập vào đối tượng nằm trên cùng một chuyên khu làm việc (domain).

    Virtual Proxy: Virtual Proxy tạo ra một đối tượng trung gian mỗi khi có yêu cầu tại thời điểm thực thi ứng dụng, nhờ đó làm tăng hiệu suất của ứng dụng.

    Monitor Proxy: Monitor Proxy sẽ thiết lập các ràng buộc bảo mật trên đối tượng cần bảo vệ, ngăn không cho client truy cập một số trường quan trọng của đối tượng.

    Protection Proxy: Đối với proxy này thì phạm vi truy cập của các client khác nhau sẽ khác nhau. Protection Proxy sẽ kiểm tra các quyền truy cập của client khi có một dịch vụ được yêu cầu.

    Cache Proxy: Cung cấp không gian lưu trữ tạm thời cho các kết quả trả về từ đối tượng nào đó, kết quả này sẽ được tái sử dụng cho các client chia sẻ chung một yêu cầu gửi đến và do đó làm tăng đáng kể hiệu suất chương trình.

    Firewall Proxy: Bảo vệ đối tượng từ chối các yêu cầu xuất xứ từ các client không tín nhiệm.

    Smart Reference Proxy: Là nơi kiểm soát các hoạt động bổ sung mỗi khi đối tượng được tham chiếu, ví dụ như kiểm soát vòng đời của đối tượng, lưu lại số lần tham chiếu vào đối tượng...

    Synchronization Proxy: Đảm bảo nhiều client có thể truy cập vào cùng một đối tượng mà không gây ra xung đột. Thực tế có rất nhiều tình huống khiến chúng ta phải nghĩ đến thiết kế này. Một synchronization proxy được thiết lập có thể kiểm soát được nhiều yêu cầu cập nhật dữ liệu một cách đồng thời, tại thời điểm bắt đầu cập nhật chỉ có một client với mức ưu tiên cao nhất giành được khoá để đánh dấu rằng các client khác cần phải chờ đến lượt.

    Synchronization proxy hoạt động rất hiệu quả và phổ biến trong thiết kế các bài toán đa tuyến. Một hiện tượng hay xảy ra với thiết kế này là khi một client nào đó chiếm dụng khoá khá lâu (và thậm chí là mãi mãi) khiến cho số lượng các client trong danh sách hàng đợi cứ tăng lên, và do đó hoạt động của hệ thống bị ngừng trệ, có thể dẫn đến hiện tượng “tắt nghẽn” là hiện tượng khoá được giữ vô thời hạn bởi một đối tượng nào đó. Trong trường hợp này người ta cải tiến thành mẫu thiết kế phức tạp hơn, đó là Copy-On-Write Proxy.

    Copy-On-Write Proxy: Cope-On-Write Proxy đảm bảo rằng sẽ không có client nào phải chờ vô thời hạn. Thiết kế này rất phức tạp do đó chỉ nên ứng dụng Copy-On-Write Proxy thay thế Synchronization Proxy khi hệ thống được dự đoán sẽ thường xuyên bị ngừng trệ hoặc có hiện tượng “tắt nghẽn” xảy ra.

    Đặc điểm chung

    Proxy Pattern có những đặc điểm chung sau đây:

    • Cung cấp mức truy cập gián tiếp vào một đối tượng.

    • Tham chiếu vào đối tượng đích và chuyển tiếp các yêu cầu đến đối tượng đó.

    • Cả proxy và đối tượng đích đều kế thừa hoặc thực thi chung một lớp giao diện. Mã máy dịch cho lớp giao diện thường “nhẹ” hơn các lớp cụ thể và do đó có thể giảm được thời gian tải dữ liệu giữa server và client.

    ADAPTER PATTERN

    Định nghĩa

    Adapter Pattern biến đổi giao diện của một lớp thành một giao diện khác mà các đối tượng client có thể hiểu được. Lớp với giao diện được tạo ra đó gọi là Adapter. Nguyên tắc cơ bản của Adapter Pattern nằm ở chỗ làm thế nào để các lớp với các giao diện không tương thích có thể làm việc được với nhau.

    Nguyên lý xây dựng Adapter Pattern khá đơn giản: chúng ta xây dựng một lớp với một giao diện mong muốn sao cho lớp đó giao tiếp được với một lớp cho trước ứng với một giao diện khác.

    Adapter Pattern không quản lý tập trung các đối tượng gần giống nhau như Factory Pattern, mà kết nối với nhiều lớp không có liên quan gì với nhau. Ví dụ lớp A sau khi thực thi giao diện của nó và vẫn muốn bổ sung các phương thức từ một lớp B nào đó, chúng ta có thể kết nối A với B thông qua hình thức kế thừa hoặc liên kết đối tượng như một thành phần. Adapter Pattern có sự giống nhau một chút với Proxy Pattern ở chỗ nó tận dụng tối đa tính chất “uỷ quyền” (delegation); lớp Adapter sẽ kết nối với một đối tượng nào đó gọi là Adaptee và Adapter sẽ được uỷ quyền truy cập vào Adaptee, lớp Adapter đóng vai trò như một kênh trung gian để client truy cập vào một số các thành phần quan trọng của lớp Adaptee.

    Đặc điểm

    • Adapter Pattern hướng tập trung vào giải quyết sự tương thích giữa hai giao diện đang tồn tại, giảm công sức viết lại mã lệnh xuống mức tối thiểu có thể được.

    • Tái sử dụng giao diện cũ và Adapter Pattern chỉ thực sự cần thiết khi mọi thứ đã được thiết kế từ trước.

    Phạm vi ứng dụng

    Adapter Pattern được ứng dụng trong các trường hợp:

    • Cần tích hợp một vài module vào chương trình.

    • Không thể sát nhập trực tiếp module vào chương trình (ví dụ như module thư viện đã được dịch ra .DLL, .CLASS...).

    • Module đang tồn tại không có giao diện mong muốn như:

    - Cần nhiều hơn phương thức cho module đó.

    - Một số phương thức có thể được nạp chồng.

    WRAPPER PATTERN

    Wrapper Pattern là một trường hợp đặc biệt của Adapter Pattern. Nếu một Adapter chỉ đơn thuần là “nhúng” (wrap) các lớp với các giao diện không tương thích với nhau để chúng có thể hoạt động cùng nhau thì có thể được gọi bằng tên riêng Wrapper Pattern. Khi đó lớp Adapter còn được gọi là lớp Wrapper. Đây là quan hệ “có một”, tức là một giao diện không tương thích có thể được nhúng vào thành một phần của một giao diện khác.

    Đặc điểm

    Đối tượng Wrapper mô phỏng tất cả các hành vi (hàm, thủ tục) của giao diện được nhúng bởi các hành vi với tên y hệt. Thí dụ nếu lớp được nhúng A có thủ tục SpecificRequest() thì lớp Wrapper cũng phải có thủ tục SpecificRequest() tham chiếu đến thủ tục cùng tên của A. (Ngoài ra đối tượng Wraper có thể được bổ sung các phương thức khác nếu cần thiết). Đặc điểm này được đưa ra dựa trên nguyên tắc thiết kế “Law of Demeter” nói rằng không nên tham chiếu một đối tượng sâu hơn một lớp.

    Các phương thức trong Adaptee được “nhúng” trong Wrapper bằng cách truyền lời gọi cùng với các tham số tới phương thức tương ứng trong Adaptee, và trả về kết quả giống như vậy. Các thành viên (thuộc tính, trường, sự kiện) được nhúng trong Wrapper có tính chất giống hệt như trong các lớp được nhúng (tên, kiểu dữ liệu, phạm vi truy cập...).

    Từ các đặc điểm ở trên, có thể thấy rằng Wrapper Pattern cho phép một module chương trình tương tác được trong một môi trường khác biệt với môi trường phát triển của module đó (ví dụ C++ và Java).

    Khác biệt giữa Wrapper Pattern và Adapter Pattern

    Sự khác biệt giữa Wrapper và Adapter nằm ở mục đích sử dụng: Adapter Pattern định hướng cho một đối tượng đang tồn tại có thể làm việc được với các đối tượng khác và biến đổi logic theo một cách thức nào đó, trong khi Wrapper Pattern chỉ đơn thuần cung cấp một giao diện kết hợp các đối tượng được xây dựng từ cùng một ngôn ngữ hoặc khác ngôn ngữ, trên cùng một hệ điều hành hoặc trên những hệ điều hành khác nhau.

    Proxy Adapter Pattern

    Nếu một lớp Adapter đóng thêm vai trò như một proxy bảo vệ cho Adaptee thì ta có mô hình Proxy Adapter Pattern, trong trường hợp này chúng ta có thể đặt tên lớp với nghĩa kết hợp, ví dụ BankProxyAdapter.

    Lời kết

    Bài viết này đưa ra một số mẫu thiết kế tiêu biểu giúp các bạn thấy được tầm quan trọng của design pattern trong việc nâng cao chất lượng phần mềm ở các yếu tố: hiệu suất ứng dụng, độ ổn định, tái sử dụng, tính bảo mật... Các bạn có thể tìm hiểu thêm về các mẫu thiết kế cao cấp khác ở rất nhiều tài liệu thiết kế phần mềm.
    Cánh Chym ứ mỏi

  5. #5
    Ngày gia nhập
    06 2007
    Nơi ở
    HCM
    Bài viết
    365

    Sau một thời gian Dr tìm hiểu và làm việc trong lĩnh vực deverlopment phần mềm, Dr thấy mình viết code tương đối tốt và sáng sủa với convention standards, và các chú thích rõ ràng. Cho đến khi Dr tiếp cận và tìm hiểu với Design pattern thì Dr thấy là code của mình viết thực sự là rất rối rắm, khó khăn trong việc bảo trì và phát triển.
    Em nghĩ là em rối rắm ở chỗ nào ??? đã code theo standard , chú thích rõ ràng thì làm gì có chuyện rối rắm trừ khi cái standard đó là do mình tự nghĩ ra, đến khi làm với team thì xung đột với std của team !!! nếu hiểu theo ý của mình thì chủ đề này sẽ rất rộng vì nó còn liên quan cả đến kỹ thuật refactoring code!!! he he xem ra sẽ có tới version 100 ....
    @dieucay555 : không hề khó nếu ta có cách tiếp cận hợp lý , hãy đi đúng hướng bằng cách vẫn dụng thành thạo interface, abstract class cũng như những nguyên lý lập trình hướng đối tượng mà mình đã liệt kê ở trên... pls search vì đó là khởi nguồn của mọi dp
    Đã được chỉnh sửa lần cuối bởi Haipt : 24-07-2008 lúc 01:33 AM.

  6. #6
    Ngày gia nhập
    07 2006
    Nơi ở
    Hanoi, Vietnam
    Bài viết
    2,750

    Mặc định Nghiên cứu về Design Pattern trong lập trình và sản xuất phần mềm. (vesion 1)

    Tuân thủ tốt convension standard + chú thích rõ ràng (chưa chắc chắn hoàn toàn, không loại trừ ai), đã là hoàn toàn tốt, và khá tốt với nhiều người, ít nhất là trong một bộ phận nào đó. Nhưng hãy thử nhìn một đống code, sau một thời gian mình xem lại cũng đã thấy bắt đầu rối rắm vì thiếu đi cái nền tảng.

    Không nói đến sau một thời gian, ngay bây giờ hãy xem chúng ta sẽ trình bày vấn đề bài toán của mình như thế nào với người khác, với thời gian tiết kiệm và hiệu quả nhất (Hãy nhớ là chúng ta không làm việc với một mình). Hãy nói và nghĩ về khả năng tái sử dụng, mở rộng hoặc thay đổi bất cứ thứ gì mà không ảnh hưởng đến toàn bộ những gì đã làm? vân vân và ...

    Có rất nhiều sự khác biệt nhất giữa việc coding và khi anh đưa bài toán về dạng tổng quát hóa vấn đề, đó chính là lý do mà người ta cần phải quan tâm đến pattern. Đó là vấn đề của phát triển phần mềm, và đó là những thứ có thể giúp chúng ta thành công hơn. (Nó đã được thực thi nhiều nơi mà đã mang lại thành công lớn cho nhiều người, đó chính là lý do mà Dr tin tưởng để nghiên cứu nó)

    Bây giờ tạm gác vấn đề đó, ta bàn cụ thể hơn về từng pattern cụ thể, sau đây Dr sẽ phân tích tại sao code của mình vẫn còn sự rối rắm.

    Về vấn đề này, quả thật có rất nhiều người cho rằng: nó quá tốn kém thời gian cho sự tìm hiểu và không cần có nó vẫn có thể làm được. Điều này hoàn toàn không sai nhưng quả thật nó là không tốt cho công việc cũng như sự phát triển công ty của bạn. Để không làm quá khó, thì Dr nghĩ ta có thể bàn đến một số pattern ở mức implement, nhưng Dr chỉ bắt đầu khi Dr thấy mọi người thực sự hứng thú với vấn đề này, (hoặc chỉ khi Dr hứng thú với một vấn đề nào đó và muốn đưa lên đây). OK?
    Email: admin[@]congdongcviet.com | CC to: info[@]congdongcviet.com
    Phone: 0972 89 7667 (Office: 04 6329 2380)
    Yahoo & Skype: dreaminess_world (Vui lòng chỉ rõ mục đích ngay khi liên hệ, cảm ơn!)

    Một người nào đó coi thường ý thức kỷ luật cũng có nghĩa là người đó đã coi thường tương lai số phận của chính bản thân người đó. Những người coi thường ý thức kỷ luật sẽ không bao giờ có được sự thành công trong sự nghiệp!

  7. #7
    Ngày gia nhập
    06 2007
    Bài viết
    206

    Đóng móc chưa nhỉ.

    Tui nhìn hoài về Factory Pattern mà thấy nó sao sao, ko phân biệt đc.
    Anh em tiếp tục đc ko? Bắt đầu từ Factory Pattern nha.
    Thông hết rồi hẳn qua cái khác.
    Thà để chửi dốt 1 lần, còn hơn ngu cả đời.

  8. #8
    Ngày gia nhập
    09 2007
    Bài viết
    724

    Factory pattern gồm 2 loại:
    Abstract Factory và Factory Method bạn muốn nói về thằng nào ở đây ?

  9. #9
    Ngày gia nhập
    06 2007
    Bài viết
    206

    Abstract Factory trc đi bạn.
    Thà để chửi dốt 1 lần, còn hơn ngu cả đời.

  10. #10
    Ngày gia nhập
    01 2007
    Nơi ở
    Somewhere I belong
    Bài viết
    168

    Trích dẫn Nguyên bản được gửi bởi zkday2686 Xem bài viết
    Factory pattern gồm 2 loại:
    Abstract Factory và Factory Method bạn muốn nói về thằng nào ở đây ?
    Zk làm một tut về Pattern đi, dạo này vtn code cảm thấy còn nhiều rối rắm chưa thực sự tối ưu, đang tính ngâm cứu về pattern, Zkday mà làm cái tut thì tớ cảm ơn nhiều lắm )
    In code we trust

Các đề tài tương tự

  1. Design Pattern Framework (2.0, 3.5, 4.0)
    Gửi bởi OWickedFox trong diễn đàn Công cụ, ebooks C#, ASP.NET, và Windows Mobile
    Trả lời: 17
    Bài viết cuối: 10-02-2017, 12:19 AM
  2. Phần I: Mẫu chiến lược Strategy - Series bài dịch Design Pattern for Dummies
    Gửi bởi haihth trong diễn đàn Tutorials và Thủ thuật lập trình Java
    Trả lời: 13
    Bài viết cuối: 13-10-2015, 05:59 AM
  3. Phần I: Mẫu Decorator và Factory - Series bài dịch Design Pattern for Dummies
    Gửi bởi haihth trong diễn đàn Tutorials và Thủ thuật lập trình Java
    Trả lời: 18
    Bài viết cuối: 12-06-2014, 11:33 PM
  4. Sử dụng Singleton(design pattern) cho đăng nhập trong MVC3 (Razor)
    Gửi bởi kevinquang91 trong diễn đàn Thắc mắc lập trình ASP.NET
    Trả lời: 5
    Bài viết cuối: 14-04-2013, 09:02 PM
  5. Design Pattern là gì?
    Gửi bởi evaritgalois trong diễn đàn Thắc mắc lập trình C/C++/C++0x
    Trả lời: 3
    Bài viết cuối: 17-06-2009, 05:15 PM

Quyền hạn của bạn

  • Bạn không thể gửi đề tài mới
  • Bạn không thể gửi bài trả lời
  • Bạn không thể gửi các đính kèm
  • Bạn không thể chỉnh sửa bài viết của bạn