Bài giảng Design Pattern - pdf 16

Download miễn phí Bài giảng Design Pattern

Giả sử chúng ta chỉ vừa mới bắt đầu việc thiết kế và chưa có gì nhiều trong mô hình thiết kế. Chúng ta sẽ tìm kiếm trong mô hình domain để tìm ra lớp IE và lớp đó chính là Sale. Chúng ta thêm vào mô hình thiết kế lớp phần mềm mới cũng có tên gọi là Sale và gán cho nó nhiệm vụ biết “knowing total” thông qua method getTotal.

Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí

Tóm tắt nội dung tài liệu:

CHƯƠNG 8:Design Pattern * Nội dung * Coupling là gì? Cohesion là gì? Pattern là gì? GRASP là gì? Coupling là gì? Coupling là 1 cách để đo lừơng xem 1 phần tử khi được kết nối thì nó có khả năng “hiểu biết” đến mức nào hay hoàn toàn phụ thuộc vào các phần tử khác. Phần tử có thể là class, subsystem, system… Một phần tử có coupling thấp (low coupling) nghĩa là nó không phụ thuộc nhiều vào các phần tử khác. * Coupling là gì? Một lớp có coupling cao sẽ phụ thuộc vào nhiều lớp khác. Các lớp này là không nên dùng vì: Những thay đổi trong các lớp có liên quan sẽ làm cho lớp này cũng bị thay đổi theo Khó hiểu khi chúng bị cô lập Khó dùng lại vì nó đòi hỏi sự hiện diện của 1 số lớp mà nó phụ thuộc vào * Cohesion là gì? Coupling đề cập đến sự tương tác giữa các đối tượng thì cohesion đề cập đến sự tương tác bên trong 1 đối tượng. Cohesion là 1 cách đo lường để xem các nhiệm vụ của 1 phần tử có quan hệ chặt chẽ với nhau như thế nào? Một phần tử có trách nhiệm tương đối cao, và không phải làm quá nhiều việc được xem là có cohesion cao (high cohesion) * Cohesion là gì? Một lớp có low cohesion khi nó làm nhiều việc không liên quan nhau hay làm quá nhiều việc. Những lớp này là không nên dùng vì: Khó hiểu Khó dùng lại Khó bảo trì Dễ bị ảnh hưởng bởi các thay đổi Các lớp có cohesion thấp thường biểu diễn cho việc trừu tượng ở mức quá lớn, hay nhận những nhiệm vụ mà lẽ ra phải giao lại cho các đối tượng khác thực hiện. * Cohesion là gì? Method cohesion: là method chỉ đảm nhiệm 1 chức năng hay 1 nhiệm vụ. Thông thường cách đặt tên của nó cũng ngầm nói lên chức năng, ví dụ method chon_nha_cung_cap(), Tinh_tong() Class cohesion: các thuộc tính và method của lớp phải có mức độ cohesion cao, nghĩa là chúng phải được dùng bởi chính các method trong class hay chỉ chứa các method phục vụ cho mục đích chính của class * Các mức độ cohesion Very low cohesion: một class phải tự mình làm nhiều việc trong những miền chức năng hoàn toàn khác nhau. Ví dụ: một lớp vừa có có nhiệm vụ tương tác với database quan hệ vừa quản lý các lệnh gọi thủ tục từ xa. Những nhiệm vụ này thuộc 2 vùng chức năng khác nhau, nên lớp này có very low cohesion. * Các mức độ cohesion Low cohesion: class có nhiệm vụ phải tự mình thực hiện 1 công việc phức tạp trong 1 vùng chức năng. Ví dụ: một lớp có nhiệm vụ tương tác với database quan hệ. Các method của lớp đều có liên quan với nhau nhưng lớp này có quá nhiều method để đảm đương nhiệm vụ Nên chia lớp này thành 1 họ các lớp cùng chia xẻ nhau công việc truy xuất database. * Các mức độ cohesion High cohesion: lớp có nhiệm vụ vừa phải (moderate responsibilities) trong cùng 1 vùng chức năng và hợp tác với các lớp khác để hoàn thành nhiệm vụ. Ví dụ: lớp RDBInterface chỉ có 1 phần nhiệm vụ trong việc tương tác với database. Nó tương tác với hàng tá các lớp khác để khôi phục và lưu trữ dữ liệu. * Quy luật Cohesion và Coupling Cohesion kém thì thường sinh ra coupling kém và ngược lại. Cohesion và couling được ví như âm và duơng (yin and yang) của software engineering * Các lợi ích của high cohesion Làm cho việc thiết kế rõ ràng và dễ hiểu hơn. Việc bảo trì và mở rộng cũng đơn giản hơn. Low coupling thường đuợc hỗ trợ. * Pattern là gì? Trong thực tế có rất nhiều lược đồ class có cấu trúc giống nhau. Pattern được xem như là giải pháp hay cách thức để giải quyết bài toán. Khái niệm về pattern trong thiết kế phần mềm đuợc vay mượn từ ngành kiến trúc xây dựng nơi mà các pattern trợ giúp rất nhiều cho các kiến trúc sư khi làm việc với các cấu trúc phức tạp * Pattern là gì? Một pattern khi được áp dụng vào1 ngữ cảnh mới sẽ đưa ra các khuyến cáo (recommendation) làm thế nào để áp dụng và hòa hợp nó vào tình huống mới “A pattern is a named problem/ solution pair that can be applied in new context, with advice on how to apply it in novel situations and discussion of its trade-offs” * GRASP GRASP (General Responsibility Assignment Software Patterns) bao gồm nhiều pattern mô tả các nguyên tắc cơ bản trong việc thiết kế đối tượng và gán nhiệm vụ cho đối tượng. Hiểu và áp dụng các nguyên tắc GRASP trong quá trình tạo lược đồ tương tác là rất quan trọng giúp thiết kế thành công phần mềm hướng đối tượng. * GRASP Mô hình thiết kế có thể chứa hàng trăm hay hàng ngàn các lớp phần mềm, và 1 ứng dụng có thể yêu cầu hàng trăm hay hàng ngàn các nhiệm vụ cần phải hoàn thành. Khi thiết kế đối tượng, cần chọn lựa xem nhiệm vụ nên gán cho đối tượng nào là phù hợp hơn. Nếu gán hợp lý, hệ thống sẽ trở nên dễ hiểu, dễ bảo trì và mở rộng. * GRASP Có rất nhiều pattern thuộc loại này nhưng 5 pattern cơ bản nhất : Information Expert Creator High Cohesion Low Coupling Controller * Information Expert (or Expert) Solution: Assign a responsibility to the information expert - the class that has the information necessary to fulfill the responsibility. Problem: What is a general principle of assigning responsibilities to objects? Gọi tắt pattern này là IE * Case study 1: Lớp nào biết tổng trị giá Nếu có một số lớp cần biết tổng trị giá của 1 lần bán. Câu hỏi đặt ra là lớp nào có nhiệm vụ cho biết tổng trị giá một lần bán. Theo IE cần tìm xem có lớp nào chứa thông tin cần thiết để xác định tổng số hay không? Chúng ta nên tìm các lớp trong mô hình domain hay mô hình thiết kế. * Case study 1: Lớp nào biết tổng trị giá Trước hết tìm các lớp thích hợp trong mô hình thiết kế. Nếu không tìm thấy, thì tìm các lớp trong mô hình domain và cố sử dụng các lớp trong mô hình domain để tạo lập các lớp tương ứng trong mô hình thiết kế. * Case study 1: Lớp nào biết tổng trị giá Giả sử chúng ta chỉ vừa mới bắt đầu việc thiết kế và chưa có gì nhiều trong mô hình thiết kế. Chúng ta sẽ tìm kiếm trong mô hình domain để tìm ra lớp IE và lớp đó chính là Sale. Chúng ta thêm vào mô hình thiết kế lớp phần mềm mới cũng có tên gọi là Sale và gán cho nó nhiệm vụ biết “knowing total” thông qua method getTotal. * Case study 1: Lớp nào biết tổng trị giá * Case study 1: Lớp nào biết tổng trị giá Thông tin gì cần biết để xác định thành tiền (subtotal) của mỗi mặt hàng (line item)?  cần phải biết số lượng (quantity) và đơn giá (price). Theo mô hình nghiệp vụ, thì lớp SalesLineItem biết số lượng (quantity) và thông tin hàng (ProductSpecification) tương ứng. Vì vậy, SalesLineItem xác định được thành tiền (subtotal) nên nó cũng là IE. * Case study 1: Lớp nào biết tổng trị giá Trong lược đồ tương tác ,để nhận thành tiền của mỗi mặt hàng thì lớp Sale cần gửi thông điệp get-Subtotal cho mỗi lớp SalesLineItem và tính tổng trên kết quả mà nó nhận được * Case study 1: Lớp nào biết tổng trị giá Để hoàn thành nhiệm vụ biết và trả lời thành tiền (subtotal), lớp LineItem cần biết đơn giá sản phẩm. Lớp ProductSpecification là IE sẽ giúp trả lời về đơn giá. Và lớp này cần một thông báo được...

Yêu cầu Download

Tài liệu, ebook tham khảo khác

Bài giảng Design Pattern - pdf 16

Tóm tắt nội dung tài liệu:

Tài liệu, ebook tham khảo khác

Học thêm