Các mẫu thiết kế phần mềm hướng đối tượng & áp dụng

LỜI NÓI ĐẦU Phần mềm ngày càng trở nên phức tạp, thách thức trong những năm tới không phải là vấn đề tốc độ, kinh phí hay sức mạnh của nó mà sẽ là độ phức tạp.Vì vậy chúng ta phải dần loại bỏ chúng. Một cách tổng quan khi xây dựng phần mềm thì ta phải quan tâm đến tổ chức, các quan hệ cấu trúc hình thành nên hệ thống. Do khả năng của con người là có giới hạn khi khảo sát các vấn đề phức tạp như tổng thể. Thông qua mô hình hoá ta sẽ giới hạn vấn đề bằng cách nghiên cứu tập trung vào một khía cạnh của vấn đề và vào một thời điểm. Không nên giải quyết tất cả các vấn đề vào một lần thiết kế, cần tranh thủ sử dụng lại những trường hợp đã làm, khi ta tìm được một giải pháp tốt, cần phát huy nó cho lần sau. Xu thế áp dụng phương pháp hướng đối tượng thay cho phương pháp cấu trúc ngày càng phổ biến khi xây dựng các hệ thống phần mềm lớn và phức tạp. Do tầm quan trọng và tính linh hoạt của phương pháp phân tích thiết kế hướng đối tượng được sử dụng rộng rãi tại các nước đang phát triển và đã được áp dụng tại Việt Nam. Phân tích hướng đối tượng là một vấn đề khó, càng khó hơn cho người thiết kế mới vì họ thường lúng túng trong vấn đề chọn lựa phương pháp nào tối ưu cho dự án, cho hệ thống của họ; đồng thời làm sao sử dụng lại và nâng cấp từ những thuật toán hướng đối tượng đã được sử dụng trước đó. Điều này cũng gây trở ngại cho những người cần tìm hiểu về hệ thống đang tồn tại, vì tính ưu việt và đặc trưng của các ngôn ngữ hướng đối tượng nên họ thường hay khó khăn nhận biết các lớp, các đối tượng... kế thừa đặc biệt là trong các dự án lớn, hệ thống lớn Khi gặp một vấn đề, người thiết kế đã lựa chọn một phương pháp tối ưu, sao cho nó tốt nhất, phù hợp nhất, sử dụng dễ, giảm thiểu được độ phức tạp cũng như tiết kiệm công sức cho những lần phát triển lần sau, cũng như những lần tái sử dụng lại chúng. Thông thường khi tìm ra một giải pháp tốt, ta thường lưu lại để sử dụng chúng cho lần sau, để lần sau sẽ ít tốn thời gian để tìm hiểu mà vẫn có thể áp dụng chúng tốt. Chính vì dựa vào khái niệm mẫu thiết kế của Christopher Alexander khi áp dụng trong thiết kế các toà nhà, giúp cho người kiến trúc sư dựa vào một số khuôn dạng sẵn có mà thiết kế theo, hoặc cải tiến nó. Các chuyên gia trong vấn đề thiết kế và lập trình đã đúc rút ra kinh nghiệm để đưa ra một số khuôn dạng chung về mẫu thiết kế phần mềm mà khi áp dụng đáp ứng được phần nào yêu cầu khắt khe của công nghệ phần mềm hiện đại. Và các nhà thiết kế sau này coi đó là một từ vựng chung để thiết kế cũng như khi áp dụng và hiểu chúng để lập trình. Trên thực tế không thể có một mẫu hoàn chỉnh cho phần mềm, nhưng chắc chắn có thể tìm ra một khuôn dạng chung hoàn chỉnh cho các mẫu này. Khó khăn khi phát triển công nghệ phần mềm và sử dụng Mẫu thiết kế. Phân tích và thiết kế hướng đối tượng là khó, nhưng mục đích thiết kế hướng đối tượng nhằm được sử dụng lại lần sau lại càng khó hơn. Ta cần phải tìm ra các đối tượng, các phần(factor) thích hợp cho từng lớp, từng đối tượng, xác định được hệ thống giao diện cần phải kế thừa như thế nào và thiết lập mối quan hệ giữa chúng. Chính vì những phức tạp đó mà rất khó và lâu dài các chuyên gia mới tìm ra được một khuôn dạng chung cho phần mềm, mặt khác các dự án và các hệ thống phần mềm khi phát triển đều có mức độ trừu tượng hoá cao, nên ngôn ngữ đôi khi cũng ở mức trừu tượng hoá và rất khó cho người sử dụng khi tìm hiểu về chúng. Ngay cả các chuyên gia khi hoàn thành nghiên cứu cũng thừa nhận họ không hiều về những gì mà họ viết ra trong lần viết đầu tiên. Đặc biệt là khi hiểu được và thiết kế theo hướng đối tượng, để áp dụng các mẫu thiết kế này vào trong hệ thống, dự án của mình thì người áp dụng cần phải nắm rõ và vững ít nhất một ngôn ngữ lập trình hướng đối tượng và phải có kinh nghiệm trong thiết kế hướng đối tượng. Theo kinh nghiệm làm việc, và bằng chính khả năng của mình, cũng như độ nhạy cảm trong phân tích mà người phát triển mới có khả năng áp dụng chúng vào trong hệ thống của mình, và kết hợp chúng một cách tối ưu nhất. Tại Việt nam, do đây là một vấn đề mới, và rất khó để tìm hiểu nên chưa có nhóm nghiên cứu cụ thể nào về các mẫu thiết kế, và chúng hầu hết được áp dụng theo phán đoán của người thiết kế, do ngôn ngữ mang tính trừu tượng cao nên khó có thể áp dụng chúng một cách chính xác nhất để phát huy tính năng ưu việt của nó. Nhưng một khi đã áp dụng các mẫu này vào thiết kế thì người thiết kế sẽ thấy rất thuận lợi và giảm thiểu công sức cũng như độ phức tạp đi rất nhiều. Hiểu và áp dụng các mẫu thiết kế này vào trong hệ thống cũng là một tiêu chuẩn quan trọng của các nhà lập trình viên ở các nước công nghệ phần mềm phát triển. Mục đích của đồ án. Mục đích của đồ án trong đợt thực tập tốt nghiệp và đồ án tốt nghiệp là nghiên cứu cụ thể và chi tiết đến các vấn đề nhỏ của các mẫu thiết kế mà trong đợt thực tập tốt nghiệp chưa có điều kiện tiếp cận và tìm hiểu đến và hoàn thiện một cách căn bản các hiểu biết về Design Patern. Đây là giai đoạn chuyển tiếp quan trọng và tiến hành các công việc áp dụng các mẫu thiết kế này vào trong thực tế, sử dụng các kiến thức đã nghiên cứu được cùng với các công cụ sẵn có như UML, C++, VC++ để thiết kế và áp dụng chúng một cách hoàn thiện và đầy đủ. Tuy nhiên, các mẫu thiết kế là một vấn đề rất khó, nó khó đối với cả những chuyên gia lập trình đầy kinh nghiệm, và bản thân nó cũng rất trừu tượng, đòi hỏi người tìm hiểu về nó phải có một kiến thưcs nhất định và rất cần thiết trên một mảng rộng các vấn đề, đặc biệt là cần phải có giác quan phán đoán mà chỉ có thể có được khi người đó có kiến thức vững về phần mềm, có kinh nghiệm chuyên sâu. Do kinh nghiệm thực tế chưa có nhiều, và cũng chưa có một tài liệu nào ở Việt Nam đã có nghiên cứu về vấn đề này, các tài liệu mà em tiếp xúc cũng như tìm hiểu đều là dựa theo các thông tin trong nghiên cứu của các chuyên gia mà cụ thể là của bốn chuyên gia: Erich Gamma, Richard Helm, Ralph Johnson và John Vlissides cùng với rất nhiều các nghiên cứu của các chuyên gia khác, và các dự án mà em tìm hiểu khi áp dụng các mẫu dự án này đều ở mức trừu tượng cao, mà để hiểu được nó, chỉ có các nhà lập trình và thiết kế dày dặn kinh nghiệm mới có thể hiểu được chúng một cách cặn kẽ và đầy đủ nhất. Vì vậy, trong đồ án này, em nghiên cứu tất cả 23 mẫu thiết kế mà được cụ thể hoá, và được coi là đầy đủ cho khuôn dạng chung của phần mềm hiện đại, nhưng để áp dụng được tất cả chúng là điều rất phức tạp, vì tuỳ vào từng dự án và từng hệ thống cụ thể mà ta có thể áp dụng từng mẫu thiết kế một, hay là ta kết hợp nhuần nhuyễn chúng để đưa ra hiệu quả cao nhất. Trên thực tế, ở nước ngoài cũng như ở Việt Nam, chưa có một dự án nào áp dụng đầy đủ 23 mẫu thiết kế này, và ở Việt Nam hiện nay cũng có ít công ty áp dụng chúng trong thiết kế. Trong quá trình nghiên cứu và tìm hiểu, em có điều kiện thực tập, và được tạo điều kiện tham gia vào nghiên cứu và áp dụng một số mẫu trong thiết kế dự án của công ty sản xuất phần mềm Khai Trí, và thấy được hiệu quả hơn hẳn khi áp dụng chúng vào trong thiết kế của dự án công ty. Đó là các mẫu: Abstract Factory Singleton Adapter Facade Template Method State Method Factory Method Do đây là một dự án đươc phát triển và được nghiên cứu từ lâu, sản phẩm đưa ra thị trường và đã được chấp nhật một cách có hiệu qủa, và trong thực tế, nó đã đáp ứng được yêu cầu đòi hỏi của phần mềm hiện đại. Việc áp dụng các mẫu thiết kế này đã có kết quả cụ thể và thực tiễn trong sản phẩm của công ty. Việc nghiên cứu đồ án giải quyết điều gì Như trên đã nói, các mẫu thiết kế là một vấn đề rất khó và rất trừu tượng, nó không phải là dễ cho những người mới tìm hiểu lần đầu, nhưng không thể thiếu nếu bạn muốn trở thành một chuyên gia lập trình. Nghiên cứu về các mẫu thiết kế trước hết là một nghiên cứu kỹ thuật phần mềm mới. Tất nhiên nhiên là nghiên cứu một cách cặn kẽ các vấn đề và chi tiết nhỏ ở từng mẫu thiết kế một là có thể nắm được một cách cơ bản và có thể áp dụng thực tế được. Kết quả của nghiên cứu này là một tài liệu làm việc về các mẫu thiết kế, với các nội dụng cụ thể để giúp cho bạn có thể phần nào hiểu được và phần nào áp dụng được trong thực tế. Nhưng muốn tìm hiểu sâu hơn, thì cần phải bằng chính khả năng của người cần tìm hiểu mới có thể rút ra được hiểu biết thấu đáo về các mẫu thiết kế. Sau đó là so sánh việc áp dụng các mẫu thiết kế này so với việc khi chưa áp dụng chúng. Trong nhiệm vụ này có thêm yêu cầu tìm hiểu dự án cụ thể và để từ đó thấy được khi áp dụng chúng thấy hiệu quả và phù hợp. Đồng thời đưa ra được một dự án cụ thể khi áp dụng chúng, và chi tiết hoá từng phần khi áp dụng và giải quyết vấn đề khi áp dụng các mẫu này. Việc giải quyết đồ án ở giai đoạn tốt nghiệp được thực hiện như thế nào? Trong giai đoạn đồ án tôt nghiệp, em nghiên cứu thêm, vì đây là vấn đề khó và phức tạp, trở ngại lớn nhất là chưa có một nghiên cứu cụ thể nào ở Việt Nam, và được tham gia khi áp dụng chúng vào trong một dự án cụ thể. Trong lần thực hiện này, em phải nghiên cứu sâu hơn về UML, các kiến thức về Rational Rose, và các quy trình phần mềm. Do kiến thức thực tế chưa có nhiểu và hạn chế về thời gian để tìm hiểu về một dự án đã được phát triển từ lâu, cũng như thời gian nâng cấp chúng nên hạn chế thời gian chưa sâu sắc vấn đề. Và tôi chỉ tập trung vào giải quyết một số mẫu trong dự án, phù hợp với dự án phát triển. Ngoài ra để áp dụng các mẫu thiết kế này còn yêu cầu rất nhiều nội dung nữa, tôi chỉ thực hiện nghiên cứu lý thuyết và chỉ áp dụng phần nào lý thuyết vào thực tế, và còn nhiều mẫu thiết kế chưa thể đưa vào dự án này được, đồng thời có ít điều kiện được nghiên cứu các dự án đã áp dụng các mẫu này ở Viêt nam cũng như các phần mềm cụ thể khác. ĐẶT VẤN ĐỀ Tóm tắt chương Chương mở đầu này tôi xin được giới thiệu một số nét chung về đồ án tốt nghiệp mà tôi lựa chọn để thực hiện. Đồng thời, trong phần này, tôi cũng trình bày một số nét tổng quan về đề tài của đồ án tốt nghiệp, về những lý do, động cơ thúc đẩy nghiên cứu và tìm hiểu đề tài của tôi, về những mục đích đặt ra và yêu cầu của đề tài mà tôi đã nghiên cứu thực hiện trong thời gian qua. Mục đích của đề tài Như tên của đề tài đồ án “ Các mẫu thiết kế phần mềm hướng đối tượng và áp dụng”, chính là thể hiện mục đích chính của đề tài. Việc nghiên cứu các mẫu dáng thiết kế không chỉ là nghiên cứu một kỹ thuật phân tích, thiết kế mới, mà hơn thế nữa là phương pháp tiếp cận khoa học và giải quyết vấn đề theo những phương pháp tối ưu hóa mà các chuyên gia phân tích , thiết kế và lập trình đã xây dựng thành các mẫu cụ thể. Nó giải quyết được những yêu cầu kiến thức cơ bản đối với người áp dụng và thiết kế theo các mẫu cũng như cần phải nắm rõ hơn để thiết kế tốt hơn, đáp ứng được yêu cầu của xu thế phát triển phần mềm hiện nay. Giới thiệu bài toán, nhiệm vụ của đề tài Nhiệm vụ của đề tài có hai phần rất rõ ràng đó là : Nghiên cứu về Mẫu thiết kế Áp dụng Mẫu thiết kế đã nghiên cứu vào giải quyết một dự án và một số bài toán con. Về lý thuyết nghiên cứu về Mẫu thiết kế, tôi xin trình bày tổng quan về tư tưởng chính mang tính cốt lõi của các tác giả để phát triển và hình thành nên Mẫu thiết kế. Do Mẫu thiết kế không đơn thuần là một công nghệ mớI mà nó thực sự là một hướng tiếp cận mớI và đầy đủ cho các nhà lập trình và phân tích thiết kế. Vì Mẫu thiết kế chỉ thích hợp vớI các ngôn ngữ lập trình hướng đốI tượng và cách phân tích thiết kế hướng đốI tượng. Trong khi sử dụng, nó không tách khỏI UML, cũng đã cho ta cách ứng dụng trực tiếp các mẫu thiết kế này. Về phần áp dụng Mẫu thiết kế vào thực hiện một dự án, tôi xin trình bày nộI dung của dự án lớn và phần thực hiện của tôi trong dự án lớn đó, là một phần của dự án nhỏ. Qua đó để bạn đọc xem được tổng quan về dự án lớn và nắm được chi tiết các ưu điểm của dự án này khi áp dụng Mẫu thiết kế vào thiết kế so vớI dự án khi áp dụng kiểu phân tích thiết kế cũ, cũng như nhìn ra được cách thiết kế giúp cho dự án được nâng cấp lên dựa trên bản thiết kế cũ. Dựa vào các thiết kế dự án cụ thể này mà ta có thể nhìn thấy rõ ràng cách thiết kế dựa trên Mẫu thiết kế và những ưu điểm của nó. Lý do chọn đề tài. Làm phần mềm không chỉ là lập trình, tạo mã một cách đơn thuần để cuối cùng ra một chương trình có khả năng chạy được. Điều đó chỉ thích hợp với các dự án thật nhỏ, và rất nhỏ, hay đúng hơn là các chương trình đơn giản. Với các dự án phần mềm còn có rất nhiều điều quan trọng hơn thế, ở mức phân tích thiết kế, ở mức quản lý, phối kết hợp các nguồn nhân lực trong dự án một cách hiệu quả và thực tế thành công của các dự án phần mềm ngày càng nhiều phụ thuộc vào các yếu tố đó. Và cũng có nhiều lý thuyết, tư tưởng ra đời để thực hiện các công việc đó, đó là các mẫu thiết kế, hay còn gọi là Mẫu thiết kế. Trong nhà trường, tôi đã được học về phân tích thiết kế có cấu trúc, việc nghiên cứu thực sự sâu sắc về một phân tích thiết kế mới trong một dự án cụ thể là không có điều kiện , do hạn chế về thời gian. Và do nhận thức dự án, tầm quan trọng của thiết kế hướng đốI tượng đối với các dự án phần mềm, nên tôi chọn đề tài “Mẫu dáng thiết kế Mẫu thiết kế và ứng dụng” là đề tài tốt nghiệp của mình. Với tất cả các kiến thức cơ sở đã được học trong nhà trường cùng sự hướng dẫn của thầy, cũng như sự hướng dẫn nhiệt tình của project manager của công ty sản xuất phần mềm Khai Trí tôi cố gắng, tìm hiểu nghiên cứu Mẫu thiết kế, là những mẫu thiết kế được áp dụng nhiều và rất hiện đại hiện nay. Điều này, đối với một sinh viên chưa có thực tế thì hơn khó khăn vì nghiên cứu và hiểu các mẫu thiết kế và tham gia vào dự án cụ thể trong thực tế thì ngoài yêu cầu kiến thức ở mức nhất định thì cần thiết phải có những trải nghiệm thực tế. Tuy nhiên, điều đó chỉ là yếu tố khách quan, trong thời gian qua, được sự hướng dẫn tận tình của thầy giáo Phạm Đăng Hải, bộ môn khoa học máy tính, khoa Công nghệ thông tin, trường Đại học Bách Khoa Hà Nội, và sự cố gắng của bản thân, tôi đã thực hiện hoàn thành đề tài. Với việc nghiên cứu các mẫu thiết kế Mẫu thiết kế và ứng dụng nó vào thực tế, tôi nghĩ đó là một bước chuyển tiếp nghiên cứu rất quan trọng, từ hàn lâm sang công nghiệp, là bước chuẩn bị quan trọng. Do đó, theo tôi nghĩ đây là một đề tài rất hay, và thiết thực, và rất tin tưởng thực hiện đề tài này TỔNG QUAN VỀ MẪU THIẾT KẾ Lịch sử về mẫu dáng thiết kế. Theo các nghiên cứu của các chuyên gia trong việc thuận lợi của ngôn ngữ đã chỉ ra rằng kiến thức và kinh nghiệm không thể được tổ chức đơn giản xoay quanh vấn đề cú pháp. Nhưng trong các cấu trúc khái niệm lớn hơn như thuật toán, cấu trúc dữ liệu thì cần được lập kế hoạch và thiết kế một cách hoàn thiện. Người thiết kế không nghĩ đến cú pháp mà họ đang sử dụng để thiết kế nhiều như khi họ cố ghép các thiết kế hiện tại mà không phù hợp vớI thuật toán, cấu trúc dữ liệu và các căn bản ăn sâu mà họ đã học. Các nhà khoa học máy tính đã đặt tên và sắp xếp các thuật toán, cấu trúc dữ liệu nhưng họ không thường đặt tên cho các mẫu khác. Mẫu thiết kế cung cấp một từ vựng chung cho các nhà thiết kế để kết nốI, lập tài liệu và tìm hiểu thiết kế mới. Mẫu thiết kế làm cho hệ thống đơn giản hơn bằng cách hiểu nó dựa trên mức trừu tượng hoá cao hơn là các ký pháp thiết kế hoặc ngôn ngữ lập trình. Mẫu thiết kế làm tăng mức độ thiết kế giúp các thành viên trong một nhóm có thể dễ dàng hiểu và thảo luận cùng nhau trong một vấn đề cần giải quyết. Biết được các mẫu dáng thiết kế giúp cho ta hiểu dễ dàng về các hệ thống hiện tại. Hầu hết các hệ thống hướng đối tượng sử dụng các mẫu thiết kế này. Những người nghiên cứu chương trình hướng đốI tượng thường phàn nàn rằng các hệ thống đã từng nghiên cứu hoặc thực hiện sử dụng tính kế thừa rất phức tạp khó có thể kiểm soát được chúng. Thực tế xảy ra rất nhiều vì họ không hiểu được các mẫu thiết kế trong hệ thống. Các mẫu dáng thiết kế giúp người nghiên cứu trở thành một nhà thiết kế giỏi hơn, hơn thế nữa, mô tả hệ thống theo các mẫu thiết kế sẽ làm cho hệ thống dễ hiểu hơn. Do có vốn từ vựng chung nên bạn không phải mô tả toàn bộ các mẫu thiết kế, chỉ cần đặt tên cho mẫu thiết kế đó, thì người đọc sẽ hiểu rõ ràng về vấn đề đó như thế nào? Chúng ta sử dụng chúng để đặt tên cho các lớp, để nghiên cứu tốt hơn và thiết kế để mô tả các mẫu thiết kế. Mục đích của các mẫu thiết kế. Giúp cho người thiết kế tái sử dụng lại thành công bởi việc dựa trên nền thiết kế mới và kinh nghiệm. Một nhà thiết kế áp dụng chúng và hiểu được chúng nhanh chóng mà không cần phải tìm hiểu và thiết kế lại chúng. Làm cho tái sử dụng lại các thiết kế và phân tích tốt hơn. Mẫu thiết kế là một kỹ thuật mới giúp cho người phát triển của hệ thống mới dễ dàng truy nhập hơn. Mẫu thiết kế giúp cho việc lựa chọn thiết kế có thứ tự làm cho hệ thống tối ưu và tránh được những rủi ro không đáng có. Các mẫu thiết kế giải quyết vấn đề như thế nào? Tìm kiếm đối tượng thích hợp: Cái khó của phân tích thiết kế hướng đối tượng là phân tích hệ thống thành các đối tượng, chúng đều ảnh hưởng đến phân tích, thường xuyên phương pháp hoá cách tiếp cận Xác định tính chất của đối tượng: Các đối tượng có thể biến đổi lớn về số lượng và kích cỡ, chúng có thể biểu diễn mọi thứ, và có thể tổng thể ứng dụng lựa chọn các đối tượng như thế nào để phù hợp bài toán và khả năng chia nhỏ đối tượng lớn thành các đối tượng nhỏ hơn, là một vấn đề cần phải có quyết định đúng. Định nghĩa giao diện đối tượng: Mẫu thiết kế giúp xác định giao diện bằng cách nhận dạng các khoá thành phần của nó và các dạng dữ liệu được nhận biết qua giao diện. Mẫu thiết kế còn xác định mối quan hệ giữa các giao diện. Đặc biệt chúng còn yêu cầu một số lớp có giao diện tương tự nhau, hoặc chúng định vị trí các ràng buộc trong giao thức của những lớp này. Xác định các thực hiện đối tượng: Cách thực hiện của đối tượng được thông qua các lớp của nó. Một lớp được chỉ ra dữ liệu bên trong đối tượng và biểu diễn , xác định các thao tác các đối tượng thực hiện Lớp và giao thức kế thừa: Theo quy tắc: Programming to an Interface, not an Implementation Vấn đề tái sử dụng và tham số hoá các dạng Mẫu thiết kế. Các phương pháp để chọn các mẫu thiết kế Phải tìm được các Mẫu thiết kế nào là phù hợp với vấn đề nhất, do đó có một số cách tiếp cận sau: Đi đến quyết định các Mẫu thiết kế giải quyết vấn đề như thế nào? Kiểm tra các nội dung mục đích cần sử dụng. Nghiên cứu các mẫu có liên quan với nhau như thế nào. Nghiên cứu các mẫu phù hợp với mục đích. Kiểm tra nguyên nhân thiết kế lại. Xem xét những vấn đề có thể thay đổi trong thiết kế của bạn. Làm thế nào để thiết kế một mẫu thiết kế Khi chọn được Mẫu thiết kế làm thế nào để sử dụng ?. Nghiên cứu về mẫu đó. Nghiên cứu các thành phần cấu trúc và các vấn đề liên quan. Lựa chọn các tên cho các phần mẫu mà hiệu quả trong ngữ cảnh. Xác định các lớp. Khai báo giao diện, xác lập quan hệ thừa kế và xác định các trường hợp biến biểu diễn dữ liệu và kết quả đối tượng. Nhận dạng các lớp hiện có trong ứng dụng của bạn mà mẫu sẽ tác động sửa đổi chúng cho phù hợp. Xác định ứng dụng, các tên đặc trưng cho các thao tác trong mẫu Thực hiện các thao tác để đưa ra quyền hạn trách nhiệm và cộng tác trong các mẫu. Các mẫu dáng thiết kế (Mẫu thiết kế) Khái quát chung về Mẫu thiết kế. Mẫu thiết kế định tên, thúc đẩy và giải thích một cách có hệ thống các thiết kế mà được địa chỉ hoá trong hệ thống hướng đối tượng. Nó mô tả vấn đề, giải pháp, khi áp dụng các giải pháp và các kết quả của nó. Nó cũng nêu ra các gợi ý và các ví dụ cụ thể trong từng bước thực hiện. Giải pháp là sự sắp sếp các đối tượng và các lớp để giải quyết vấn đề. Giải pháp được tuỳ biến và thực hiện để giải quyết các vấn để trong từng ngữ cảnh riêng biệt. Chúng tôi chia các mẫu thiết kế theo hai tiêu chí. Tiêu chí đầu tiên, là mục đích, ánh xạ những vấn đề mà mẫu thiết kế thực hiện. Các mẫu có thể thuộc vào một trong những mục đích như khởi tạo, cấu trúc và hoạt động. Các mẫu khởi tạo liên quan đến quá trình tạo đối tượng, các mẫu cấu trúc( structural mẫu) giải quyết thành phần của các lớp và các đối tượng. Các mẫu hoạt động( behavioral mẫu) cụ thể hoá phương pháp mà các lớp và các đối tượng thực hiện và phân quyền trách nhiệm. Theo tiêu chí thứ hai, là phạm vi (scope), định nghĩa liệu mẫu áp dụng đầu tiên vào các lớp các đối tượng. Các mẫu class giải quyết mối quan hệ giữa các lớp và các lớp con của nó. Mối quan hệ này được thiết lập thông qua tính kế thừa, nên chúng được gắn kết tĩnh tại thời gian biên dịch. Các mẫu đối tượng giải quyết mối quan hệ giữa các đối tượng, mà có thể được thay đổi tại thời gian chạy và chúng linh động hơn. Hầu hết các mẫu sử dụng tính kế thừa ở một số khía cạnh nào đó. Nên chỉ có mẫu mang tên là “ các mẫu lớp” là tập trung vào mối quan hệ giữa các lớp. Còn lại hầu hết các mẫu đều thuộc vào phạm vi đối tượng. Có nhiều cách tổ chức thành các mẫu. Và một số mẫu được sử dụng cùng nhau để làm trong sáng thiết kế. Sử dụng mẫu nào còn phụ thuộc vào công việc bên trong mà chúng thực hiện, chúng so sánh, và khi nào thì áp dụng chúng. Mẫu khởi tạo Mẫu khởi tạo trừu tượng hoá quá trình khởi tạo(tạo nấc). Mẫu khởi tạo giúp cho hệ thống độc lập vào các đối tượng của nó được tạo ra như thế nào, soạn như thế nào, và biểu diễn như thế nào. Một lớp mẫu khởi tạo sử dụng tính kế thừa để biến đổi lớp đã khởi tạo, nhưng ngược lại một đối tượng mẫu khởi tạo sẽ giao việc khởi tạo tới đối tượng khác. Creational trở nên quan trọng khi các hệ thống có nhiều sự phụ thuộc vào thành phần đối tượng hơn là lớp kế thừa. Có hai vấn đề tuần hoàn trong các mẫu này là : Chúng đều bao gói kiến thức(nội dung) về những lớp thực hiện mà hệ thống sử dụng. Thứ hai là chúng đều ẩn đi làm thế nào mà các thể hiện của các lớp này được tạo ra và được đặt cạnh nhau. Kết quả là mẫu khởi tạo đều đưa ra nhiều hiệu quả hơn trong cái gì đã được tạo ra, ai tạo ra chúng, nó được tạo ra như thế nào, và khi nào thì tạo ra chúng. Chúng cho phép ta cấu hình một hệ thống với các “product” object, biến đổi rộng trong cấu trúc và chức năng. Cấu hình có thể tĩnh(được chỉ định trong thời gian biên dịch) hoặc động(được chỉ định trong thời gian chạy). Trong 23 mẫu thiết kế mà tôi nghiên cứu và tìm hiểu, thì trong mẫu khởi tạo có những mẫu sau: Abstract Factory Builder Factory Method Prototype Singleton Do các mẫu khởi tạo có mối liên quan gần với nhau, ở đây ta nghiên cứu có 5 mẫu mà làm nổi bật nên sự tương đồng và khác nhau của chúng. Chọn mẫu nào còn phụ thuộc vào nhiều yếu tố, và tuỳ vào mục đích dự án của mình mà ta sử dụng các mẫu cụ thể cũng như khi ta kết hợp các mẫu này với nhau trong dự án của mình. Sau đây tôi xin trình bày tổng quan về mục đích, cấu trúc và các mẫu thiết kế của từng mẫu cụ thể trong phần mẫu khởi tạo cũng như khi ta áp dụng chúng vào trong thiết kế dự án cũng như từng phần của dự án thì thu được những kết quả gì. Abstract Factory. Mục đích Cung cấp một giao diện để tạo ra các họ của các đối tượng phụ thuộc hoặc liên quan đến nhau mà không phải xác định chính xác các lớp thực hiện của chúng. Ví dụ Coi bộ dụng cụ giao diện người dùng cung cấp các tiêu chuẩn đa giao diện như là Motif và Presentation Manager. Các thể hiện và hoạt động khác nhau cho giao diện người dùng” widgets” giống như scroll bar, window, và các nút.Theo tiêu chuẩn này, một ứng dụng có thể không khó mã hoá các widget của nó cho từng khía cạnh cảm nhận và nhỉn. Các lớp khởi tạo của widget thông qua ứng dụng này làm cho nó khó mà chuyển đổi sau đó. Giải pháp đặt ra là định nghĩa một lớp WidgetFactory ảo, khai báo một giao diện cho việc tạo từng loại cơ bản trong widget. Cũng có một lớp ảo cho từng loại trong widget, và các lớp con thực hiện cài đặt các widget. Giao diện WidgetFactory có một thao tác trả về một đối tượng widget cho từng lớp widget ảo. Các client gọi những thao tác này để sử dụng các thể hiện widget, nhưng các client không nhận biết được các lớp cụ thể mà chúng sử dụng. Có một lớp con cụ thể của WidgetFactory cho từng tiêu chuẩn một. Mỗi lớp con cài đặt các thao tác để tạo các widget tương ứng. Ví dụ, hàm CreateScrollBar trong MotifWidgetFactory thể hiện và trả về một Motif scroll bar, trong khi các thao tác tương ứng trong PMWidgetFactory trả về một scroll bar cho Presentation Manager. Các client tạo các widget đơn nhất thông qua giao diện WidgetFactory và các lớp cài đặt các widget cho chúng. Một WidgetFactory cũng tuân thủ sự phụ thuộc giữa các lớp widget cụ thể. Một Motif scroll bar có thể được sử dụng với nút Motif và một soạn thảo text Motif, và ràng buộc này phải tự động tuân theo như kết quả khi sử dụng MotifWidgetFactory. Ứng dụng Một hệ thống có thể độc lập vào sản phẩm của nó được tạo ra, kết cấu và biểu diễn như thế nào. Một hệ thống có thể được định dạng với một trong nhiều họ của sản phẩm. Một họ của các đối tượng sản phẩm liên quan được thiết kế để được sử dụng cùng nhau và cần thiết tuân thủ các ràng buộc này. Bạn muốn cung cấp một thư viện lớp của các sản phẩm và muốn chỉ đưa ra giao diện của chúng, mà không cần đưa ra cách cài đặt của chúng. Cấu trúc Client AbstractFactory CreateproductA() CreateproductB() AbstractProductA ProductA2 ProductA1 ConcreteFactory CreateproductA() CreateproductB() ConcreteFactory CreateproductA() CreateproductB() AbstractProductB ProductB2 ProductB1 Các thành phần AbstractFactory: Khai báo một giao diện cho các thao tác mà tạo các đối tượng sản phẩm trừu tượng. ConcreteFactory: Cài đặt các thao tác để tạo các đối tượng sản phẩm cụ thể. AbstractProduct: Khai báo một giao diện cho một dạng của đối tượng sản phẩm. ConcreteProduct: Định nghĩa một đối tượng sản phẩm được tạo bởi concrete factory tương thích. thực hiện giao thức AbstractProduct. Client: Chỉ sử dụng cho các giao diện được khai báo bởi AbstractFactory và các lớp AbstractProduct. Phối hợp cộng tác với các mẫu khác: Thường là một thể hiện lớp ConcreteFactory đơn lẻ được tạo tại thời gian chạy, concrete factory này tạo các đối tượng sản phẩm cài đặt trường hợp riêng biệt. Để tạo các đối tượng sản phẩm khác nhau, client có thể sử dụng một concrete factory khác nhau. AbstractFactory làm theo việc tạo của các đối tượng sản phẩm tới lớp con Concrete Factory. Kết quả Cô lập với các lớp thực hiện : Giúp bạn kiểm soát được các lớp trong các đối tượng mà ứng dụng tạo ra.Vì, một factory bao gói trách nhiệm và quá trình tạo các đối tượng sản phẩm, nó cô lập các client từ các lớp cài đặt của nó. Client sử dụng các thể hiện thông qua các giao diện trừu tượng của chúng. Các tên của lớp sản phẩm được cô lập trong quá trình cài đặt của các factory cụ thể; nên chúng không xuất hiện trong mã của client. Tạo ra sự thay đổi các họ sản phẩm một cách dễ dàng : Lớp của Concrete factory chỉ xuất hiện một lần trong ứng dụng, tại vị trí mà nó được tạo ra.Có thể sử dụng các định dạng sản phẩm khác nhau một cách đơn giản bằng cách thay đổi concrete factory. Do một abstract factory tạo một họ đầy đủ các sản phẩm. Tăng mối quan hệ vững chắc giữa các sản phẩm . Khi các đối tượng sản phẩm trong một họ được thiết kế để làm việc cùng nhau, điều quan trọng là một đối tượng sử dụng các đối tượng chỉ từ một họ, tại một thời điểm. Đưa ra các kiểu dạng mới của sản phẩm là khó. Do vì mở rộng các factory trừu tượng để tạo các dạng mới của Product là không đơn giản. Điều đó có nghĩa là giao diện AbstractFactory cố định một tập các sản phẩm có thể được tạo. Để đưa ra các dạng mới của các sản phẩm thì cần yêu cầu mở rộng giao diện factory, điều đó cũng có nghĩa là giải quyết sự thay đổi lớp AbstractFactory và tất cả các lớp con của nó. Cài đặt Factory là đơn lẻ : Một ứng dụng riêng biệt chỉ cần một thể hiện của Concrete Factory cho mỗi họ sản phẩm. Trong trường hợp này nên dùng mẫu Singleton. Tạo các sản phẩm : Abstract Factory chỉ khai báo một giao diện cho việc tạo các sản phẩm. Tuỳ thuộc vào các lớp con ConcreteProduct để tạo chúng. Phương pháp chung để thực hiện việc này là định nghĩa một factory method cho từng sản phẩm. Định nghĩa các factory có thể được mở rộng.Mỗi dạng sản phẩm thường được AbstractFactory định nghĩa một thao tác khác nhau. Các loại sản phẩm được mã hoá trong các thao tác ký pháp. Do vậy, thêm một loại mới của sản phẩm yêu cầu sự thay đổi giao diện AbstractFactory và tất cả các lớp con phụ thuộc vào nó. Một giải pháp thiết kế hiệu quả và ít rủi ro hơn là thêm vào một tham số tới các thao tác tạo đối tượng. Tham số này chỉ ra dạng đối tượng có thể tạo được. Nó có thể là một lớp nhận dạng, một số nguyên, một xâu, hoặc có thể chỉ ra dạng của sản phẩm. Với phương pháp này, AbstractFactory chỉ cần một thao tác “Make” đơn với một tham số để chỉ ra một dạng đối tượng cần tạo. Các mẫu thiết kế liên quan Các lớp Abstract Factory thường được cài đặt với factory method, nhưng chúng cũng có thể được cài đặt bằng cách sử dụng Prototype. Một concrete factory thường là đơn nhất. Builder Mục đích : Phân tách việc xây dựng của đối tượng phức tạp dựa trên biểu diễn của nó, do đó cùng một tiến trình xây dựng có thể tạo ra các biểu diễn khác nhau. Ví dụ Reader đối với dữ liệu RTF có thể thay đổi định dạng, và chuyển sang một số dạng text khác như ASCII hoặc text wigdet. Và số lượng khả năng chuyển đổi là không kết thúc. Nên nó có thể dễ dàng thêm vào một chuyển đổi mới mà không cần phải chỉnh sửa. Giải pháp tốt là định dạng lớp RTFReader với đối tượng TextConverter, chuyển đổi RTF sang biểu diễn text khác. Như khi RTFReader phân tách dữ liệu RTF, nó sử dụng TextConverter để thực hiện việc chuyển đổi này,dưới dạng chuyển đổi thẻ bài. Các đối tượng TextConverter là có trách nhiệm cho việc thực hiện chuyển đổi dữ liệu và đối với việc biểu diễn một thẻ bài trong từng định dạng một. Các lớp con của TextConverter chỉ ra trong các chuyển đổi và các định dạng khác nhau. Từng dạng lớp chuyển đổi có kỹ thuật tạo và cài đặt đối tượng phức tạp, và đặt chúng dưới dạng một giao diện trừu tượng. Việc chuyển đổi như thế nào là do reader phân tách. Trong mẫu này mỗi lớp chuyển đổi được gọi là builder, và một reader được gọi là director. Trong v í dụ này ta nên áp dụng mẫu Builder, và mẫu Builder phân tách thuật toán cho việc dịch một định dạng text, làm thế nào để một chyển đổi định dạng đã tạo, đã biểu diễn. Nó cho phép sử dụng lại thuật toán chuyển đổi của RTFReader để tạo các biểu diễn text khác nhau từ tài liệu RTF- chỉ được định dạng RTFReader với các lớp con của TextConverter. Ứng dụng Sử dụng một thuật toán xây dựng một đối tượng phức tạp nên có thể độc lập với các thành phần tạo nên đối tượng cũng như việc chúng được lắp ghép lại với nhau như thế nào. Quá trình xây dựng phải cho phép các biểu diễn khác nhau đối với đối tượng mà nó xây dựng. Cấu trúc: Director Contruct() Builder BuilPart() ConcreteBuilder._. BuilPart() GetResult() For all objects in struscture{ Builder->BuildPart() } Product Thành phần Builder : Định nghĩa một giao diện trừu tượng để tạo các thành phần của Product object. ConcreteBuilder: Xây dựng và lắp ráp các phần của sản phẩm bằng cách cài đặt giao diện Builder. Định nghĩa và theo dõi biểu diễn mà nó tạo ra. Cung cấp một giao diện cho việc thu được sản phẩm. Director: Xây dựng một đối tượng bằng việc sử dụng giao diện Builder. Product Biểu diễn đối tượng phức tạp dưới dạng xây dựng. ConcreteBuilder xây dựng biểu diễn bên trong của sản phẩm và định nghĩa tiến trình xử lý mà nó được lắp ráp. Bao hàm các lớp mà định nghĩa các phần hợp thành, bao gồm các giao diện đối với việc cài đặt các phần vào kết quả cuối cùng. Phối hợp cộng tác. Client tạo đối tượng Director và cấu hình nó với việc yêu cầu đối tượng Builder. Director thông báo cho builder bất kỳ khi nào một phần của product có thể được xây dựng. Builder nắm giữ các yêu cầu từ director và thêm các phần tới sản phẩm. Client thu lại sản phẩm từ builder.. Kết quả Cho phép thay đổi biểu diễn bên trong của sản phẩm. Đối tượng Buider cung cấp cho director một giao diện trừu tượng để xây dựng sản phẩm Giao diện này cho phép ẩn đi cách biểu diễn và cấu trúc trong của sản phẩm, cũng ẩn sản phẩm đã lắp ghép như thế nào từ các thành phần cấu thành. Do, sản phẩm được xây dựng qua một giao diện trừu tượng nên tất cả những gì bạn cần làm để thay đổi cách biểu diễn bên trong của product là định nghĩa một Builder mới. Xây dựng và biểu diễn có mã nguồn tách biệt. Mẫu Builder tăng tính modul hoá bằng cách bao gói phương pháp một đối tượng phức tạp đã được tạo ra và cách nó được biểu diễn như thế nào. Client không cần biết gì về các lớp định nghĩa cấu trúc bên trong của sản phẩm, các lớp như thế không xuất hiện trong giao diện Builder. Mỗi ConcreteBuilder chứa tất cả mã nguồn để tạo và lắp ráp một dạng product cụ thể. Mã nguồn được viết một lần và các director có thể sử dụng lại để xây dựng các biến thể khác của sản phẩm từ một tập các thành phần. Giúp kiểm soát tốt hơn trong quá trình xây dựng: Không giống như các creational mẫu khác xây dựng các sản phẩm trong một lần ( one shot)., Builder mẫu xây dựng sản phẩm từng bước một dưới kiểm soát của director. Chỉ khi nào sản phẩm được hoàn thành thì director thu lại nó từ Builder. Do đó, giao diện Builder phản ánh quá trình xây dựng product đầy đủ rõ ràng hơn các mẫu khởi tạo khác. Giúp điều khiển quá trình xây dựng tốt hơn. Cài đặt Đặc thù là có một lớp Builder trừu tượng định nghĩa một thao tác cho từng thành phần, director có thể hỏi đến nó để tạo. Lớp ConcreteBuilder ghi lồng các thao tác cho các thành phần Cài đặt và xây dựng giao diện : Các Builder xây dựng sản phẩm của chúng theo từng bước một, vấn đề thiết kế chính liên quan đến mô hình cho việc xử lý xây dựng và cài đặt. Tại sao không có lớp trừu tượng nào cho các sản phẩm? Trong những trường hợp chung chung, các sản phẩm tạo ra bởi các builder concrete khác rất nhiều so với việc biểu diễn của chúng, trong đó số nhỏ thu được từ việc đưa ra các sản phẩm khác nhau từ một lớp cha thông thường. Các phương pháp rỗng như là sự lựa chọn trong Builder: Trong C++, Build method thường mang tính chất thực hiện không khai báo các thành viên chức năng ảo. Chúng được định nghĩa như một phương pháp rỗng, cho phép các client ghi đè chỉ khi các thao tác mà chúng liên quan mật thiết tới. Các Mẫu quan hệ Abstract Factory thường tương tự với Builder trong đó nó cũng có thể xây dựng các đối tượng phức tạp. Cái khác nhau trước hết là Builder mẫu tập trung vào việc xây dựng một đối tượng phức tạp từng bước một. Tầm quan trọng của Abstract Factory là trong một họ các đối tượng sản phẩm (đơn giản hoặc phức tạp). Builder đưa ra sản phẩm như là bước cuối cùng, nhưng tới một chừng mực nào đó mà Abstract Factory được quan tâm, sản phẩm được đưa ra một cách trực tiếp và nhanh chóng (get returned immediately). Factory Method Mục đích Định nghĩa một giao diện cho việc tạo một đối tượng, nhưng cho phép các lớp con quyết định lớp nào khởi tạo, factory method để một lớp dựa theo việc khởi t ạo đó để tới các lớp con. Ví dụ Framework sử dụng các lớp trừu tượng để định nghĩa và duy trì quan hệ giữa các đối tượng. Một framework thường chịu trách nhiệm tạo những đối tượng. Coi một framework đối với việc áp dụng có thể biểu diễn nhiều document tới user. Hai lớp trừu tượng chính trong framework này là các lớp Application và Document. Cả hai lớp này là trừu tượng, và các client phải phân lớp chúng để thực hiện các application-specific của chúng. Để tạo một ứng dụng vẽ, ví dụ, chúng ta định nghĩa các lớp DrawingApplication và DrawingDocument. Lớp Application có nhiệm vụ chính là quản lý Document và sẽ tạo chúng theo yêu cầu – khi mà user chọn Open hoặc là New từ menu. Factory Method đề ra được một giải pháp. Nó bao gói các hiểu biết của lớp con Document nào tạo và dịch chuyển hiểu biết này ra khỏi framework. Các lớp con Application định nghĩa lại một thao tác CreateDocument trừu tượng trong Application để trả về một lớp con Document tương ứng. Chúng ta gọi CreateDocument là một factory method do nó có nhiệm vụ đối với việc sản xuất một đối tượng. Thành phần Một lớp không thể biết trước lớp của các đối tượng nó phải tạo. Một lớp muốn các lớp con của nó định nghĩa các đối tượng mà nó tạo. Cấu trúc: Product ConcreteProduct Creator FactoryMethod AnOperation() ConcreteCretor FactoryMethod Product=FactoryMethod() Return new CreteProduct Thành phần: Product: Định nghĩa một giao diện của các đối tượng một factory method tạo. ConcreteProduct: Thực hiện giao diện Product. Creator: Khai báo factory method, mà đưa ra một đối tượng của của dạng Product. Creator có thể cũng định nghĩa là một default implementation của factory method để trả về một đối tượng ConcreteProduct mặc định. Có thể gọi factory method để tạo một đối tượng Product. ConcreteCreator: Ghi đè factory method để trả về một thể hiện của ConcreteProduct thích hợp. Kết quả Factory method bỏ qua sự cần thiết để nối kết các lớp định nghĩa ứng dụng (application – specific) vào trong mã nguồn. Mã nguồn chỉ thực hiện với giao diện Product;. Ngoài ra còn có : Cung cấp các móc nối cho các lớp con.: tạo các đối tượng bên trong một lớp với một factory method hữu hiệu hơn là tạo một đối tượng một cách trực tiếp. Factory method đưa cho các lớp con một kết nối để cung cấp một phiên bản mở rộng của đối tượng. Kết nối các biểu đồ lớp song song .Các biểu đồ lớp song song đưa ra kết quả khi một lớp đưa ra các thành phần để phân chia lớp. Cài đặt Có hai dạngbiến đổi chính :Trước hết là khi lớp Creator là lớp trừu tượng và không cung cấp một cài đặt nào cho factory method mà nó khai báo, trường hợp này yêu cầu lớp con định nghĩa một cài đặt. Trường hợp thứ hai là : Khi Creator là lớp thực hiện, và cung cấp mặc định cài đặt cho factory method. Tham số hoá factory method. Factory method sử dụng một tham số để phân biệt được dạng của đối tượng để tạo. Tất cả các đối tượng mà factory method tạo sẽ được sử dụng trong giao diện Product. Sử dụng template để tránh việc phân lớp. Một vấn đề cơ bản khác với factory method là phải phân lớp khi tạo các đối tượng Product tương thích. class Creator { public: virtual Product*CreateProduct() = 0; }; template class StandardCreator : public Creator { public: virtual Product * CreateProduct(); }; template Product * StandardCreator:: CreatorProduct(){ return new TheProduct; } Với template này, client cung cấp một product class – không phân lớp Creator. class MyProduct : public Product{ public : Myproduct(); //.... }; StandardCreatormyCreator; Đặt tên sự chuyển đổi. Các mẫu liên quan: Abstract Factory thường được thực hiện với factory method. Factory method thường đựoc gọi cùng Template Method. Trong ví dụ Document, NewDocument là template method. Prototype không yêu cầu việc phân lớp Creator. Tuy nhiên, chúng thường yêu cầu một thao tác khởi tạo trong lớp Product. Creator sử dụng Initialize để khởi tạo một đối tượng. Factory Method không yêu cầu như một thao tác. Prototype Mục đích Chỉ ra các dạng của nhiều đối tượng để tạo bằng cách dùng một thể hiện mẫu ban đầu, và tạo các đối tượng mới bằng việc sao chép mẫu này. Ví dụ Có thể xây dựng một soạn thảo cho các điểm nhạc bằng cách làm theo một khung tổng quát cho các soạn thảo đồ hoạ và thêm vào các đối tượng mới để biểu diễn ghi chú, các điểm dừng,các đoạn nhạc. Khung soạn thảo có thể có một bảng công cụ đối với việc thêm các đối tượng nhạc tới các điểm. Bảng công cụ cũng có thể chứa công cụ để cho phép chọn lựa, di chuyển, hay các thao tác xử lý dựa trên đối tượng âm nhạc đó. Giả sử, framework cung cấp một lớp ảo Graphic có các thành phần đồ hoạ, giống như là các ghi chú, và các đoạn nhạc. Hơn nữa, nó cũng cung cấp một lớp Tool ảo cho việc định nghĩa các công cụ giống các thao tác trong bảng công cụ. Framework cũng định nghĩa trước một lớp con GraphicTool cho các công cụ tạo các thể hiện của các đối tượng đồ hoạ và thêm chúng vào dữ liệu. Nhưng Graphic Tool biểu diễn một vấn đề cho thiết kế framework. Các lớp cho các ghi chú và các đoạn chỉ ra phần ứng dụng, nhưng lớp GraphicTool thuộc về framework. GraphicTool không biết làm thế nào để tạo các thể hiện của đối tượng nhạc, nhưng cũng tạo rất nhiều lớp con. Chúng ta cũng biết thành phần đối tượng là sự lựa chọn hiệu quả tới việc phân lớp. Một câu hỏi đặt ra là, làm thế nào một framework sử dụng nó để tham số hoá thể hiện của GraphicTool bởi lớp nào của Graphic mà chúng hỗ trợ để tạo ra?Giải pháp được nằm trong GraphicTool tạo một Graphic mới bằng cách sao chép hoặc nhân bản một thể hiện của lớp con Graphic. Chúng ta gọi thể hiện này là mẫu. GraphicTool được tham số hoá bởi mẫu, nó có thể nhân bản và thêm vào tới document. Nếu tất cả các lớp con Graphic thwcj hiện thao tác Clone, sau đó GraphicTool có thể nhân bản bất kỳ một dạng nào của Graphic. Nên trong soạn thảo nhạc, mỗi công cụ tạo một đối tượng nhạc là một thể hiện GraphicTool mà nó tạo với các mẫu khác nhau. Mỗi GraphicTool sẽ tạo ra một đối tượng nhạc khi nhân bản mẫu của nó và thêm một nhân bản tới điểm nhạc. Có thể sử dụng Prototype pattern để làm giảm số lượng các lớp thậm chí con số này còn nhiều hơn nữa. Ta chia các lớp cho toàn bộ ghi chú hoặc phân nửa các ghi chú, nhưng cũng có thể không cần thiết. Thay vào đó các thể hiện của cùng một lớp được khởi tạo bởi các hình ảnh và thời gian khác nhau. Kết quả Sử dụng Prototype khi một hệ thống độc lập với sản phẩm của nó được tạo ra, kết cấu, và biểu diễn như thế nào. Khi các lớp để khởi tạo được xác định tại thời gian chạy ; hoặc Để tránh việc xây dựng một biểu đồ lớp của các factory tương đương với biểu đồ lớp của các sản phẩm. Khi các thể hiện của một lớp có thể có một trong một số các tổ hợp trạng thái khác nhau. Nó thuận tiện hơn để cài đặt một số lượng các mẫu tương đương và nhân bản chúng hơn là phải khởi tạo một lớp, tương đương với mỗi thời điểm của trạng thái. Cấu trúc Client Operation() Prototype Clone() P= prototype->Clone() Return cocy of sell Return cocy of sell ConcretePrototype1 Clone() ConcretePrototype2 Clone() Thành phần : Prototype: Khai báo một giao diện cho việc nhân bản bản thân nó. ConcretePrototype: Thực hiện một thao tác để tự nhân bản nó. Client: Tạo một đối tượng mới bởi việc yêu cầu nhân bản nguyên mẫu. Phối hợp cộng tác Một client yêu cầu một mẫu để tự nhân bản. Kết qủa Nó ẩn một số lớp sản phẩm concrete từ client, làm giảm số lượng tên của các client biết về nó. Các mẫu tạo điều kiện kết hợp một lớp sản phẩm thực hiện mới vào một hệ thống một cách đơn giản bằng việc đăng kí một thể hiện mẫu với client. Hiệu quả hơn là những mẫu khởi tạo khác, do một client có thể cài đặt và bác bỏ các mẫu tại thời gian chạy. Định nghĩa các đối tượng mới bằng cách biến đổi các giá trị. Các hệ thống biến đổi động cao cho phép bạn định nghĩa hoạt động mới thông qua thành phần đối tượng, bởi việc xác định các giá trị cho biến đối tượng.Ví dụ bằng cách xác định giá trị các biến đối tượng và không phải định nghĩa thêm lớp mới. Bạn định nghĩa các loại đối tượng mứoi một cách có hiệu quả bằng việc tạo các thể hiện của các lớp đã có và đăng ký cácthể hiện đó như các mẫu của các đối tượng client. Một client có thể đưa ra một hoạt động mới bằng cách gán chức năng cho nguyên mẫu. Định nghĩa các đối tượng mới bằng cách thay đổi cấu trúc. Một số các ứng dụng xây dựng các đối tượng từ các phần hoặc các phần con. Các soạn thảo cho thiết kế vòng tròn, ví dụ, xây dựng các đường vòng ra khỏi các vòng con. Để cho thuận tiện, như các ứng dụng thường giúp ta khởi tạo các cấu trúc phức tạp, cấu trúc người dùng định nghĩa, cũng nói rằng, để sử dụng các vòng con đã định nghĩa những lần sau. Làm giảm sự phân lớp. Mẫu Prototype giúp ta nhân bản một nguyên mẫu thay vì yêu cầu một factory method để tạo đối tượng mới. Cài đặt Sử dụng một quản lí mẫu khi số lượng các mẫu trong hệ thống không được thông qua, chúng có thể được tạo hay huỷ động. Thực hiện các thao tác nhân bản. Phần khó nhất của mẫu Prototype là thực hiện thao tác nhân bản sao cho chính xác. Khởi tạo các nhân bản. Các mẫu liên quan Prototype và Abstract Factory là các mẫu tương thích trong một số trường hợp, như chúng ta đã thảo luận tại cuối phần này. Chúng có thể được sử dụng cùng nhau, tuy nhiên. Một Abstract Factory cũng lưu trữ một tập các mẫu từ đó nhân bản và trả về các đối tượng sản phẩm. Các thiết kế nặng vấn đề sử dụng của Composite và Decorator mẫu thường có hiệu quả với Prototype tốt. Singleton Mục đích Đảm bảo một lớp chỉ có một thể hiện, và cung cấp điểm toàn cục trong việc truy cập vào nó. Ví dụ Làm thế nào để đảm bảo rằng một lớp chỉ có thể có một thể hiện và thể hiện đó có thể truy xuất dễ dàng? Một biến toàn cục làm cho một đối tượng có thể được truy xuất tại mọi nơi, nhưng không đảm bảo cho việc tạo ra nhiều thể hiện của lớp đó. Giải pháp tốt nhất là bản thân lớp đó có nhiệm vụ theo dõi thể hiện duy nhất của nó. Lớp đó có thể đảm bảo rằng không có thể hiện nào khác có thể được tạo ra, và nó có thể cung cấp cách truy xuất đến thể hiện. Dạng mẫu này được gọi là mẫu Singleton. Ứng dụng Phải có đúng một thể hiện của lớp, và nó phải được truy cập tới clien tử điểm truy cập đã xác định rõ ràng. Khi một thể hiện duy nhất có thể mở rộng bằng cách tạo lớp con và các client của nó phải dùng một thể hiện mở rộng mà không cần sửa đổi lại mã của chúng. Cấu trúc Singleton Static instance() SingletonOperation() GetSingletonData() Static uniqueInstance singletonData Return uniqueInstance Thành phần Singleton: Xác định một thao tác Instance mà cho phép các client truy cập vào trong một thể hiện duy nhất. Instance là một lớp thao tác Có chức năng để tạo một thể hiện duy nhất. Cộng tác: Các client truy cập một Singleton một cách duy nhất thông qua hàm Instance của Singleton. Kết quả : Điều khiển truy cập tới một trường hợp duy nhất Vì lớp Singleton bao gói thể hiện duy nhất của nó. Nên nó có thể có giới hạn điều khiển việc các client truy xuất đến nó như thế nào và khi nào. Giảm thiểu không gian tên.( được cải thiện dựa trên các biến toàn cục, Nó tránh được trùng lặp về không gian tên với các biến toàn cục mà lưu trong trường hợp đơn nhất.). Cho phép cải tiến và làm mịn các thao tác và biểu diễn. Do lớp Singleton có thể tạo ra các lớp con của nó, nó dễ được định dạng một ứng dụng với một thể hiện của lớp được mở rộng này. Bạn có thể định dạng một ứng dụng với thể hiện của lớp bạn cần tại thời gian chạy. Cho phép số lượng biến của các thể hiện, tức là cho phép tạo ra một số lượng có thể thay đổi các thể hiện. Thuận tiện hơn các thao tác lớp, tạo sự mềm dẻo khi thao tác với các lớp, Không nhất thiết là tạo ra thể hiện duy nhất. Mẫu Singleton cho phép tạo nhiều hơn một thể hiện, hơn nữa với hướng tiếp cận như vậy có thể điều khiển được số lượng thể hiện mà ứng dụng sử dụng. Chỉ mỗi hàm cho phép truy xuất đến thể hiện của Singleton là phải thay đổi. Cài đặt Đảm bảo một trường hợp duy nhất. Cách chung nhất để thực hiện điều này là ẩn đi hàm tạo và thể hiện dưới dạng một hàm của lớp( hoặc là một chức năng tĩnh hoặc một class method). Điều đó đảm bảo chỉ một duy nhất một thể hiện được tạo ra, hàm đó truy xuất đến biến có thể hiện duy nhất và nó chắc chắn rằng biến đó được khởi tạo với thể hiện duy nhất truóc khi trả về giá trị của nó. Lớp Singleton được khai báo như sau: class Singleton { public: static Singleton* Instance(): protect: Singleton(); private: static Singleton* _instance; }; Chức năng của việc cài đặt trong này là: Singleton*Singleton:_ instance = 0; Singleton* Singleton:: Instance(){ if (_instance == 0) { _instance = new Singleton; } return _ instance; } Từ đoạn mã cài đặt và chức năng của lớp Singleton, đã nêu rõ được kết quả khi áp dụng mẫu Singleton vào trong thiết kế. Nó kiểm soát được truy xuất tới trường hợp duy nhất và giảm thiểu không gian tên, cũng như cho phép số lượng biến mà nó thể hiện. Phân lớp con trong lớp Singleton. Các mẫu liên quan Một số mẫu có thể được thực hiện bằng việc sử dụng Singleton mẫu. (Abstract factory, Builder, và Prototype). Kết luận: Như vậy có hai cách để tham số hoá hệ thống bởi các lớp đối tượng nó tạo ra. Cách một là sắp xếp các lớp tạo đối tượng, việc này cho phép sử dụng mẫu Factory Method. Mặt hạn chế chính của bước này là nó có thể yêu cầu tạo một lớp con mới để thay đổi lớp của sản phẩm. Sự thay đổi này có thể là trường hợp thay thế. Một mặt khác để tham số hoá hệ thống là dựa trên nhiều thành phần kết cấu đối tượng. Xác định một đối tượng chức năng đối với việc nhận biết lớp của sản phẩm đối tượng, và nó làm cho nó tham số hoá hệ thống. Đây là khía cạnh chủ yếu của Abstract Factory, Builder và Prototype. Ba mẫus này liên quan đến việc tạo một đối tượng factory mới mà tính năng của nó là để tạo ra các đối tượng sản phẩm. Abstract Factory có đối tượng factory tạo đối tượng thuộc một số lớp. Trong khung soạn thảo, Factory method là cách dễ nhất để sử dụng đầu tiên. Nó rất dễ để xác định một lớp con mới. Các mẫu cấu trúc(Structural Mẫu) Các mẫu cấu trúc được quan tâm về các lớp và các đối tượng như thế nào để hợp thành một cấu trúc lớn hơn. Các mẫu lớp cấu trúc đều dùng tính kế thừa để tạo giao diện hoặc thực hiện. Structural đối tượng mô tả các phương pháp để tạo các đối tượng thu được nhiều chức năng mới. Giữa các mẫu cấu trúc có các thành phần giống nhau, đặc biệt là thành phần tham gia và cộng tác của chúng. Điều này là có thể vì các mẫu cấu trúc dựa trên một bộ nhỏ giống nhau của các cơ chế ngôn ngữ về mã cấu trúc và sự vật. Có thể chia chúng thành 2 loại: Structural class pattern: Sử dụng tính kế thừa để tạo các giao diện hay các thực hiện: ví dụ, ta thừa kế trộn 2 hay nhiều lớp thành một lớp. Lớp tạo ra chứa tất cả các thuộc tính của các lớp cha của nó. Structural object pattern: là phương pháp để hợp các đối tượng để thực hiện chức năng mới. Trong các mẫu cấu trúc có các mẫu mà tôi đã nghiên cứu sau: Adapter mẫu Bridge mẫu Composite mẫu Decorator mẫu Facade mẫu Flyweight mẫu Proxy mẫu Adapter mẫu Mục đích Chuyển đổi giao diện của một lớp sang giao diện khác mà client muốn. Cho phép các lớp có giao diện không tương thích làm việc với nhau. Ví dụ: Một soạn thảo đồ hoạ, giúp người dùng có thể vẽ hoặc sắp xếp các thành phần đồ hoạ như là đường thẳng, text, đa giác... vào các tranh vẽ hoặc các biểu đồ. Vấn đề trừu tượng chính của soạn thảo vẽ ở đây là đối tượng đồ hoạ, hình dáng có thể tự sửa đổi được. Giao diện cho các vấn đề đồ hoạ ở đây được định nghĩa bởi một lớp trừu tượng gọi là Shape. Soạn thảo vẽ định nghĩa một lớp con của Shape cho từng loại như LineShape cho đường kẻ, PolygonShape cho đa giác... Các lớp ứng với các hình dáng hình hoạ cơ bản như LineShape, PolygonShape là đơn giản hơn trong việc cài đặt vì các khả năng vẽ và sửa đổi của chúng là hạn chế. Nhưng một lớp con TextShape cho phép hiển thị và sửa đổi text rất khó cài đặt, do việc sửa đổi text đến các phép cập nhật màn hình quản lý bộ đệm phức tạp. Trong khi đó, bộ dụng cụ trong giao diện người dùng cung cấp lớp TextView cho hiển thị và soạn thảo. Ở đây ta muốn sử dụng lại TextView để thực hiện TextShape, nhưng dụng cụ không được thiết kế với Shape nên không thể sử dụng đối tượng TextView và TextShape một cách tích hợp. Như vậy yêu cầu ở đây đặt ra là làm thế nào để các lớp sẵn có và không liên quan như TextView và TextShape có thể làm việc với nhau trong khi giao diện không tương thích với nhau. Một giải pháp đặt ra là có thể thay đổi lớp TextView để cho nó phù hợp với giao diện Shape, nhưng sẽ không thực hiện nếu không có mã nguồn trong bộ dụng cụ. Chính vì thế, thay vì định nghĩa TextShape để thích ứng với giao diện TextView với giao diện Shape. Chúng ta có thể định nghĩa điều này theo 2 cách: bằng cách kế thừa giao diện Shape và thực hiện TextView hoặc kết nối thể hiện TextView vào một TextShape và cài đặt TextShape dưới dạng giao diện của TextView. Cả hai phương pháp này tương ứng với hai phiên bản của mẫu Adapter: class Adapter pattern, và Object Adapter Pattern. Ứng dụng Muốn sử dụng một lớp hiện hành và giao diện của nó nhưng không phù hợp với cái bạn cần. Muốn tạo một lớp sử dụng lại mà các kết nối với các lớp không liên quan, không biết trước, nghĩa là các lớp không cần phải có giao diện tương thích. Cần sử dụng một số các lớp con hiện hành, nhưng nó được ứng dụng trong thực tế để điều hợp giao diện của chúng bằng việc phân lớp. Một đối tượng Adapter có thể điều hợp giao diện của lớp cha. Cấu trúc: Phương pháp I: Một lớp adapter sử dụng tính kế thừa để thíc ứng một giao diện tới giao diện khác. Client Target Request() Adapter Request() Adaptee SpecificRequest() Return uniqueInstance (Implementation) Một đối tượng adapter dựa trên tổ hợp đối tượng. Client Target Request() Adapter Request() Adaptee SpecificRequest() Return uniqueInstance adaptee Thành phần: Target : định nghĩa giao diện domain-specific mà Client sử dụng. Client : Cộng tác với các đối tượng tuân theo giao diện Target . Adaptee : Định nghĩa một giao diện có sẵn cần thiết cho việc thích nghi. Adapter:Giao diện này cần phải sửa đổi cho phù hợp với giao diện Target. Các cộng tác Client gọi các lệnh trong thể hiện Adapter. Từ đó, adapter gọi các lệnh Adaptee để thực hiện yêu cầu. Kết quả. Class Adapter và object Adapter có nhiều yếu tố để đánh giá khác nhau để đạt được hiệu quả tốt nhất. Việc làm cho Adapter tương thích với Target được làm cho một lớp cụ thể. Dẫn đến, một lớp adapter sẽ không hoạt động khi chúng ta muốn điều hợp một lớp và các lớp con của nó. Điều hợp Adapter tới Target bằng cách chuyển đến lớp Adapter cụ thể. Cho phép Adapter ghi đè một số hoạt động của Adapter, từ khi Adapter là một lớp con của Adaptee. Giới thiệu duy nhất một đối tượng, và không cần điểm gián tiếp nào để nhận đến adaptee. Một đối tượng adapter: Cho phép một adapter làm việc với nhiều adaptee. Làm cho khó ghi đè các hàm của Adaptee hơn, nó yêu cầu tạo lớp con Adaptee và bắt Adapter tham chiếu đến lớp con chứ không phải là bản thân Adaptee. Một số vấn đề khi sử dụng Adapter mẫu: Adapter biến đổi trong một lượng công việc chúng thực hiện để tương thích Adatee tới giao diện Target. Adapter là không trong suốt với client. Cài đặt. Cài đặt lớp Adater trong C++ : Adapter có thể kế thừa chung từ Target và riêng từ Adaptee. Do đó Adapter là một dạng con thuộc Target chứ không thuộc Adaptee. Sử dụng các thao tác trừu tượng. Sử dụng các đối tượng thành phần. Các Adapter đã được tham số hoá. Các mẫu liên quan: Bridge có cấu trúc tương tự như một đối tượng adapter, nhưng Bridge có nội dung khác: Nó được hiểu là để phân chia một giao diện từ việc thực hiện của nó nên có thể biến đổi rõ ràng và độc lập. Một adapter được hiểu là để thay đổi một giao diện của đối tượng sẵn có. Decorator tăng cường đối tượng khác mà không cần thay đổi giao diện của nó. Một Decorator vì thế sẽ trong suốt hơn đối với ứng dụng hơn là một adapter. Từ đó đưa ra kết quả, Decorator hỗ trợ các thành phần đệ quy, mà nó không có hỗ trợ cho một adapter trong suốt. Proxy định nghĩa một biểu diễn hoặc thay thế cho đối tượng khác và không thay đổi giao diện của nó. Bridge mẫu Mục đích Phân tách việc trừu tượng hoá khỏi các cài đặt của chúng để cho cả hai có thể biến đổi một cách độc lập. Ví dụ Việc cài đặt của vấn đề trừu tượng hoá trong cửa sổ Window trong bộ dụng cụ giao diện người dùng, cho phép các user có thể ghi các ứng dụng làm việc trong cả hai hệ thống X Window System và Presentation Manager. Sử dụng tính kế thừa, chúng ta định nghĩa một lớp Window, các lớp con XWindow và PMWindow cài đặt giao diện Window cho các nền khác nhau. Nhưng chính phương pháp này có hai điều hạn chế lớn nhất, đó là: Không thuận tiện khi mở rộng Window để bao hàm các dạng khác của window hoặc các nền mới. Tưởng tượng là một lớp con IconWindow của Window chỉ ra bởi các icon trong Window. Để hỗ trợ Icon Window cho cả hai nền này, chúng ta cài đặt 2 lớp mới, XIconWindow và PMIconWindow. Trong trường hợp xấu nhất, chúng ta sẽ định nghĩa 2 lớp cho mọi cửa sổ. Như vậy cần một nền thứ 3 yêu cầu lớp con Window mới cho tất cả các dạng cửa sổ. Làm cho mã nguồn Client độc lập với nền. Bất kỳ khi nào client tạo một cửa sổ, nó khỏi tạo một lớp thực hiện, mà nó chỉ ra cài đặt. Trong trường hợp này, ạo một đối tượng XWindow kết nối với Window cho việc cài đặt X Window, tạo mã nguồn client độc lập với cài đặt X Window, chính vì thế, nó rất khó để chuyển mã nguồn client tới các nền khác. Khi áp dụng mẫu Bridge, nó lập địa chỉ những vấn đề này bằng cách đặt Window và cài đặt của nó trong biểu đồ lớp phân chia. Chỉ có một lớp kế thừa cho các cửa sổ giao diện (Window, IconWindow, TransientWindow) và biểu đồ lớp phân chia cho các cài đặt cửa sổ chỉ ra nền, coi WindowImp là gốc. Lớp con XWindowImp cung cấp một cài đặt dựa trên X Window System. Tất cả các lớp con Window được cài đặt trong các thao tác ảo từ giao diện WindowImp. Điều này tách riêng các cửa sổ khỏi các cài đặt. Mối quan hệ giã Window và WindowImp như một cầu nối, do nó bắc cầu giữa vấn đề trừu tượng này và việc cài đặt của nó, cho phép chúng biến đổi một cách độc lập. Ứng dụng Cần tránh một kết nối cố định giữa vấn đề ảo và việc cài đặt của nó. Cả vấn đề ảo và việc cài đặt của nó có thể mở rộng việc phân lớp con. Trong trường hợp này Bridge cho phép bạo tổ hợp các vấn đề ảo và các cài đặt khác nhau và mở rộng chúng một cách độc lập. Thay đổi cài đặt của một vấn đề ảo có thể không ảnh hưởng đến client; có nghĩa là mã của chúng không cần phải dịch lại. Muốn ẩn việc thực hiện của vấn đề ảo hoàn toàn từ các client. Muốn dùng chung cài đặt giữa nhiều đối tượng, và điều này có thể được ẩn từ client. Cấu trúc: Client Abstraction Operation() Abstraction Operation() RelinedAbstraction imp->OperationImp() ConcreteimplementorA OperationImp() ConcreteimplementorB OperationImp() Thành phần: Abstraction: Định nghĩa một giao diện trừu tượng. Duy trì một tham chiếu tới một đối tượng của dạng Implementor. RefinedAbstraction : Mở rộng một giao diện được định nghĩa bởi Abstraction. Implementor: Định nghĩa một giao diện để cài đặt các lớp. Giao diện này không cần phải thực hiện một cách chính xác tới giao diện của Abstraction; thực tế hai giao diện có quá nhiều điểm khác nhau. Điển hình giao diện Implementor cung cấp các thao tác cơ bản, và Abstraction định nghĩa các thao tác mức cao dựa trên những ưu tiên này. ConcretImplementor: Thực hiện giao diện Implementor và định nghĩa cài đặt cụ thể. của nó. Kết quả Phân tách giao diện và cài đặt. Do việc thực hiện của vấn đề ảo có thể được định dạng tại thời gian chạy. Phân tách được Abstraction và Implementation cũng loại bỏ được sự phụ thuộc của thời gian biên dịch vào cài đặt, thay đổi việc cài đặt lớp không yêu cầu phải biên dịch lại lớp Abstraction và các client của nó. Khả năng mở rộng được cải thiện. Có thể mở rộng biểu đồ Abstraction và Implementation một cách độc lập. Ẩn đi các chi tiết cài đặt từ Client. Cài đặt Trong quá trình thực hiện khi áp dụng Bridge mẫu vào, sẽ phát sinh một số vấn đề sau : Chỉ có một Implementor. Tạo đúng đối tượng Implementation Sử dụng chung Implementor. Sử dụng tính đa kế thừa. Các mẫu liên quan Abstract Factory có thể tạo và cấu hình một phần Bridge. Adapter mẫu lớn hơn toward việc tạo các lớp không phụ thuộc làm việc cùng nhau. Nó thường được áp dụng vào hệ thống sau khi chúng đã được thiết kế. Bridge, trong một khía cạnh nào đó, được sử dụng up-front trong thiết kế để cho phép các trừu tượng hoá và việc cài đặt biến đổi một cách độc lập. Composite Mục đích Tạo nên một cách tổng thể các đối tượng thành cấu trúc cây để biểu diễn các hệ thống part-whole. Composite cho phép các client sử dụng các đối tượng và các thành phần riêng lẻ của các đối tượng thống nhất. Ví dụ Ứng dụng đồ hoạ như soạn thảo vẽ và hệ thống biểu diễn dưới dạng bản đồ cho phép người dùng xây dựng một biểu đồ phức tạp từ những thành phần đơn giản. Người dùng có thể nhóm các thành phần để tổ chức thành thành phần lớn hơn. Một cách thực hiện đơn giản là có thể định nghĩa các lớp cho các mẫu đồ hoạ như Text, Line, và các lớp có các hoạt động này. Khi sử dụng phương pháp này, sẽ xuất hiện một vấn đề: Mã nguồn mà sử dụng các lớp này phải xử lý được màu gốc và các đối tượng trong nội dung đó một cách khác nhau. Để phân biệt những đối tượng này sẽ làm cho hệ thống phức tạp hơn. Mẫu Composite mô tả làm thế nào để sử dụng thành phần đệ quy nên các client không cần phải tạo sự khác biệt đó. Nhưng vấn đề chủ yếu ở đây là: một lớp ảo biểu diễn cả gốc và nội dung của nó. Đối với hệ thống đồ hoạ, lớp này là Graphic, Graphic khai báo các thao tác Draw, dùng để chỉ ra các đối tượng đồ hoạ. Nó cũng khai báo các thao tác mà tất cả các thành phần của nó sử dụng chung, ví dụ như thao tác truy xuất và quản lí các lá con của nó. Các lớp con như là Line, Rectangle, và Text, định nghĩa các đối tượng đồ hoạ cơ bản. Những lớp này cài đặt thao tácDraw đ._.