THIẾT KẾ LỚP và PHƯƠNG THỨC

Lớp (class) là một thuật ngữ chung để xác định và tập hợp các thể hiện hay các đối tượng đặc biệt nào đó. Lớp đóng gói các đặc điểm chung của một nhóm các đối tượng. Khái niệm lớp đã được các nhà phát triển phần mềm hướng đối tượng sử dụng để mô tả các đặc trưng mà các dạng đối tượng cụ thể có thể có. Đối tượng (object) là một khởi tạo của lớp, nó có thể là một sự vật, một thực thể, một danh từ hoặc bất cứ cái gì mà bạn có thể nhặt lên hoặc ném đi, hay những gì mà bạn có thể tưởng tượng ra với một số đặc tính nào đó của nó. Mỗi đối tượng có các thuộc tính (attribute) mô tả thông tin về đối tượng đó. Trạng thái (state) của một đối tượng được xác định bởi bộ giá trị của những thuộc tính và quan hệ với những đối tượng khác tại một thời điểm cụ thể. Mỗi đối tượng có một số hành vi (behavior) nhằm đặc tả những gì đối tượng này có thể thực hiện được. Trong các mô hình hướng đối tượng, các thuật ngữ hành vi, hành động (action), thao tác (operation), phương thức (method) đều có nghĩa như nhau nhưng thường được dùng cho các ngữ cảnh khác nhau. Ví dụ, khi nói về các đối tượng thực tế thì ta thường hay nói hành vi hay hành động của đối tượng đó; khi đề cập đến đối tượng trong lập trình người ta thường dùng phương thức hay thao tác nhưng phương thức được dùng phổ biến, nó được xem là thể hiện cài đặt của hành vi.

THIẾT KẾ LỚP VÀ PHƯƠNG THỨC

1 Lớp, Đối tượng, Phương thức và Thông điệp

Lớp (class) là một thuật ngữ chung để xác định và tập hợp các thể hiện hay các

đối tượng đặc biệt nào đó Lớp đóng gói các đặc điểm chung của một nhóm các đối tượng Khái niệm lớp đã được các nhà phát triển phần mềm hướng đối tượng sử dụng để mô tả các đặc trưng mà các dạng đối tượng cụ thể có thể có

Đối tượng (object) là một khởi tạo của lớp, nó có thể là một sự vật, một thực

thể, một danh từ hoặc bất cứ cái gì mà bạn có thể nhặt lên hoặc ném đi, hay những

gì mà bạn có thể tưởng tượng ra với một số đặc tính nào đó của nó Mỗi đối tượng

có các thuộc tính (attribute) mô tả thông tin về đối tượng đó Trạng thái (state) của một đối tượng được xác định bởi bộ giá trị của những thuộc tính và quan hệ với những đối tượng khác tại một thời điểm cụ thể Mỗi đối tượng có một số hành vi (behavior) nhằm đặc tả những gì đối tượng này có thể thực hiện được Trong các

mô hình hướng đối tượng, các thuật ngữ hành vi, hành động (action), thao tác (operation), phương thức (method) đều có nghĩa như nhau nhưng thường được dùng cho các ngữ cảnh khác nhau Ví dụ, khi nói về các đối tượng thực tế thì ta thường hay nói hành vi hay hành động của đối tượng đó; khi đề cập đến đối tượng trong lập trình người ta thường dùng phương thức hay thao tác nhưng phương thức được dùng phổ biến, nó được xem là thể hiện cài đặt của hành vi

Phương thức (method) được sử dụng để thực hiện các hoạt động chỉ định hành

vi (hay còn gọi hành động, thao tác) của các đối tượng Phương thức chính là hành động mà một đối tượng có thể thực hiện và nó tương tự như một hàm hay thủ tục trong ngôn ngữ truyền thống như C, Pascal

Thông điệp (message) là thông tin được gửi cho đối tượng để kích hoạt các

phương thức Một thông điệp chính là lời gọi hàm hay thủ tục truyền thống nhưng lại từ một đối tượng này đến đối tượng khác

Ví dụ, trong Hệ quản lý thư viện, nếu nhân viên thư viện cần chèn thêm một cuốn

sách mới, những thông tin được đưa vào qua giao diện sẽ được hệ thống gửi đi dưới dạng thông điệp chèn cuốn sách mới cho chương trình ứng dụng Khi đó đối tượng sách sẽ nhận thông điệp và thực hiện các công việc cần thiết gọi là thực hiện phương thức để chèn cuốn sách mới vào hệ thống

Đóng gói và ẩn dấu thông tin

Đóng gói (encapsulation) là cơ chế kết hợp các quy trình và dữ liệu thành một đối

tượng duy nhất

Ẩn thông tin (information hiding) liên quan đến khả năng hiển thị của các phương

thức và thuộc tính Chính xác là làm cho đối tượng lưu trữ dữ liệu hoặc thực hiện các phương thức không liên quan, miễn là đối tượng hoạt động chính xác Tất cả những gì cần thiết để sử dụng một đối tượng là tập hợp các phương thức và thông điệp cần được gửi để kích hoạt chúng Giao tiếp duy nhất giữa các đối tượng phải thông qua các phương thức của đối tượng Thực tế là chúng ta có thể sử dụng một đối tượng bằng cách gửi một thông báo gọi các phương thức là chìa khóa cho khả năng tái sử dụng vì nó bảo vệ hoạt động bên trong của đối tượng khỏi những thay đổi của hệ thống bên ngoài và nó giữ cho hệ thống không bị ảnh hưởng khi thay đổi được thực hiện đối với một đối Nguyên lý của ẩn dấu thông tin cho rằng chỉ thông tin được đòi hỏi để sử dụng môđun phần mềm là được công khai cho sử dụng môđun đó Nghĩa là, chỉ thông tin được yêu cầu chuyển đến môđun này và thông tin trả về từ môđun đó là được công khai mà thôi

Đa xạ và ràng buộc động

Đa xạ (polymorphism) có nghĩa là cùng một thông điệp có thể được thể hiện

một cách khác nhau qua các lớp đối tượng khác nhau Ví dụ, trong hệ quản lý thư viện, chèn thêm một cuốn sách khác với chèn thêm một bạn đọc hay một nhân viên

vì thông tin các đối tượng này được đưa vào và truyền đi khác nhau và sau đó cũng lưu trữ khác nhau May mắn là các ngôn ngữ lập trình hiện nay cho phép chúng ta chúng ta xử lý tính đa xạ này thông qua ràng buộc động (dynamic binding)

Ràng buộc động ( dynamic binding) là kỹ thuật cho phép hoãn định kiểu

một đối tượng cho đến thời gian chạy Nghĩa là một phương thức thực sự được gọi khi chương trình chạy Ngược lại, trong ràng buộc tĩnh kiểu của đối tượng được xác định tại thời điểm biên dịch và do đó người phát triển phải tự chọn phương thức nào được gọi thay vì để hệ thống tự thực hiện Ví dụ trong ngôn ngữ lập trình truyền thống như C, chúng ta phải viết một logic quyết định bằng cách sử dụng các toán tử if hay case để xác định đối tượng nào cần chèn thêm và phải gọi tên hàm tương ứng (thêm sách, thêm bạn đọc hay thêm nhân viên) Tuy nhiên, trong lập trình hướng đối tượng, chúng ta có thể thiết kế chương trình để cho hệ thống tự lựa chọn hàm thực thi tương ứng vào thời gian chạy

Kế thừa

Kế thừa (inheritance) là khái niệm đã được đề xuất và sử dụng rộng rãi

trong xây dựng mô hình dữ liệu của nhưng năm 70, 80 thế kỷ trước, cho phép các nhà phát triển xác định các lớp tăng dần bằng cách sử dụng lại các lớp được định nghĩa trước đó làm cơ sở cho các lớp mới Mặc dù chúng ta có thể định nghĩa từng

lớp riêng biệt, nhưng có thể đơn giản hơn nếu định nghĩa một lớp cha chung chứa

dữ liệu và phương thức cần thiết của các lớp con và sau đó để các lớp này kế thừa các thuộc tính của lớp cha Các lớp con kế thừa các thuộc tính và phương thức thích hợp từ các lớp cha bên trên chúng Kế thừa giúp việc xác định các lớp trở nên đơn

Trong Java, những lỗi này được gọi là ngoại lệ mà hệ thống “ném” và phải “bắt” Nói cách khác, nhà lập trình phải lập trình chính xác ném và bắt nếu không máy ảo Java sẽ ngừng hoạt động Một lần nữa, mỗi ngôn ngữ lập trình có thể xử lý những tình huống này theo một cách riêng Đã có nhiều loại cơ chế kế thừa khác nhau được liên kết với các hệ thống hướng đối tượng.Các cơ chế kế thừa phổ biến nhất bao gồm các dạng khác nhau của kế thừa đơn và đa kế thừa Kế thừa đơn cho phép một lớp con chỉ có một lớp cha duy nhất Hiện tại, tất cả các phương pháp, cơ sở dữ liệu và ngôn ngữ lập trình hướng đối tượng đều cho phép mở rộng định nghĩa về thừa kế đơn lớp siêu cấp

Xung đột kế thừa [tức là một thuộc tính (hoặc phương thức) của lớp con có

cùng tên với thuộc tính (hoặc phương thức) của lớp cha] Ví dụ trong Hình 9-4, Doctor là một lớp con của Employee Cả hai phương thức có tên ComputePay () Điều này gây ra xung đột kế thừa Hơn nữa, khi định nghĩa của lớp cha được sửa đổi, tất cả các lớp của lớp đó đều bị ảnh hưởng Điều này có thể dẫn đến xung đột thừa kế bổ sung trong một (hoặc nhiều) lớp con của lớp cha

các xung đột kế thừa là do phân loại lớp con kém trong hệ thống phân cấp kế thừa (loại ngữ nghĩa tổng quát hóa bị vi phạm) hoặc cơ chế kế thừa thực tế vi phạm nguyên tắc đóng gói Để giải quyết những vấn đề này, JimRumbaugh và các đồng nghiệp của ông đã đề xuất các nguyên tắc sau:

■ Không xác định lại các thao tác truy vấn

■ Các phương thức xác định lại những cái kế thừa chỉ nên hạn chế ngữ nghĩa của những cái kế thừa

■ Ngữ nghĩa cơ bản của phương thức kế thừa không bao giờ được thay đổi

■ Chữ ký (danh sách đối số) của phương thức kế thừa không bao giờ được thay đổi Tuy nhiên, nhiều ngôn ngữ lập trình hướng đối tượng hiện có vi phạm các nguyên tắc này

Ngoài khả năng có xung đột kế thừa giữa lớp con và một (hoặc nhiều) lớp cha của

nó, bây giờ có thể xảy ra xung đột giữa hai (hoặc nhiều) lớp cha Trong trường hợp sau này, có ba loại xung đột thừa kế bổ sung khác nhau có thể xảy ra:

■ Hai thuộc tính (hoặc phương thức) kế thừa có cùng tên (chính tả) và ngữ nghĩa

■ Hai thuộc tính kế thừa (hoặc phương thức) có tên khác nhau nhưng ngữ nghĩa giống hệt nhau (nghĩa là chúng là từ đồng nghĩa)

■ Hai thuộc tính (hoặc phương thức) kế thừa có cùng tên nhưng khác nhau về ngữ

nghĩa (nghĩa là chúng là từ đồng nghĩa, từ đồng nhất hoặc từ đồng âm) Điều này

cũng vi phạm việc sử dụng đa hình của nhà cung cấp

TIÊU CHUẨN THIẾT KẾ

Khi xem xét thiết kế của một hệ thống hướng đối tượng, một bộ tiêu chí tồn tại có

thể được sử dụng để xác định xem thiết kế đó là tốt hay xấu Theo Coad

andYourdon, 11 “Một thiết kế tốt là một thiết kế cân bằng giữa các yếu tố đánh đổi

để giảm thiểu tổng chi phí của hệ thống trong suốt thời gian tồn tại của nó” Các

tiêu chí này bao gồm sự khớp nối, sự gắn kết và sự lâu dài

* Khớp nối

Khớp nối (Coupling )đề cập đến cách thức các mô-đun (lớp, đối tượng và hệ thống)

phụ thuộc lẫn nhau hoặc liên quan lẫn nhau trong một hệ thống Sự phụ thuộc lẫn

nhau càng cao thì càng có nhiều khả năng những thay đổi trong một phần của thiết

kế có thể khiến các phần khác của thiết kế phải thay đổi Đối với các hệ thống

hướng đối tượng, Coad và Yourdon đã xác định hai kiểu kết hợp để xem xét: tương

tác và kế thừa

- Khớp nối tương tác giải quyết việc ghép nối giữa các phương thức và đối tượng

thông qua việc truyền thông điệp

- Khớp nối kế thừa đề cập đến việc các lớp được kết hợp chặt chẽ như thế nào trong một hệ thống phân cấp kế thừa Hầu hết các tác giả có xu hướng nói đơn giản rằng loại khớp nối này

là không mong muốn Tuy nhiên, tùy thuộc vào các vấn đề đã nêu trước đây với kế thừa - xung đột kế thừa, khả năng xác định lại và liên kết động- mức độ cao của việc can thiệp thừa

kế có thể không phải là điều tốt

Do đó, một lần nữa, kiến thức về ngôn ngữ lập trình hướng đối tượng nào sẽ được sử dụng là rất quan trọng Từ quan điểm thiết kế, nhà phát triển sẽ cần phải tối ưu hóa việc vi phạm các quy tắc đóng gói và ẩn thông tin, đồng thời gia tăng mong muốn ghép nối giữa các lớp con

và các lớp cha của nó

* Sự gắn kết

Sự gắn kết (Cohesion ) đề cập đến cách một mô-đun (lớp, đối tượng hoặc phương thức) duy

nhất trong một hệ thống Một lớp hoặc đối tượng chỉ nên đại diện cho một thứ và một

phương thức chỉ nên giải quyết một tác vụ duy nhất Ba loại liên kết chung, phương pháp, lớp và tổng quát hóa / chuyên môn hóa, đã được Coad và Yourdon xác định cho các hệ thống hướng đối tượng

-Sự gắn kết phương pháp giải quyết sự gắn kết trong một phương thức riêng lẻ (nghĩa là một phương thức được hướng tới như thế nào) Các phương pháp nên làm một và chỉ một việc Một phương thức thực sự hoạt động tốt nhiều chức năng thì khó hiểu hơn và do đó, để triển khai và duy trì hơn một phương thức chỉ thực hiện một chức năng duy nhất Có bảy kiểu kết dính trực tiếp đã được xác định (xem Hình 9-9)

-Sự gắn kết lớp là mức độ gắn kết giữa các thuộc tính và phương thức của một lớp (tức là

mức độ duy nhất của một lớp) Một lớp chỉ nên đại diện cho một thứ, chẳng hạn như một nhân viên, một bộ phận hoặc một đơn đặt hàng Tất cả các thuộc tính và phương thức chứa trong một lớp phải được yêu cầu để lớp đó đại diện cho thứ đó

Ví dụ: một lớp nhân viên phải có các thuộc tính liên quan đến số an sinh xã hội, họ, tên, chữ đệm, địa chỉ và lợi ích, nhưng không được có các thuộc tính như cửa, động cơ hoặc mui xe Hơn nữa, không được có thuộc tính hoặc phương thức không bao giờ được sử dụng Nói cách khác, aclass chỉ nên có các thuộc tính và phương thức cần thiết để xác định đầy đủ các thể hiện cho vấn đề Trong trường hợp này, chúng tôi có sự gắn kết lớp lý tưởng Glenford Meyers đã gợi ý rằng một lớp kết hợp nên có các thuộc tính sau:

■ Nó phải chứa nhiều phương thức có thể nhìn thấy bên ngoài lớp (nghĩa là một lớp đơn lẻ hiếm khi có ý nghĩa)

■ Mỗi phương thức hiển thị chỉ thực hiện một chức năng duy nhất (tức là nó có tính liên kết chức năng)

* Các loại phương pháp

■ Tất cả các phương thức chỉ tham chiếu đến các thuộc tính hoặc các phương thức khác được xác định trong lớp hoặc một trong các lớp cha của nó (nghĩa là, nếu một phương thức

sẽ gửi thông báo đến một đối tượng khác, thì đối tượng từ xa phải là giá trị của một trong các thuộc tính của đối tượng cục bộ)

■ Nó không nên có bất kỳ khớp nối luồng điều khiển nào giữa các phương thức hiển thị của nó.Page-Jones đã xác định ba loại liên kết lớp ít mong muốn hơn: hỗn hợp, miền hỗn hợp và vai trò hỗn hợp (xem Hình 9-10) Một lớp cá nhân có thể có sự kết hợp của bất kỳ loại nào trong ba loại

* Sự gắn kết tổng quát hóa / chuyên môn hóa giải quyết tính nhạy cảm của hệ thống phân

cấp kế thừa Các lớp trong hệ thống phân cấp kế thừa có quan hệ với nhau như thế nào? Các lớp có liên quan với nhau thông qua một ngữ nghĩa khái quát / chuyên môn hóa (một loại) không? Hoặc, chúng có liên quan đến liên kết viasome, tập hợp hoặc kiểu thành viên của mối quan hệ được tạo ra với mục đích tái sử dụng đơn giản không?

Ví dụ, trong Hình 9-11, các lớp con ClassRooms và Staff kế thừa từ

superclassDepartment Rõ ràng, các trường hợp của các lớp ClassRooms và Staff

không phải là một-loại-ofDepartment Tuy nhiên, trong những ngày đầu của lập

trình hướng đối tượng, việc sử dụng kế thừa này khá phổ biến Khi một lập trình

viên thấy rằng có một số thuộc tính chung mà một tập hợp các lớp chia sẻ, lập trình

viên sẽ tạo ra một trừu tượng nhân tạo xác định các điểm chung Điều này có khả

năng hữu ích trong việc tái sử dụng, nhưng hóa ra nó lại gây ra nhiều cơn ác mộng

về bảo trì Trong trường hợp này, các phiên bản của ClassRooms và Staffclass được

liên kết với hoặc một phần của phiên bản của Bộ Ngày nay, chúng ta biết rằng hệ

thống phân cấp kế thừa gắn kết chặt chẽ chỉ nên hỗ trợ ngữ nghĩa của khái quát hóa

và chuyên môn hóa (a-kind-of) và nguyên tắc thay thế

*Connascence – thước đo chất lượng phần mềm

Connascence tổng quát hóa các ý tưởng về sự gắn kết và ghép nối, và nó kết hợp

chúng với các đối số để đóng gói Để thực hiện điều này, ba mức đóng gói đã được

xác định.:

- Đóng gói mức 0 đề cập đến lượng đóng gói được thực hiện trong một dòng

mã riêng lẻ,

- Đóng gói mức 1 là mức đóng gói đạt được bằng cách kết hợp các dòng mã

vào một phương thức

- Đóng gói mức 2 đạt được bằng cách tạo các lớp chứa cả phương thức và

thuộc tính

Sự gắn kết phương thức và sự kết hợp tương tác chủ yếu giải quyết việc đóng gói

mức 1 Sự gắn kết lớp, sự kết hợp tổng quát hóa / chuyên môn hóa và sự kết hợp kế

thừa chỉ địa chỉ đóng gói mức 2 Sự hình thành, như một gen- sự tổng hợp của sự

gắn kết và ghép nối, giải quyết cả việc đóng gói mức 1 và mức 2

CÁC HOẠT ĐỘNG THIẾT KẾ ĐỐI TƯỢNG

Các hoạt động thiết kế cho các lớp và phương pháp thực sự là một phần mở rộng của các hoạt động phân tích và phát triển đã được trình bày trước đây (xem Chương 5 đến Chương 8) Trong trường hợp này, chúng tôi mở rộng các mô tả của các phân vùng, các lớp và các lớp Thực tế mà nói, các mô tả mở rộng được tạo ra thông qua các hoạt động diễn ra trong quá trình thiết kế chi tiết các lớp và phương thức Các hoạt động được sử dụng để thiết kế các lớp và phương pháp bao gồm đặc tả bổ sung của mô hình hiện tại, xác định các cơ hội để

sử dụng lại, tái cấu trúc thiết kế, tối ưu hóa thiết kế và cuối cùng, ánh xạ các lớp miền vấn đề sang ngôn ngữ hoàn thiện Tất nhiên, bất kỳ thay đổi nào được thực hiện đối với một lớp trên một lớp cũng có thể dẫn đến các lớp trên các lớp khác được ghép nối với nó cũng bị sửa đổi Các hoạt động của thiết kế đối tượng được mô tả trong phần này

Thêm thông số kỹ thuật (Adding Specifications)

Tại thời điểm này trong quá trình phát triển hệ thống, điều quan trọng là phải xem xét lại tập hợp các mô hình chức năng, cấu trúc và hành vi hiện tại Đầu tiên, chúng ta nên đảm bảo rằng các lớp trên lớp miền vấn đề đều cần thiết và đủ để giải quyết vấn đề cơ bản Để làm điều này, cần phải đảm bảo rằng không có thuộc tính hoặc phương thức bị thiếu và không có thuộc tính hoặc phương thức bổ sung hoặc không sử dụng trong mỗi lớp Hơn nữa, có lớp nào bị thiếu hoặc thêm không? Nếu chúng ta hoàn thành tốt công việc của mình trong quá trình phân tích, sẽ có rất ít thuộc tính, phương thức hoặc lớp, nếu có, để thêm vào các mô hình Và, không chắc rằng chúng ta có bất kỳ thuộc tính, phương thức hoặc lớp bổ sung nào

để xóa khỏi mô hình Tuy nhiên, chúng ta vẫn cần đảm bảo rằng chúng ta đã phân tích dữ liệu, tóm tắt và tinh chỉnh các mô hình đang phát triển và tạo ra các phân vùng và sự cộng tác có liên

Xác định cơ hội để sử dụng lại (Identifying Opportunities for Reuse)

Sử dụng lại (reuse) là khái niệm đã được bàn cãi rất nhiều trong công nghiệp

phần mềm Nhiều nghiên cứu và thực tế phát triển phần mềm đã chỉ ra rằng sử

dụng lại dẫn đến phát triển nhanh hơn, hiệu quả hơn và đáng tin cậy hơn vì mã đã được kiểm thử nhiều lần Hơn nữa, việc bảo trì cũng sẽ dễ dàng hơn

Trong thiết kế, ngoài việc sử dụng các mẫu phân tích, còn có các cơ hội để sử dụng các mẫu thiết kế, khuôn khổ, thư viện và thành phần Các cơ hội thể thao sẽ khác nhau, tùy thuộc vào lớp nào đang được xem xét

Ví dụ:

- Sử dụng lại các chức năng trong một hệ thống: Dạng đơn giản nhất là dùng lại mã nguồn (được sử dụng trong phát triển các hệ thống theo cách truyền thống) liên quan đến việc viết các hàm tiện ích được gọi từ nhiều nơi Ví dụ, một số môdun trong hệ thống cần sử dụng chức năng tìm kiếm thông qua một danh sách tên khách hàng, do đó có thể viết một hàm tìm kiếm chung để

có thể gọi từ các tình huống khác nhau

- Sử dụng lại các phương thức trong một đối tượng: Các phương thức được

đóng gói trong một đối tượng có thể được gọi từ các phương thức khác Ví

dụ, trong Java phương thức không public có thể sử dụng trong lớp nào thuộc cùng gói với nó Bạn nên nghĩ đến việc sử dụng lại các phương thức trong một đối tượng bất cứ khi nào cần

- Dùng lại các lớp trong một số hệ thống: Chúng ta cũng có thể sử dụng lại

toàn bộ lớp (thuộc tính và phương thức) hơn chỉ là một phương thức Ví dụ,

ta có thể viết một lớp nhân viên Employee với một số thuộc tính cùng với các phương thức để sử dụng cho một số dự án của cùng một công ty

- Một khuôn khổ (A framework) bao gồm một tập hợp các lớp được triển khai có thể được sử dụng làm cơ sở để triển khai một ứng dụng Ví dụ, có sẵn các khuôn khổ cho CORBA và DCOM để dựa trên việc triển khai một phần của lớp kiến trúc

hệ thống Hầu hết các framework đều cho phép chúng ta tạo các lớp con để kế thừa

từ các lớp trong framework Có những khung công tác bền vững đối tượng có thể được mua và sử dụng để thêm tính bền bỉ cho các lớp miền có vấn đề, điều này sẽ hữu ích trên lớp quản lý dữ liệu Tất nhiên, khi kế thừa từ các lớp trong một khuôn khổ, chúng ta đang tạo ra một sự phụ thuộc (tức là tăng sự kết hợp thừa kế từ lớp con đến lớp cha) Do đó, nếu chúng tôi sử dụng một khuôn khổ và nhà cung cấp thực hiện các thay đổi đối với khuôn khổ đó, thì ít nhất chúng ta sẽ phải biên dịch lại hệ thống khi chúng tôi nâng cấp lên phiên bản mới của khuôn khổ

- Thư viện lớp (A class library ) tương tự như một khung công tác ở chỗ nó thường

có một tập hợp các lớp được triển khai được thiết kế để sử dụng lại Tuy nhiên, các khuôn khổ thường có nhiều đặc điểm miền hơn Trên thực tế, các khung công tác

có thể được xây dựng bằng thư viện lớp Một thư viện lớp điển hình có thể được mua để hỗ trợ xử lý số hoặc thống kê, quản lý tệp (lớp quản lý dữ liệu) hoặc phát triển giao diện người dùng (lớp tương tác giữa người và máy tính) Trong một số trường hợp, các thể hiện của các lớp có trong thư viện lớp có thể được tạo và trong các trường hợp khác, các lớp trong thư viện lớp có thể được mở rộng bằng cách tạo

các lớp con dựa trên chúng Như với các khung công tác, nếu chúng ta sử dụng kế thừa để sử dụng lại các lớp trong thư viện lớp, chúng ta sẽ gặp phải tất cả các vấn

đề liên quan đến việc ghép nối và kết hợp kế thừa Nếu chúng ta trực tiếp khởi tạo các lớp trong thư viện lớp, chúng ta sẽ tạo ra một sự phụ thuộc giữa đối tượng của chúng ta và đối tượng thư viện dựa trên các chữ ký của các phương thức trong đối tượng thư viện Điều này làm tăng sự kết hợp giữa các hành động giữa đối tượng thư viện lớp và đối tượng của chúng ta

- Thành phần (A component ) là một phần mềm khép kín, được đóng gói có thể được cắm vào hệ thống để cung cấp một tập hợp các chức năng cần thiết cụ thể Ngày nay, có nhiều thành phần có sẵn để mua đã được triển khai bằng công nghệ ActiveX hoặc JavaBean Một thành phần có một API (giao diện chương trình ứng dụng) được xác định rõ ràng Về cơ bản, một API là một tập hợp các giao diện phương thức với các đối tượng có trong thành phần Các hoạt động bên trong của thành phần được ẩn sau API Các thành phần có thể được thực hiện bằng cách sử dụng các thư viện lớp và khung công tác Tuy nhiên, các thành phần cũng có thể được sử dụng để triển khai các khuôn khổ Trừ khi API thay đổi giữa các phiên bản của thành phần, việc nâng cấp lên phiên bản mới thông thường sẽ chỉ yêu cầu liên kết lại thành phần đó vào ứng dụng Do đó, thông thường không cần biên dịch lại Nói chung, các khuôn khổ được sử dụng hầu hết để hỗ trợ phát triển các đối tượng trên kiến trúc hệ thống, tương tác giữa con người với máy tính hoặc các lớp quản lý

dữ liệu; các thành phần được sử dụng chủ yếu để đơn giản hóa việc phát triển các đối tượng trên miền vấn đề và các lớp tương tác giữa con người với máy tính; và các thư viện lớp được sử dụng để phát triển các khuôn khổ và thành phần cũng như

để hỗ trợ lớp nền tảng Cho dù bạn sử dụng phương pháp tái sử dụng nào trong số những phương pháp tái sử dụng này, bạn phải nhớ rằng việc tái sử dụng mang lại nhiều lợi ích và các vấn đề có thể xảy ra Ví dụ: phần mềm trước đây đã được xác minh và xác thực, điều này sẽ làm giảm số lượng thử nghiệm cần thiết cho hệ thống của chúng tôi Tuy nhiên, như đã nêu trước đây, nếu phần mềm mà chúng tôi đang dựa trên hệ thống của mình thay đổi, thì rất có thể, chúng tôi cũng sẽ phải thay đổi

hệ thống của mình Hơn nữa, nếu phần mềm của một công ty bên thứ ba, chúng tôi đang tạo ra sự phụ thuộc từ công ty của chúng tôi (hoặc công ty của khách hàng của chúng tôi) với nhà cung cấp bên thứ ba Do đó, chúng ta cần có một số niềm tin rằng nhà cung cấp sẽ kinh doanh trong một thời gian

Tái cấu trúc thiết kế (Restructuring the Design)

và phương thức riêng lẻ đã được chỉ định và các thư viện, khung và thành phần của lớp đã được tích hợp vào thiết kế đang phát triển, chúng ta nên sử dụng cấu trúc cơ cấu để cấu trúc lại thiết kế Factoring là quá trình tách biệt các Hoạt động thiết kế bên ngoài các khía cạnh của một phương thức hoặc lớp thành một phương thức

hoặc lớp mới để đơn giản hóa thiết kế tổng thể Ví dụ, khi xem xét một tập hợp các lớp trên một lớp cụ thể, chúng tôi có thể phát hiện ra rằng tập hợp các lớp này có chung một định nghĩa Trong trường hợp đó, có thể hữu ích nếu tính ra các điểm tương đồng và tạo một lớp mới Dựa trên các vấn đề liên quan đến gắn kết, ghép nối và liên kết, lớp mới có thể liên quan đến các lớp cũ thông qua kế thừa (tổng quát hóa) hoặc thông qua mối quan hệ tổng hợp hoặc liên kết Một quá trình khác hữu ích để tái cấu trúc thiết kế đang phát triển là chuẩn hóa được mô tả trong Chương 10 liên quan đến cơ sở dữ liệu quan hệ Tuy nhiên, chuẩn hóa đôi khi có thể hữu ích để xác định các lớp tiềm năng bị thiếu trong thiết kế Cũng liên quan đến chuẩn hóa là yêu cầu thực hiện các mối quan hệ kết hợp và tập hợp thực tế như các thuộc tính Hầu như không có ngôn ngữ lập trình hướng đối tượng nào phân biệt giữa các thuộc tính và các mối quan hệ kết hợp và tập hợp Do đó, tất cả các mối quan hệ kết hợp và tập hợp phải được chuyển đổi thành các thuộc tính trong các lớp

Ví dụ trong Hình 9-14a, các lớp Khách hàng và Trạng thái được liên kết với lớp Đơn hàng Do đó, chúng ta cần thêm các thuộc tính vào lớp Order để tham chiếu đến các lớp Khách hàng và Trạng thái Hơn nữa, lớp liên kết Product-Order phải được chuyển đổi thành một lớp (xem Hình 9-14b) Cuối cùng, tất cả các mối quan

hệ kế thừa phải được thử thách để đảm bảo rằng chúng chỉ hỗ trợ ngữ nghĩa tổng quát hóa / chuyên biệt hóa

Tối ưu hóa thiết kế (Optimizing the Design).

Tối ưu hóa đầu tiên cần xem xét là xem xét các đường dẫn truy cập giữa các đối tượng Trong một số trường hợp, một thông điệp từ đối tượng này sang đối tượng khác có thể có một con đường dài để truyền đi (tức là nó đi qua nhiều đối tượng) Nếu đường dẫn dài và tin nhắn được gửi thường xuyên, nên xem xét một đường dẫn dự phòng Việc thêm một thuộc tính vào đối tượng đang gọi sẽ lưu trữ kết nối trực tiếp đến đối tượng ở cuối đường dẫn có thể thực hiện được điều này Tối ưu hóa thứ hai là xem xét từng thuộc tính của mỗi lớp Phương thức nào sử dụng các thuộc tính và đối tượng nào sử dụng các phương thức cần được xác định Nếu phương thức duy nhất sử dụng thuộc tính là phương thức đọc và cập nhật và chỉ các phiên bản của một tin nhắn lớp duy nhất để đọc và cập nhật thuộc tính, thì thuộc tính có thể thuộc về lớp gọi thay vì lớp được gọi Việc di chuyển thuộc tính sang lớp đang gọi sẽ tăng tốc đáng kể cho hệ thống

Tối ưu hóa thứ ba là xem xét sự xuất hiện trực tiếp và gián tiếp của mỗi phương thức Fanout đề cập đến số lượng tin nhắn được gửi bởi một phương thức Fan-out trực tiếp là số lượng tin nhắn được gửi bởi chính phương thức, trong khi đó fan-out gián tiếp cũng bao gồm số lượng tin nhắn được gửi bởi các phương thức được gọi bởi các phương thức khác trong một cây thông báo Nếu giá trị phản hồi của một phương pháp cao so với các phương pháp khác trong hệ thống, thì phương pháp đó

nên được tối ưu hóa Một cách để làm điều này là xem xét việc thêm một chỉ mục vào các thuộc tính được sử dụng để gửi thông báo đến các đối tượng trong cây thông báo

Tối ưu hóa thứ tư là xem xét thứ tự thực thi của các câu lệnh trong các phương thức thường dùng Trong một số trường hợp, có thể sắp xếp lại một số câu lệnh để phù hợp hơn Ví dụ: nếu dựa trên các đối tượng trong hệ thống, biết rằng quy trình tìm kiếm có thể được thu hẹp bằng cách tìm kiếm trên một thuộc tính trước một thuộc tính khác, thì thuật toán tìm kiếm nên được tối ưu hóa bằng cách buộc nó luôn tìm kiếm theo thứ tự trước

Tối ưu hóa thứ năm là để tránh tính toán lại bằng cách tạo một thuộc tính dẫn xuất (hoặc giá trị hoạt động)(ví dụ: tổng sẽ lưu trữ giá trị của phép tính) Đây còn được gọi là kết quả tính toán trong bộ nhớ đệm Nó có thể được thực hiện bằng cách thêm một trình kích hoạt vào các thuộc tính có trong phép tính (tức là, những thuộc tính mà thuộc tính dẫn xuất phụ thuộc vào) Điều này sẽ yêu cầu tính toán lại chỉ diễn ra khi các thuộc tính đi vào tính toán bị thay đổi Một cách tiếp cận khác là đánh dấu một cách đơn giản thuộc tính dẫn xuất để tính toán lại và trì hoãn việc tính toán lại cho đến lần tiếp theo thuộc tính dẫn xuất được truy cập Cách tiếp cận cuối cùng này sẽ trì hoãn việc tính toán lại càng lâu càng tốt Theo cách này, một phép tính không xảy ra trừ khi nó phải chạy Nếu không, mỗi khi một thuộc tính dẫn xuất cần được truy cập, sẽ cần phải có một phép tính

Tối ưu hóa thứ sáu nên được coi là xử lý các đối tượng tham gia vào liên kết 1-1, tức là cả hai đều phải tồn tại để tồn tại Trong trường hợp này, vì mục đích hiệu quả, có thể hợp lý khi thu gọn hai lớp xác định thành một lớp duy nhất

* Ánh xạ các lớp miền có vấn đề sang ngôn ngữ triển khai

Cho đến thời điểm này trong quá trình phát triển hệ thống, người ta đã giả định rằng các lớp và hệ thống trong các mô hình sẽ được thực hiện trực tiếp trong một ngôn ngữ lập trình hướng đối tượng Tuy nhiên, bây giờ điều quan trọng là phải ánh

xạ thiết kế hiện tại với khả năng của ngôn ngữ lập trình được sử dụng Ví dụ: nếu chúng tôi đã sử dụng đa kế thừa trong thiết kế của bạn nhưng chúng tôi đang triển khai bằng một ngôn ngữ chỉ hỗ trợ kế thừa đơn, thì đa kế thừa phải được tính ra khỏi thiết kế Hoặc, nếu việc triển khai được thực hiện bằng ngôn ngữ dựa trên đối tượng, ngôn ngữ không hỗ trợ kế thừa, 30 hoặc ngôn ngữ không dựa trên đối tượng, chẳng hạn như C hoặc Pascal, chúng ta phải ánh xạ các đối tượng miền vấn đề với các cấu trúc lập trình có thể được thực hiện bằng cách sử dụng môi trường thực hiện đã chọn Trong phần này,

*Triển khai các lớp miền có sự cố bằng một ngôn ngữ kế thừa duy nhất

Vấn đề duy nhất được liên kết với việc triển khai các đối tượng miền vấn đề

là tính thừa số của bất kỳ kế thừa nào nghĩa là, việc sử dụng nhiều hơn một lớp cha được sử dụng trong thiết kế đang phát triển Ví dụ: nếu bạn triển khai giải pháp